Colis

À quelques exceptions près, les packages d'interface HIDL se trouvent dans hardware/interfaces ou vendor/. La hardware/interfaces est mappé de niveau supérieur directement à Espace de noms du package android.hardware ; la version est un sous-répertoire sous l'espace de noms du package (et non de l'interface).

Le compilateur hidl-gen compile les fichiers .hal dans un ensemble de fichiers .h et .cpp. À partir de ces images générées automatiquement, fichiers auxquels une bibliothèque partagée est créée, avec laquelle les implémentations client/serveur sont liées. Le fichier Android.bp qui crée cette bibliothèque partagée est généré automatiquement par hardware/interfaces/update-makefiles.sh script. Chaque fois que vous ajoutez un package à hardware/interfaces, ou ajouter/supprimer des fichiers .hal d'un package existant, vous devez le réexécuter le script pour s'assurer que la bibliothèque partagée générée est à jour.

Par exemple, l'exemple de fichier IFoo.hal doit se trouver dans hardware/interfaces/samples/1.0 L'exemple Le fichier IFoo.hal crée une interface IFoo dans Package samples:

package android.hardware.samples@1.0;
interface IFoo {
    struct Foo {
       int64_t someValue;
       handle  myHandle;
    };

    someMethod() generates (vec<uint32_t>);
    anotherMethod(Foo foo) generates (int32_t ret);
};

Fichiers générés

Les fichiers générés automatiquement dans un package HIDL sont liés dans un seul bibliothèque ayant le même nom que le package (par exemple, android.hardware.samples@1.0). La bibliothèque partagée exporte également un en-tête unique, IFoo.h, qui peut être inclus par les clients et serveurs. Utiliser le compilateur hidl-gen avec IFoo.hal du fichier d'interface comme entrée, le mode lié possède le code suivant, généré automatiquement : :

Fichiers généré par le compilateur

Figure 1 : Fichiers générés par le compilateur.

  • IFoo.h Décrit le IFoo pur interface dans une classe C++ ; il contient les méthodes et types définis dans le Interface IFoo dans le fichier IFoo.hal, traduite en C++ si nécessaire. Ne contient pas d'informations sur le Mécanisme RPC (par exemple, HwBinder) utilisé pour implémenter cette interface. La classe est associée à un espace de noms avec le package et la version (par exemple, ::android::hardware::samples::IFoo::V1_0 Les clients et les serveurs incluez l'en-tête suivant: les clients pour appeler les méthodes sur celui-ci et les serveurs pour de la mise en œuvre de ces méthodes.
  • IHwFoo.h Fichier d'en-tête contenant pour les fonctions qui sérialisent les types de données utilisés dans l'interface. Les développeurs ne doivent jamais inclure son en-tête directement (il ne contient classe).
  • BpHwFoo.h Une classe qui hérite de IFoo et décrit le proxy HwBinder (côté client) ; la mise en œuvre de l'interface. Les développeurs ne doivent jamais se référer à ce cours directement.
  • BnHwFoo.h Une classe contenant un référence à une implémentation de IFoo et décrit Implémentation du bouchon HwBinder (côté serveur) de l'interface. Les développeurs ne doivent jamais se référer directement à ce cours.
  • FooAll.cpp Une classe contenant les des implémentations pour le proxy HwBinder et Bouchon HwBinder. Lorsqu'un client appelle une méthode d'interface, le proxy marshale automatiquement les arguments du client et envoie la transaction au pilote du noyau de liaison, qui transmet la transaction au bouchon (qui appelle ensuite l'implémentation réelle du serveur).

Les fichiers sont structurés de la même manière que les fichiers générés par aidl-cpp (pour en savoir plus, consultez la section "Mode passthrough" dans les Présentation de HIDL, La seule généré automatiquement et indépendant du mécanisme RPC utilisé par HIDL est IFoo.h; tous les autres fichiers sont liés au mécanisme RPC HwBinder utilisé par HIDL. Par conséquent, les implémentations client et serveur ne doivent jamais font directement référence à tout autre élément autre que IFoo. Pour atteindre inclure uniquement IFoo.h et un lien avec le fichier partagé bibliothèque.

Un client ou un serveur qui utilise une interface dans un package doit inclure le paramètre la bibliothèque partagée de ce package dans un (1) des éléments suivants : emplacements:

  • Dans Android.mk: 
    LOCAL_SHARED_LIBRARIES += android.hardware.samples@1.0
  • Dans Android.bp: 
    shared_libs: [
    /* ... */
    "android.hardware.samples@1.0",
],

Vous devrez peut-être inclure d'autres bibliothèques:

libhidlbase Inclut les types de données HIDL standards. À partir d'Android 10, cela contient également tous les symboles précédemment dans libhidltransport et libhwbinder
libhidltransport Gère le transport des appels HIDL via différents mécanismes RPC/IPC. Android 10 rend cette bibliothèque obsolète.
libhwbinder Symboles spécifiques à la liaison. Android 10 abandonne cette bibliothèque.
libfmq IPC de la file d'attente de messages rapide.

Espaces de noms

Fonctions et types HIDL tels que Return<T> et Les Void() sont déclarées dans l'espace de noms ::android::hardware. L'espace de noms C++ d'un package est déterminé par le nom et la version du package. Par exemple, un package mypackage avec la version 1.2 sous hardware/interfaces présente les caractéristiques suivantes:

  • Espace de noms C++ : ::android::hardware::mypackage::V1_2
  • Nom complet de IMyInterface, est: ::android::hardware::mypackage::V1_2::IMyInterface. (IMyInterface est un identifiant qui ne fait pas partie de l'espace de noms.)
  • les types définis dans le fichier types.hal du package ; sont identifiés comme suit: ::android::hardware::mypackage::V1_2::MyPackageType