HAL hérités

Un HAL définit une interface standard que les fournisseurs de matériel doivent implémenter, ce qui permet à Android d'être indépendant des implémentations de pilotes de niveau inférieur. L'utilisation d'un HAL vous permet d'implémenter des fonctionnalités sans affecter ni modifier le système de niveau supérieur. Cette page décrit l'ancienne architecture, qui n'est plus prise en charge depuis Android 8.0. Pour Android 8.0 et versions ultérieures, veuillez consulter la présentation de HAL .

Composants HAL

Figure 1. Composants HAL

Vous devez implémenter le HAL (et le pilote) correspondant au matériel spécifique fourni par votre produit. Les implémentations HAL sont généralement intégrées dans des modules de bibliothèque partagés (fichiers .so ), mais comme Android n'impose pas d'interaction standard entre une implémentation HAL et les pilotes de périphérique, vous pouvez faire ce qui convient le mieux à votre situation. Cependant, pour permettre au système Android d'interagir correctement avec votre matériel, vous devez respecter le contrat défini dans chaque interface HAL spécifique au matériel.

Pour garantir que les HAL ont une structure prévisible, chaque interface HAL spécifique au matériel possède des propriétés définies dans hardware/libhardware/include/hardware/hardware.h . Cette interface permet au système Android de charger les versions correctes de vos modules HAL de manière cohérente. Une interface HAL se compose de deux composants : des modules et des appareils.

Modules HAL

Un module représente votre implémentation HAL packagée, qui est stockée sous forme de bibliothèque partagée ( .so file ). Le fichier d'en-tête hardware/libhardware/include/hardware/hardware.h définit une structure ( hw_module_t ) qui représente un module et contient des métadonnées telles que la version, le nom et l'auteur du module. Android utilise ces métadonnées pour rechercher et charger correctement le module HAL.

De plus, la structure hw_module_t contient un pointeur vers une autre structure, hw_module_methods_t , qui contient un pointeur vers une fonction ouverte pour le module. Cette fonction ouverte est utilisée pour initier la communication avec le matériel pour lequel le HAL sert d'abstraction. Chaque HAL spécifique au matériel étend généralement la structure générique hw_module_t avec des informations supplémentaires pour cet élément matériel spécifique. Par exemple, dans le HAL de la caméra, la structure camera_module_t contient une structure hw_module_t ainsi que d'autres pointeurs de fonction spécifiques à la caméra :

typedef struct camera_module {
    hw_module_t common;
    int (*get_number_of_cameras)(void);
    int (*get_camera_info)(int camera_id, struct camera_info *info);
} camera_module_t;

Lorsque vous implémentez un HAL et créez la structure du module, vous devez le nommer HAL_MODULE_INFO_SYM . Exemple tiré du HAL audio du Nexus 9 :

struct audio_module HAL_MODULE_INFO_SYM = {
    .common = {
        .tag = HARDWARE_MODULE_TAG,
        .module_api_version = AUDIO_MODULE_API_VERSION_0_1,
        .hal_api_version = HARDWARE_HAL_API_VERSION,
        .id = AUDIO_HARDWARE_MODULE_ID,
        .name = "NVIDIA Tegra Audio HAL",
        .author = "The Android Open Source Project",
        .methods = &hal_module_methods,
    },
};

Appareils HAL

Un appareil résume le matériel de votre produit. Par exemple, un module audio peut contenir un périphérique audio principal, un périphérique audio USB ou un périphérique audio Bluetooth A2DP.

Un périphérique est représenté par la structure hw_device_t . Semblable à un module, chaque type de périphérique définit une version détaillée du hw_device_t générique qui contient des pointeurs de fonction pour des fonctionnalités spécifiques du matériel. Par exemple, le type de structure audio_hw_device_t contient des pointeurs de fonction vers les opérations du périphérique audio :

struct audio_hw_device {
    struct hw_device_t common;

    /**
     * used by audio flinger to enumerate what devices are supported by
     * each audio_hw_device implementation.
     *
     * Return value is a bitmask of 1 or more values of audio_devices_t
     */
    uint32_t (*get_supported_devices)(const struct audio_hw_device *dev);
  ...
};
typedef struct audio_hw_device audio_hw_device_t;

En plus de ces propriétés standard, chaque interface HAL spécifique au matériel peut définir davantage de ses propres fonctionnalités et exigences. Pour plus de détails, consultez la documentation de référence HAL ainsi que les instructions individuelles pour chaque HAL.

Construire des modules HAL

Les implémentations HAL sont intégrées dans des fichiers de modules ( .so ) et sont liées dynamiquement par Android le cas échéant. Vous pouvez créer vos modules en créant des fichiers Android.mk pour chacune de vos implémentations HAL et en pointant vers vos fichiers sources. En général, vos bibliothèques partagées doivent être nommées dans un format spécifique afin qu'elles puissent être trouvées et chargées correctement. Le schéma de dénomination varie légèrement d'un module à l'autre, mais suit le modèle général : <module_type>.<device_name> .

HAL hérité

Le terme Legacy HAL fait largement référence à tous les HAL antérieurs à Android 8.0 (obsolètes dans Android 8). La majeure partie des interfaces du système Android (caméra, audio, capteurs, etc.) sont définies sous « hardware/libhardware/include/hardware » et ont une version approximative et un ABI à peu près stable. Quelques sous-systèmes (dont le Wi-Fi, la couche d'interface radio et le Bluetooth) ont d'autres interfaces non standardisées dans `libhardware_legacy` ou intercalées dans la base de code. Les anciens HAL n'ont jamais fourni de garanties de stabilité strictes.