Tracer les transitions de fenêtre à l'aide de Winscope

Winscope est un outil Web qui vous permet d'enregistrer, de relire et d'analyser l'état de plusieurs services système pendant et après les animations et les transitions. Winscope enregistre tous les états pertinents des services système dans un fichier de trace. En utilisant l'interface utilisateur Winscope avec le fichier de trace, vous pouvez inspecter l'état de ces services pour chaque frame d'animation, avec ou sans enregistrement d'écran, en relisant, en parcourant et en déboguant les transitions.

Traces compatibles

Winscope vous permet de collecter et de représenter visuellement différentes traces, c'est-à-dire des séquences d'états de services système. Vous pouvez configurer ces traces pour les adapter à des cas d'utilisation spécifiques, allant d'une faible surcharge à une verbosité élevée. Winscope est compatible avec les traces suivantes :

• EventLog : collectez l'enregistrement d'événement de diagnostic système à l'aide de EventLog. Dans Winscope, ces informations ne sont utilisées que pour identifier et afficher les repères CUJ.
• IME : suivez les événements du pipeline de l'éditeur de mode de saisie (IME), y compris IMS, IMMS et le client IME.
• Input : suivez les événements d'entrée provenant de différentes parties du pipeline d'événements d'entrée.
• ProtoLog : collectez les messages ProtoLog à partir des services système et du code des services système s'exécutant dans les processus clients.
• Enregistrement d'écran : collectez un enregistrement d'écran en même temps que les traces.
• Transitions de l'interface : enregistrez les détails du système de transition des fenêtres et des activités.
• SurfaceFlinger : collectez les traces SurfaceFlinger contenant des informations sur les surfaces (couches) telles que la position, le tampon et la composition.
• Transactions : suivez l'ensemble des modifications atomiques reçues par SurfaceFlinger à l'aide de SurfaceControl pour la composition.
• ViewCapture : capturez une plage de propriétés de toutes les vues des fenêtres système compatibles avec ViewCapture, comme l'UI du système et le lanceur d'applications.
• Gestionnaire de fenêtres : suivez les états du Gestionnaire de fenêtres contenant des détails sur les fenêtres, y compris les événements d'entrée et de focus , l'orientation de l'écran, les transitions, les animations, le positionnement et les transformations.

Vidéos compatibles

Winscope peut collecter et afficher des vidages d'état, qui sont des instantanés de l'état de l'appareil pris à des moments spécifiques que vous définissez. Contrairement aux traces, qui sont collectées en continu lors de l'utilisation de l'appareil et peuvent affecter les performances, les vidages ne sont effectués qu'à ces moments définis par l'utilisateur, afin de vérifier que les performances et la verbosité ne sont pas compromises. Cela permet une analyse plus ciblée et efficace de l'état de l'appareil à des moments spécifiques. Winscope est compatible avec les vidages suivants :

• Gestionnaire de fenêtres : videz un seul état du gestionnaire de fenêtres.
• SurfaceFlinger : videz un seul instantané SurfaceFlinger.
• Capture d'écran : collectez une capture d'écran en même temps que les vidages.

Ressources

Pour en savoir plus sur la création et l'exécution de Winscope, consultez Exécuter Winscope.

Pour en savoir plus sur la collecte de traces, consultez Capturer des traces.

Pour savoir comment charger des traces à l'aide de l' interface utilisateur Web Winscope, consultez Charger des traces.

Pour en savoir plus sur l'analyse des traces, consultez Analyser des traces.

Exemples

L'exemple suivant décrit comment déboguer un échec de test de scintillement et un bug signalé par un utilisateur.

Échec du test de scintillement

Cet exemple montre comment utiliser Winscope pour déboguer un échec du test de scintillement.

Examiner l'échec du test

Suivez ces étapes pour déterminer le type de problème et examiner le message d'échec du test.

1. Déterminez le type de problème en examinant le nom du test et de la classe.

   Nom du test et de la classe :

   FlickerTestsNotification com.android.server.wm.flicker.notification.OpenAppFromLockscreenNotificationColdTest#appLayerBecomesVisible[ROTATION_0_GESTURAL_NAV]
   

   Type de problème :

   • Le CUJ fait référence au lancement d'une application à partir d'une notification sur l'écran de verrouillage (OpenAppFromLockscreenNotificationColdTest).
   • Le test s'attend à ce que l'application devienne visible (#appLayerBecomesVisible).

2. Examinez le message d'échec du test, qui fournit des informations complètes sur l'échec, y compris :

   • Une comparaison entre le résultat attendu et le résultat visible réel
   • Des horodatages pour vous aider à identifier le moment où l'échec s'est produit
   • Le nom de l'artefact ou du fichier associé à l'échec
   • Des informations contextuelles supplémentaires permettant de comprendre et de déboguer l'échec

   android.tools.flicker.subject.exceptions.IncorrectVisibilityException: com.android.server.wm.flicker.testapp/com.android.server.wm.flicker.testapp.NotificationActivity# should be visible
   
   Where?
       Timestamp(UNIX=2024-05-10T11:04:14.227572545(1715339054227572545ns), UPTIME=37m21s184ms79178ns(2241184079178ns), ELAPSED=0ns)
   
   What?
       Expected: com.android.server.wm.flicker.testapp/com.android.server.wm.flicker.testapp.NotificationActivity#
       Actual: [e636ecd com.android.server.wm.flicker.testapp/com.android.server.wm.flicker.testapp.NotificationActivity#3457: Buffer is empty, Visible region calculated by Composition Engine is empty, com.android.server.wm.flicker.testapp/com.android.server.wm.flicker.testapp.NotificationActivity#3458: Visible region calculated by Composition Engine is empty]
   
   Other information
       Artifact: FAIL__OpenAppFromLockscreenNotificationColdTest_ROTATION_0_GESTURAL_NAV.zip
   
   Check the test run artifacts for trace files
   
       at android.tools.flicker.subject.layers.LayerTraceEntrySubject.isVisible(LayerTraceEntrySubject.kt:187)
       at android.tools.flicker.subject.layers.LayersTraceSubject$isVisible$1$1.invoke(LayersTraceSubject.kt:151)
       at android.tools.flicker.subject.layers.LayersTraceSubject$isVisible$1$1.invoke(LayersTraceSubject.kt:150)
       at android.tools.flicker.assertions.NamedAssertion.invoke(NamedAssertion.kt:32)
       at android.tools.flicker.assertions.CompoundAssertion.invoke(CompoundAssertion.kt:42)
       at android.tools.flicker.assertions.AssertionsChecker.test(AssertionsChecker.kt:79)
       at android.tools.flicker.subject.FlickerTraceSubject.forAllEntries(FlickerTraceSubject.kt:59)
       at android.tools.flicker.assertions.AssertionDataFactory$createTraceAssertion$closedAssertion$1.invoke(AssertionDataFactory.kt:46)
       at android.tools.flicker.assertions.AssertionDataFactory$createTraceAssertion$closedAssertion$1.invoke(AssertionDataFactory.kt:43)
       at android.tools.flicker.assertions.AssertionDataImpl.checkAssertion(AssertionDataImpl.kt:33)
       at android.tools.flicker.assertions.ReaderAssertionRunner.doRunAssertion(ReaderAssertionRunner.kt:35)
       at android.tools.flicker.assertions.ReaderAssertionRunner.runAssertion(ReaderAssertionRunner.kt:29)
       at android.tools.flicker.assertions.BaseAssertionRunner.runAssertion(BaseAssertionRunner.kt:36)
       at android.tools.flicker.legacy.LegacyFlickerTest.doProcess(LegacyFlickerTest.kt:59)
       at android.tools.flicker.assertions.BaseFlickerTest.assertLayers(BaseFlickerTest.kt:89)
       at com.android.server.wm.flicker.notification.OpenAppTransition.appLayerBecomesVisible_coldStart(OpenAppTransition.kt:51)
       at com.android.server.wm.flicker.notification.OpenAppFromNotificationColdTest.appLayerBecomesVisible(OpenAppFromNotificationColdTest.kt:64)
   

   Cet exemple de résultat indique les éléments suivants :

   • Le problème se produit à 2024-05-10T11:04:14.227572545.
   • NotificationActivity doit être visible, mais ce n'est pas le cas.
   • Le nom du fichier d'artefact contenant les traces de débogage est FAIL__OpenAppFromLockscreenNotificationColdTest_ROTATION_0_GESTURAL_NAV.

Déboguer

Suivez ces étapes pour déterminer la cause du scintillement :

1. Téléchargez les fichiers de trace et chargez-les dans Winscope. Winscope s'ouvre avec SurfaceFlinger sélectionné automatiquement :

   

   Figure 1. Page de destination Winscope avec la vue SurfaceFlinger.

2. Accédez à l'horodatage où le problème se produit en copiant et en collant l'horodatage du message d'exception dans le champ d'horodatage. Vous pouvez copier l'horodatage au format lisible (2024-05-10T11:04:14.227572545) et le coller dans le premier champ, ou copier l'horodatage en nanosecondes (1715339054227572545ns) et le coller dans le deuxième champ.

   

   Figure 2. Boîte de dialogue "Horodatage".

3. Appuyez sur la flèche vers la gauche pour accéder à la frame précédente. Dans cet état, l'application NotificationActivity s'affiche correctement dans la vidéo, et les surfaces de l'application et de l'écran de démarrage sont visibles, comme l'indiquent leurs rectangles verts dans la vue 3D et le chip V sur leurs éléments de hiérarchie.

   Les noms de surface de l'application et de l'écran de démarrage sont les suivants :

   com.android.server.wm.flicker.testapp/com.android.server.wm.flicker.testapp.NotificationActivity#3458`
   
   Splash Screen com.android.server.wm.flicker.testapp#3453
   

   Cela indique que l'application était en cours de lancement lorsque l'écran est devenu noir et que cet événement se produit lors du lancement de l'application, car l'écran de démarrage est toujours visible :

   

   Figure 3. Au lancement de l'application.

4. Appuyez sur la flèche vers la droite pour revenir à la frame suivante, où le scintillement se produit. Dans la vue des rectangles, NotificationShade s'affiche à l'écran au lieu de l'application. Les surfaces suivantes sont affichées dans cette frame :

   • Superpositions de décoration d'écran (en haut et en bas)
   • Barre de navigation
   • Emplacement du pointeur (à partir de l'enregistrement d'écran)

   

   Figure 4. Activité de scintillement.

5. Sélectionnez l'activité de l'application dans la vue hiérarchique. Si vous ne la trouvez pas, désactivez Afficher uniquement V. Ensuite, inspectez la vue des propriétés.

   Le nom de la surface de l'application est le suivant :

   com.android.server.wm.flicker.testapp/com.android.server.wm.flicker.testapp.NotificationActivity#3458`
   

   

   Figure 5. Propriétés de l'application.

   Bien que l'activité de l'application soit définie sur visible et opaque, la surface n'est pas affichée en raison d'une erreur Invisible due to: null visible region. Cela se produit, car une autre surface opaque a été placée devant elle lors de la composition. Cette hypothèse provient du fait que le rectangle NotificationShade se trouve devant le rectangle NotificationActivity dans la vue 3D, et que le NotificationShade visible (vert) est potentiellement la couche choisie.

6. Pour valider cette hypothèse, sélectionnez la surface NotificationShade visible sur la frame actuelle et vérifiez ses propriétés. Les indicateurs sont définis sur OPAQUE|ENABLE_BACKPRESSURE (0x102). Le nom de la surface NotificationShade est NotificationShade#3447. Appuyez ensuite sur la flèche vers la gauche pour revenir à la frame précédente (avant le scintillement) et inspectez à nouveau les propriétés de la surface NotificationShade. Notez qu'au lieu d'être OPAQUE, la surface ne comporte que l'indicateur ENABLE_BACKPRESSURE (0x100). Cela confirme que NotificationShade devient opaque avant la fin du lancement de l'application. Étant donné que NotificationShade se trouve devant NotificationActivity, l'application n'est pas affichée. Le NotificationShade est noir, l'écran devient donc brièvement noir, ce qui provoque le scintillement.

7. Identifiez dans le code pourquoi NotificationShade devient opaque trop tôt.

Bug signalé par l'utilisateur

Les bugs signalés par les utilisateurs peuvent être difficiles à déboguer, car ils manquent souvent d'informations détaillées. Contrairement aux échecs de test de scintillement, qui fournissent des horodatages spécifiques, des détails sur les éléments et des enregistrements d'écran, les bugs signalés par les utilisateurs n'incluent généralement qu'une brève description du problème.

Dans notre étude de cas, les seules informations fournies sont le titre L'écran a scintillé lors de la réouverture de l'application à partir de l'écran partagé et un horodatage approximatif de 18 avril 2024 15:51 GMT-04:00.

Suivez ces étapes pour déboguer un bug signalé par un utilisateur :

1. Chargez le fichier de trace dans Winscope. Winscope s'ouvre avec SurfaceFlinger sélectionné automatiquement.

   

   Figure 6. Page de destination Winscope avec la vue SurfaceFlinger.

2. Accédez à l'horodatage approximatif signalé par l'utilisateur, dans ce cas 3:50 PM GMT-04:00, en saisissant 15:50:00 dans le champ d'horodatage lisible.

   

   Figure 7. Boîte de dialogue "Horodatage".

3. Utilisez la vue des rectangles pour identifier ce qui a été dessiné à l'écran. Pour une meilleure vue, utilisez le curseur Rotation pour modifier la perspective des rectangles. En cochant Afficher uniquement V et Plat dans la vue Hiérarchie , le fond d'écran, la superposition de décoration d'écran, le letterbox, le lanceur d'applications, les contacts et les surfaces du clavier de numérotation sont visibles.

   Les noms des packages sont les suivants :

   • Lanceur d'applications : com.google.android.apps.nexuslauncher/com.google.android.apps.nexuslauncher.NexusLauncherActivity#40602
   • Contacts: com.google.android.contacts/com.android.contacts.activities.PeopleActivity#40565
   • Clavier de numérotation : com.google.android.dialer/com.google.android.dialer.extensions.GoogleDialtactsActivity#40564

   En plus des surfaces visibles (rectangles verts), un rectangle gris, qui représente la surface de la zone d'affichage, nommé Unknown display, s' affiche. Pour améliorer la visibilité, cliquez sur () à côté de la surface ScreenDecorHwcOverlay#64 pour masquer le rectangle correspondant et afficher les surfaces situées derrière. Nous supprimons la superposition pour l'analyse, car elle n'est pas visible par l'utilisateur et ne serait pas signalée comme une animation de scintillement.

   

   Figure 8. Rapport utilisateur.

4. Une fois que vous avez identifié les surfaces impliquées dans la vue en écran partagé, utilisez la trace Transitions pour parcourir différentes actions de l'utilisateur et trouver le scintillement. Cliquez sur l'onglet Transitions dans Winscope pour visualiser la liste des transitions lues :

   

   Figure 9. Transitions.

   La transition lue pendant cette frame est mise en surbrillance en bleu. Dans ce cas, les indicateurs de transition incluent TRANSIT_FLAG_IS_RECENTS, ce qui indique que l'utilisateur accède à l'écran des applications récentes.

5. Cliquez sur le lien dans la colonne Dispatch Time (Heure d'envoi) (dans ce cas, 2024-04-18, 15:50:57.205) pour accéder à ce moment précis et vérifier les rectangles dans l'onglet Surface Flinger. Vérifiez l'exactitude de l'état de l'appareil pendant la transition en parcourant la transition avec la flèche vers la droite et en observant les rectangles.

   Le lanceur d'applications s'affiche à 15:50:57.278, mais l'animation ne démarre pas à ce moment-là. Le fond d'écran est déjà visible, car rien n'est dessiné entre les applications en écran partagé (séparateur). Une frame plus tôt (15:50:57.212), le fond d'écran n'est pas visible et le séparateur s'affiche, ce qui correspond à l'aspect de l'écran partagé lorsqu'il n'est pas animé.

   

   Figure 10. Écran avant l'événement de scintillement.

6. Pour consulter la transition suivante, cliquez directement sur la chronologie. Les états de SurfaceFlinger sont représentés par une ligne de blocs bleu clair. Les transitions sont représentées par une ligne de blocs roses.

   

   Figure 11. Fin de la première transition.

   Cliquez sur la ligne SurfaceFlinger au début de la transition suivante. Sur la figure 11, la position verticale du curseur est indiquée par la fine ligne bleue. L'arrière-plan bleu clair de la ligne SurfaceFlinger indique sa position horizontale. Parcourez la transition avec la flèche vers la droite pour voir si un scintillement se produit. Vérifiez que l'appareil s'affiche correctement pour cette transition.

7. Ignorez la transition suivante, car sa durée est très courte et il est donc peu probable qu'elle contienne un scintillement. Cliquez plutôt sur la chronologie de la ligne SurfaceFlinger au début de la transition plus longue suivante, comme indiqué par le curseur sur l'image suivante.

   

   Figure 12. Fin de la deuxième transition.

   Pendant cette transition, à 15:51:13.239, notez que les couches Splash Screen des deux applications, des contacts et du clavier de numérotation se trouvent du même côté de l'écran :

   

   Figure 13. Écrans de démarrage.

8. Déterminez quelle application se trouve du mauvais côté. Ajoutez un favori à votre position actuelle en cliquant sur l'icône de drapeau à côté du champ de saisie ns pour revenir à cette frame ultérieurement.

   

   Figure 14. Ajouter aux favoris.

9. Accédez à une frame à la fin de la transition en cliquant directement sur la chronologie, par exemple sur 15:51:13.859. Ici, les deux applications se trouvent désormais dans leur position finale, avec le clavier de numérotation à gauche et les contacts à droite :

   

   Figure 15. Écran partagé final.

10. Cliquez sur le drapeau du favori dans la chronologie pour revenir à la frame avec le scintillement.

    

    Figure 16. Chronologie des favoris.

    Les deux applications se trouvent à droite, ce qui indique que le clavier de numérotation n'est pas au bon endroit.

11. Cliquez sur l'écran de démarrage du clavier de numérotation pour afficher ses propriétés. Examinez plus particulièrement ses propriétés de transformation dans la vue Propriétés sélectionnée.

    

    Figure 17. Propriétés de transformation.

    La transformation calculée est appliquée à cette surface, mais n'est pas définie à ce niveau. Les colonnes calculées et demandées ont des valeurs différentes, ce qui indique que la transformation est héritée d'une surface parente.

12. Désélectionnez Plat dans la vue hiérarchique pour afficher l'arborescence hiérarchique complète, puis accédez aux nœuds parents de la surface de l'application jusqu'à ce que les transformations Calculées et Demandées soient identiques, ce qui indique que la transformation est demandée sur la surface Surface(name=Task=7934)/@0x1941191_transition-leash#40670.

13. Vérifiez quand la transformation a été définie pour la première fois et quelle était sa valeur. Réduisez les propriétés sélectionnées en cliquant sur l'icône à côté du titre :

    

    Figure 18. Réduire les propriétés sélectionnées.

14. Sélectionnez Afficher le différentiel dans la vue Proto Dump pour mettre en surbrillance les propriétés qui sont modifiées dans cette frame. Saisissez transform dans le champ de recherche de texte pour filtrer les propriétés :

    

    Figure 19. Afficher le différentiel.

    La transformation est définie sur IDENTITY à SCALE|TRANSLATE|ROT_270 dans cette frame pour le transition-leash.

    Ces informations montrent que le scintillement s'est produit lorsque la transformation a été appliquée à la laisse d'animation de l'application en écran partagé du clavier de numérotation.

    

    Figure 20. Identification du scintillement.

15. Identifiez dans le code pourquoi cette transformation est définie sur la laisse de transition de l'écran partagé.