À 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
Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

Pour Android 11 ou version ultérieure, les modules d'assistance d'interaction avec l'appareil de la suite de tests de compatibilité (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 les documents 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 leur produit et qui doivent réussir les tests CTS peuvent être en mesure d'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

Vérifiez les modules CDD ou 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 que l'UI ne puisse être modifiée.

Sinon, vous pouvez personnaliser l'UI.

Workflow d'implémentation

Personnalisez l'interface utilisateur en fonction des besoins de votre produit.
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 porte le préfixe Default.
Créez les outils d'assistance dans un APK en suivant ces conventions de testeur.
- 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, 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'aide sur plusieurs APK, cette propriété peut contenir une liste de packages séparés par une double barre oblique.
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'aide attendue est choisie en examinant les messages Logcat.
Facultatif, mais vivement recommandé: envoyez votre implémentation d'assistance à AOSP ou mettez-la à la disposition des tests tiers.

Exemple d'implémentation d'une aide

Par exemple, CtsPrintTestCases attend un assistant 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 une 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é 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 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 test 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 de test sans assistants n'existe pas au moment de l'exécution sur l'appareil, mais elle 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 les assistants d'être entièrement utilisés dans cette compilation.
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 tant que l'APK n'est pas restauré dans testcases.

Vous pouvez modifier les paramètres par défaut à l'aide des arguments Tradefed et de la commande de propriété ro.vendor.cts_interaction_helper_packages, à partir de laquelle l'APK d'assistance est chargé.

Consultez les valeurs ou plages attendues pour chacun des paramètres disponibles ci-dessous.

ro.vendor.cts_interaction_helper_packages est une chaîne séparée par 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 de l'assistant 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é suit les 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 passent le CTS sur Android d'origine. Vérifiez que les implémentations des partenaires passent le CTS avec des 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.

Un module CTS qui interagit avec l'UI que vous souhaitez personnaliser peut ne pas utiliser le framework d'assistance. Les modules CTS devraient être convertis vers le framework d'assistance en fonction de la demande et des priorités du propriétaire des tests. Envoyez des demandes de conversion au début du processus pour vous assurer que la conversion est planifiée, comme vous le feriez pour demander des modifications CTS afin de prendre en charge les fonctionnalités prévues.
Les fonctions fournies par un assistant existant ne répondent peut-être pas 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 présente indirectement une dépendance d'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.