Cette page a été traduite par l'API Cloud Translation.

Module d'aide à l'interaction des appareils CTS

Pour Android 11 ou version ultérieure, les modules d'aide à l'interaction avec les appareils Compatibility Test Suite (CTS) vous permettent de personnaliser la manière dont certains tests CTS interagissent avec l'interface utilisateur (UI) d'un appareil spécifique. Cela signifie que des actions, telles que le remplacement d'un élément d'interface utilisateur qui n'est pas couvert par le document de définition de compatibilité Android (CDD) ou la documentation de l'API, peuvent être effectuées tout en passant le CTS.

Les OEM qui souhaitent personnaliser l'interface utilisateur Android pendant le développement du produit et doivent réussir le CTS peuvent être en mesure d'implémenter des modules d'assistance. Si vous utilisez l’implémentation Android par défaut, aucun travail supplémentaire n’est nécessaire.

Implémentation de modules d'assistance

Conditions requises pour personnaliser l'interface utilisateur

Vérifiez les modules CDD ou Mainline pour connaître les exigences de l'interface utilisateur. Si l'interface utilisateur souhaitée est couverte par les modules CDD ou Mainline, cette interface utilisateur ne peut pas être personnalisée.

Si les tests CTS qui interagissent avec l’interface utilisateur souhaitée n’utilisent pas le framework d’assistance, cette interface utilisateur ne peut pas être personnalisée. Travaillez avec le propriétaire du test pour convertir le module de test avant que l'interface utilisateur puisse être modifiée.

Sinon, vous pouvez personnaliser l'interface utilisateur.

Flux de travail de mise en œuvre

Personnalisez l'interface utilisateur selon les besoins de votre produit spécifique.
Désignez les modules d'assistance AOSP existants comme sous-classes pour les modules de test CTS qui doivent interagir avec l'interface utilisateur. Remplacez les interactions nécessaires de manière appropriée pour l’interface utilisateur personnalisée. Les remplacements varient en fonction du type de modifications.
- Les sous-classes OEM se trouvent dans un package OEM, tel que com.[oem].cts.helpers .
- Chaque sous-classe OEM est nommée avec un préfixe commun qui la distingue de l'implémentation AOSP, qui porte le préfixe Default .
Intégrez les assistants dans un APK en suivant ces conventions d'exécution de tests.
- Android.bp doit déclarer android_test_helper_app avec le même nom que le package contenu.
- AndroidManifest.xml pour l'APK doit déclarer une propriété de métadonnées nommée interaction-helpers-prefix avec la valeur du préfixe de classe choisi dans le point précédent.
- L'application doit dépendre de cts-helpers-core , cts-helpers-interfaces et com.android.cts.helpers.aosp . Si les assistants OEM implémentent entièrement toutes les interfaces pertinentes, alors com.android.cts.helpers.aosp est facultatif.
Définissez la propriété ro.vendor.cts_interaction_helper_packages dans l'image de l'appareil pour inclure le nom de l'APK. Si vous devez séparer vos implémentations d'assistance sur plusieurs APK, cette propriété peut contenir une liste de packages séparés par des deux-points.
Assurez-vous que l'APK est disponible dans le répertoire testcases lors de l'exécution de Tradefed pour CTS. Si nécessaire, confirmez que la classe d'implémentation d'assistance attendue est choisie en examinant les messages logcat.
Facultatif, mais fortement recommandé : soumettez l'implémentation de votre assistant à AOSP ou rendez-la disponible pour des tests tiers.

Exemple d'implémentation d'assistance

Par exemple, CtsPrintTestCases attend un assistant avec l'interface définie dans ICtsPrintHelper . L'implémentation AOSP s'appelle com.android.cts.helpers.aosp.DefaultCtsPrintHelper .

Si vous personnalisez l'interface utilisateur d'impression, vous pouvez créer com.oem.cts.helpers.OemCtsPrintHelper qui sous-classe DefaultCtsPrintHelper . android_test_helper_app dans Android.bp est nommé com.oem.cts.helpers , qui produit com.oem.cts.helpers.apk et déclare interaction-helpers-prefix comme Oem dans AndroidManifest.xml .

La propriété de l'appareil ro.vendor.cts_interaction_helper_packages est définie sur com.oem.cts.helpers .

Implémentations de référence

Les implémentations de référence incluent les interfaces sous cts/libs/helpers et les assistants AOSP par défaut sous cts/helpers . L'interface de niveau supérieur est documentée dans cts/libs/helpers/core/src/com/android/cts/helpers/ICtsDeviceInteractionHelper.java .

Pour connecter le test CTS à ses assistants, les propriétaires de tests peuvent utiliser la définition @Rule documentée dans cts/libs/helpers/core/src/com/android/cts/helpers/DeviceInteractionHelperRule.java .

Chaque module CTS qui utilise le framework et son comportement d'assistance attendu est documenté dans une interface définie sous cts/libs/helpers/core/src/com/android/cts/helpers .

Exécution des tests CTS

Test sans aide

À part une propriété, l'option permettant de tester sans assistants n'existe pas au moment de l'exécution sur l'appareil, mais modifie éventuellement la façon dont les tests CTS interagissent avec l'appareil. Si vous devez exécuter CTS sans les implémentations d'assistance, vous disposez de deux options :

Supprimez la propriété ro.vendor.cts_interaction_helper_packages de l'appareil. Cela empêche les assistants d'être entièrement utilisés sur cette version.
Supprimez l’APK d’assistance du répertoire testcases avant d’exécuter CTS. Cela empêche les assistants d'être utilisés par des exécutions jusqu'à ce que l'APK soit restauré dans testcases .

Vous pouvez modifier les paramètres par défaut avec les arguments Tradefed et le contrôle de propriété ro.vendor.cts_interaction_helper_packages , à partir duquel l'APK d'assistance est chargé.

Consultez ce qui suit pour connaître les valeurs ou plages attendues pour chacun des paramètres disponibles.

ro.vendor.cts_interaction_helper_packages est une chaîne séparée par deux points contenant les noms de packages. Il peut prendre n'importe quelle valeur qui constitue un choix de package valide pour l'implémentation de l'assistant OEM.
cts-tradefed accepte un argument device-interaction-helper:property-name qui modifie temporairement la propriété attendue pour une exécution de test, tel que --module-arg 'CtsPrintTestCases:{device-interaction-helper}property-name:debug.cts.hlp' . La valeur du nom de propriété peut être n'importe quelle propriété que vous définissez sur l'appareil. La valeur de la propriété suit les mêmes restrictions que la propriété ro.vendor.cts_interaction_helper_packages décrite ci-dessus.

Tests avec personnalisations

Par défaut, les implémentations de référence transmettent le CTS sur Android d'origine. Vérifiez que les implémentations des partenaires réussissent le CTS avec les personnalisations de l'interface utilisateur. Exécutez les modules CTS couvrant l’interface utilisateur ou les fonctionnalités que vous avez personnalisées.

Certains modules ou assistants CTS peuvent ne pas encore prendre en charge certaines personnalisations.

Un module CTS qui interagit avec l'interface utilisateur que vous souhaitez personnaliser peut ne pas utiliser le framework d'assistance. Les modules CTS devraient être convertis vers le cadre d'assistance en fonction de la demande et des priorités du propriétaire du test. Déposez des demandes de conversion dès le début du processus pour vous assurer que la conversion se déroule dans les délais, de la même manière que si vous demandiez des modifications CTS pour prendre en charge les fonctionnalités prévues.
Les fonctions fournies par un assistant existant peuvent ne pas répondre entièrement aux personnalisations que vous souhaitez effectuer. Les fonctions d'assistance doivent éliminer les dépendances de l'interface utilisateur. Si une fonction d'assistance a indirectement une dépendance à l'interface utilisateur, cela peut être traité de la même manière que les bogues dans CTS.