Test HAL prenant en compte le nom du service

Android 9 inclut la prise en charge de l'obtention du nom de service d'une instance HAL donnée en fonction de l'appareil sur lequel les tests Vendor Test Suite (VTS) sont exécutés. L'exécution de tests VTS HAL prenant en compte le nom du service permet aux développeurs d'automatiser les tests d'extensions de fournisseurs, de plusieurs HAL et de plusieurs instances HAL sur les exécutions de tests VTS côté cible et côté hôte.

À propos des noms de services

Chaque instance du service HAL en cours d'exécution s'enregistre avec un nom de service.

Dans les versions précédentes d'Android, les développeurs exécutant des tests VTS HAL devaient définir le nom de service correct pour le client de test dans getService() ou laisser le nom vide et revenir au nom de service par défaut. Les inconvénients de cette approche comprenaient :

  • S'appuyer sur les connaissances du développeur de tests pour définir le nom de service correct.
  • Limité aux tests sur une seule instance de service par défaut.
  • Maintenance manuelle des noms de service (c'est-à-dire que les noms sont codés en dur, ils doivent être mis à jour manuellement si le nom du service change).

Dans Android 9, les développeurs peuvent obtenir automatiquement le nom du service pour une instance HAL donnée en fonction de l'appareil testé. Les avantages de cette approche incluent la prise en charge des tests :

  • Extensions HAL du fournisseur . Par exemple, lorsqu'un fournisseur dispose d'une implémentation de camera.provider HAL qui s'exécute sur les appareils du fournisseur avec un nom de service personnalisé, VTS peut identifier l'instance du fournisseur et exécuter le test sur celle-ci.
  • Plusieurs instances HAL . Par exemple, lorsque le HAL graphics.composer comporte deux instances (une avec le nom de service « default » et une avec le nom de service « vr »), VTS peut identifier les deux instances et exécuter le test sur chacune d'elles.
  • Tests multi-HAL . Utilisé lors du test de plusieurs HAL avec plusieurs instances. Par exemple, lors de l'exécution du test VTS qui vérifie la manière dont les HAL keymaster et gatekeeper fonctionnent ensemble, VTS peut tester toutes les combinaisons d'instances de service pour ces HAL.

Tests côté cible

Pour activer la reconnaissance du nom de service pour les tests côté cible, Android 9 inclut un environnement de test personnalisable ( VtsHalHidlTargetTestEnvBase ) qui fournit des interfaces pour :

  • Enregistrez le ou les HAL ciblant le ou les HAL dans le test.
  • Répertoriez tous les HAL enregistrés.
  • Obtenez le(s) nom(s) de service pour les HAL enregistrés fournis par le framework VTS.

De plus, le framework VTS fournit une prise en charge d'exécution pour :

  • Prétraitement du binaire de test pour obtenir tous les HAL de test enregistrés.
  • Identifier toutes les instances de service en cours d'exécution et obtenir le nom du service pour chaque instance (récupéré en fonction de vendor/manifest.xml ).
  • Calcul de toutes les combinaisons d'instances (pour prendre en charge plusieurs tests HAL).
  • Génération d'un nouveau test pour chaque instance de service (combinaison).

Exemple:

Runtime support for target-side testing

Figure 1. Prise en charge du runtime du framework VTS pour les tests côté cible

Configurer des tests côté cible prenant en compte le nom du service

Pour configurer votre environnement de test pour les tests prenant en compte le nom du service côté cible :

  1. Définissez un testEnvironment basé sur VtsHalHidlTargetTestEnvBase et enregistrez les HAL de test :
    #include <VtsHalHidlTargetTestEnvBase.h>
    class testEnvironment  : public::testing::VtsHalHidlTargetTestEnvBase {
          virtual void registerTestServices() override {
        registerTestService<IFoo>();
          }
    };
  2. Utilisez getServiceName() fourni par l'environnement de test pour transmettre le nom du service :
    ::testing::VtsHalHidlTargetTestBase::getService<IFoo>(testEnv->getServiceName<IFoo>("default"));
    // "default" is the default service name you want to use.
  3. Enregistrez l'environnement de test dans main() et initTest :
    int main(int argc, char** argv) {
            testEnv = new testEnvironment();
            ::testing::AddGlobalTestEnvironment(testEnv);
            ::testing::InitGoogleTest(&argc, argv);
            testEnv->init(argc, argv);
            return RUN_ALL_TESTS();
    }

Pour des exemples supplémentaires, reportez-vous à VtsHalCameraProviderV2_4TargetTest.cpp .

Tests côté hôte VTS

Les tests VTS côté hôte exécutent des scripts de test côté hôte au lieu de tester les binaires sur le périphérique cible. Pour activer la reconnaissance du nom de service pour ces tests, vous pouvez utiliser des modèles côté hôte pour exécuter le même script de test plusieurs fois avec différents paramètres (similaire au test paramétré gtest).

Runtime support for host-side testing

Figure 2. Prise en charge du runtime du framework VTS pour les tests côté hôte
  • Le script de test hal spécifie le(s) service(s) HAL ciblé(s) dans le test.
  • Le hal_hidl_host_test (sous-classe de param_test ) prend le(s) HAL de test enregistré à partir du script de test, identifie le(s) nom(s) de service correspondant pour le HAL de test, puis génère des combinaisons de noms de service (pour les tests multi-HAL) comme paramètres de test. Il fournit également une méthode getHalServiceName() qui renvoie le nom du service correspondant en fonction du paramètre passé au scénario de test en cours.
  • Le modèle param_test prend en charge la logique pour accepter une liste de paramètres et exécuter tous les cas de test donnés sur chaque paramètre. C'est-à-dire que pour chaque cas de test, il génère N nouveaux cas de test paramétrés (N = taille des paramètres), chacun avec un paramètre donné.

Configurer des tests côté hôte prenant en compte le nom du service

Pour configurer votre environnement de test pour les tests prenant en compte le nom du service côté hôte :

  1. Spécifiez le service HAL cible dans le script de test :
    TEST_HAL_SERVICES = { "android.hardware.foo@1.0::IFoo" }
    
  2. Appelez getHalServiceName() et transmettez le nom à init hal :
    self.dut.hal.InitHidlHal(
                target_type='foo',
                target_basepaths=self.dut.libPaths,
                target_version=1.0,
                target_package='android.hardware.foo',
                target_component_name='IFoo',
                hw_binder_service_name
                      =self.getHalServiceName("android.hardware.foo@1.0::IFoo"),
                bits=int(self.abi_bitness))
    

Pour des exemples supplémentaires, reportez-vous à VtsHalMediaOmxStoreV1_0HostTest.py .

Enregistrer les HAL de test

Dans les versions précédentes d'Android, VTS identifiait le HAL de test à l'aide de l'option <precondition-lshal> configurée dans AndroidTest.xml . Cette approche était difficile à maintenir (car elle reposait sur les développeurs pour configurer correctement le test et mettre à jour la configuration en conséquence) et inexacte (car elle ne contenait que les informations sur le package et la version et non les informations sur l'interface).

Dans Android 9, VTS identifie le HAL de test à l'aide de la connaissance du nom de service. Les HAL de test enregistrés sont également utiles pour :

  • Vérifications des conditions préalables . Avant d'exécuter un test HAL, VTS peut confirmer que le test HAL est disponible sur le périphérique cible et ignorer les tests si ce n'est pas le cas (reportez-vous à la vérification de testabilité VTS ).
  • Mesure de couverture . VTS prend en charge la mesure de la couverture de code inter-processus via la connaissance des services de test HAL qu'il souhaite mesurer (c'est-à-dire pour vider la couverture du processus de service hal).