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
.
- Les sous-classes OEM se trouvent dans un package OEM, tel que
- Intégrez les assistants dans un APK en suivant ces conventions d'exécution de tests.
-
Android.bp
doit déclarerandroid_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éeinteraction-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
etcom.android.cts.helpers.aosp
. Si les assistants OEM implémentent entièrement toutes les interfaces pertinentes, alorscom.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é danstestcases
.
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 argumentdevice-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.