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 agnostique quant aux 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 HAL .

Composants HAL

Figure 1. Composants HAL

Vous devez implémenter le HAL correspondant (et le pilote) pour le 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 des 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 a 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 périphériques.

Modules HAL

Un module représente votre implémentation HAL packagée, qui est stockée sous la forme d'une 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 trouver 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 HAL sert d'abstraction. Chaque HAL spécifique au matériel étend généralement la structure hw_module_t générique avec des informations supplémentaires pour ce matériel spécifique. Par exemple, dans la couche 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 de la HAL audio 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 des opérations de 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 source. 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 nommage varie légèrement d'un module à l'autre, mais suit le schéma général suivant : <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 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 (y compris le Wi-Fi, la couche d'interface radio et Bluetooth) ont d'autres interfaces non standardisées dans `libhardware_legacy` ou dispersées dans la base de code. Les HAL hérités n'ont jamais fourni de garanties de stabilité absolues.