Colis

À quelques exceptions près, les packages d'interface HIDL se trouvent dans hardware/interfaces ou le répertoire vendor/. Le niveau supérieur hardware/interfaces est mappé directement sur l'espace de noms du package android.hardware. La version est un sous-répertoire de 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 fichiers générés automatiquement, une bibliothèque partagée avec laquelle les implémentations client/serveur sont associées est créée. Le fichier Android.bp qui compile cette bibliothèque partagée est généré automatiquement par le script hardware/interfaces/update-makefiles.sh. Chaque fois que vous ajoutez un package à hardware/interfaces, ou que vous ajoutez/supprimez des fichiers .hal à/depuis un package existant, vous devez réexécuter le script pour vous 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 de fichier IFoo.hal crée une interface IFoo dans le 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 associés à une seule bibliothèque partagée portant le même nom que le package (par exemple, android.hardware.samples@1.0). La bibliothèque partagée exporte également un seul en-tête, IFoo.h, qui peut être inclus par les clients et les serveurs. En utilisant le compilateur hidl-gen avec le fichier d'interface IFoo.hal comme entrée, le mode lié contient les fichiers générés automatiquement suivants:

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

• IFoo.h : décrit l'interface IFoo pure dans une classe C++. Il contient les méthodes et les types définis dans l'interface IFoo dans le fichier IFoo.hal, traduits en types C++ si nécessaire. Ne contient pas de détails sur le mécanisme RPC (par exemple, HwBinder) utilisé pour implémenter cette interface. La classe est associée au nom d'espace avec le package et la version, par exemple ::android::hardware::samples::IFoo::V1_0. Les clients et les serveurs incluent cet en-tête: les clients pour appeler des méthodes dessus et les serveurs pour implémenter ces méthodes.
• IHwFoo.h : fichier d'en-tête contenant des déclarations pour les fonctions qui sérialisent les types de données utilisés dans l'interface. Les développeurs ne doivent jamais inclure cet en-tête directement (il ne contient aucune classe).
• BpHwFoo.h : classe qui hérite de IFoo et décrit l'implémentation du proxy HwBinder (côté client) de l'interface. Les développeurs ne doivent jamais faire référence directement à cette classe.
• BnHwFoo.h : classe qui contient une référence à une implémentation IFoo et décrit l'implémentation du bouchon HwBinder (côté serveur) de l'interface. Les développeurs ne doivent jamais faire référence directement à cette classe.
• FooAll.cpp : classe contenant les implémentations du proxy HwBinder et du bouchon HwBinder. Lorsqu'un client appelle une méthode d'interface, le proxy marshalle automatiquement les arguments du client et envoie la transaction au pilote du kernel du liaisonneur, qui la transmet au bouchon de l'autre côté (qui appelle ensuite l'implémentation du serveur).

Les fichiers sont structurés de manière similaire aux fichiers générés par aidl-cpp (pour en savoir plus, consultez la section "Mode passthrough" dans la présentation de HIDL). Le seul fichier généré automatiquement qui est 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 faire référence directement à autre chose qu'à IFoo. Pour ce faire, n'incluez que IFoo.h et associez-le à la bibliothèque partagée générée.

Lien vers les bibliothèques partagées

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

• Dans Android.mk:

  LOCAL_SHARED_LIBRARIES += android.hardware.samples@1.0

• Dans Android.bp:

  shared_libs: [
      /* ... */
      "android.hardware.samples@1.0",
  ],

Bibliothèques supplémentaires que vous devrez peut-être inclure:

Espaces de noms

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

• L'espace de noms C++ est ::android::hardware::mypackage::V1_2.
• Le nom complet de IMyInterface dans ce package est ::android::hardware::mypackage::V1_2::IMyInterface. (IMyInterface est un identifiant, et 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