À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

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

Module d'assistance pour l'interaction avec l'appareil CTS

Pour Android 11 ou version ultérieure, les modules d'assistance à l'interaction avec l'appareil de la Compatibility Test Suite (CTS) vous permettent de personnaliser la façon dont certains tests CTS interagissent avec l'interface utilisateur (UI) sur 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 réussissant le CTS.

Les OEM qui souhaitent personnaliser l'UI Android lors du développement de produits et qui doivent réussir le CTS peuvent implémenter des modules d'assistance. Si vous utilisez l'implémentation Android par défaut, aucune action supplémentaire n'est requise.

Implémenter des modules d'assistance

Conditions requises pour personnaliser l'UI

Consultez le CDD ou les modules Mainline pour connaître les exigences concernant l'UI. Si l'UI souhaitée est couverte par les modules CDD ou Mainline, elle ne peut pas être personnalisée.

Si les tests CTS qui interagissent avec l'UI souhaitée n'utilisent pas le framework d'assistance, cette UI ne peut pas être personnalisée. Collaborez avec le propriétaire du test pour convertir le module de test avant de pouvoir modifier l'UI.

Sinon, vous pouvez personnaliser l'UI.

Workflow d'implémentation

Personnalisez l'UI 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'UI. Remplacez les interactions nécessaires de manière appropriée pour l'UI 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 a le préfixe Default.
Créez les outils d'aide dans un fichier APK en suivant ces conventions de test runner.
- 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 helpers OEM implémentent entièrement toutes les interfaces pertinentes, 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 lorsque vous exécutez Tradefed pour CTS. Si nécessaire, vérifiez que la classe d'implémentation d'assistance attendue est sélectionnée en examinant les messages logcat.
Facultatif, mais vivement recommandé : envoyez votre implémentation d'assistant à AOSP ou mettez-la à disposition pour des tests tiers.

Exemple d'implémentation d'un helper

Par exemple, CtsPrintTestCases attend un helper avec l'interface définie dans ICtsPrintHelper. L'implémentation AOSP est appelée com.android.cts.helpers.aosp.DefaultCtsPrintHelper.

Si vous personnalisez l'UI 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, ce qui produit com.oem.cts.helpers.apk et déclare interaction-helpers-prefix comme Oem dans AndroidManifest.xml.

La propriété ro.vendor.cts_interaction_helper_packages de l'appareil 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 premier niveau est documentée dans cts/libs/helpers/core/src/com/android/cts/helpers/ICtsDeviceInteractionHelper.java.

Pour associer 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écuter des tests CTS

Tester sans assistants

À l'exception d'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, deux options s'offrent à vous :

Supprimez la propriété ro.vendor.cts_interaction_helper_packages de l'appareil. Cela empêche complètement l'utilisation des helpers sur cette version.
Supprimez l'APK d'assistance du répertoire testcases avant d'exécuter CTS. Cela empêche toute exécution d'utiliser les helpers jusqu'à ce que l'APK soit restauré sur testcases.

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

Consultez les sections suivantes pour connaître les valeurs ou les plages attendues pour chacun des paramètres disponibles.

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

Tester avec des personnalisations

Par défaut, les implémentations de référence réussissent le CTS sur Android standard. Vérifiez que les implémentations des partenaires réussissent le CTS avec les personnalisations de l'UI. Exécutez les modules CTS qui couvrent l'UI ou les fonctionnalités que vous avez personnalisées.

Il est possible que certains modules ou assistants CTS ne soient pas encore compatibles avec certaines personnalisations.

Il est possible qu'un module CTS qui interagit avec l'UI que vous souhaitez personnaliser n'utilise pas le framework d'assistance. Les modules CTS devraient être convertis au framework d'assistance en fonction de la demande et des priorités du propriétaire du test. Demandez la conversion de fichiers tôt dans le processus pour vous assurer qu'elle est planifiée, de la même manière que vous demandez des modifications du CTS pour prendre en charge les fonctionnalités que vous prévoyez d'implémenter.
Il est possible que les fonctions fournies par un assistant existant ne répondent pas entièrement aux personnalisations que vous souhaitez apporter. Les fonctions d'assistance doivent abstraire les dépendances de l'UI. 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 bugs dans CTS.

Module d'assistance pour l'interaction avec l'appareil CTS Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.