Colis

À quelques exceptions près, les packages d'interface HIDL se trouvent dans hardware/interfaces ou dans le répertoire vendor/ . Le niveau supérieur hardware/interfaces correspond directement à l’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 en un ensemble de fichiers .h et .cpp . À partir de ces fichiers générés automatiquement, une bibliothèque partagée à laquelle les implémentations client/serveur sont liées est créée. Le fichier Android.bp qui construit cette bibliothèque partagée est généré automatiquement par le script hardware/interfaces/update-makefiles.sh . Chaque fois que vous ajoutez un nouveau package à hardware/interfaces , ou que vous ajoutez/supprimez des fichiers .hal à/d'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 d'exemples :

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 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 binderisé contient les fichiers générés automatiquement suivants :

• IFoo.h Décrit l'interface IFoo pure dans une classe C++ ; il contient les méthodes et 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 liés au mécanisme RPC (par exemple, HwBinder ) utilisé pour implémenter cette interface. La classe est dotée d'un espace de noms avec le package et la version, par exemple ::android::hardware::samples::IFoo::V1_0 . Les clients et les serveurs incluent cet en-tête : clients pour appeler des méthodes et 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 directement son en-tête (il ne contient aucune classe).
• BpHwFoo.h . Une classe qui hérite d' IFoo et décrit l'implémentation proxy HwBinder (côté client) de l'interface. Les développeurs ne doivent jamais faire directement référence à cette classe.
• BnHwFoo.h . Une classe qui contient une référence à une implémentation IFoo et décrit l'implémentation stub HwBinder (côté serveur) de l'interface. Les développeurs ne doivent jamais faire directement référence à cette classe.
• FooAll.cpp . Classe qui contient les implémentations du proxy HwBinder et du stub HwBinder . Lorsqu'un client appelle une méthode d'interface, le proxy rassemble automatiquement les arguments du client et envoie la transaction au pilote du noyau de classeur, qui transmet la transaction au stub de l'autre côté (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 plus de détails, voir « Mode Passthrough » dans la présentation HIDL ). Le seul fichier 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 HwBinder RPC utilisé par HIDL. Par conséquent, les implémentations client et serveur ne doivent jamais faire directement référence à autre chose que IFoo . Pour y parvenir, incluez uniquement IFoo.h et créez un lien vers la bibliothèque partagée générée.

Lien vers des bibliothèques partagées

Un client ou un serveur qui utilise n'importe quelle interface d'un package doit inclure la bibliothèque partagée de ce package dans l'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 le nom et la version du package. Par exemple, un package mypackage avec la version 1.2 sous hardware/interfaces a les qualités 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 : ::android::hardware::mypackage::V1_2::MyPackageType