À partir du 27 mars 2025, nous vous recommandons d'utiliser android-latest-release au lieu de aosp-main pour créer et contribuer à AOSP. Pour en savoir plus, consultez la section Modifications apportées à AOSP.

Cette page a été traduite par l'API Cloud Translation.

HAL ConfigStore

Dans Android 10, ConfigStore HAL utilise des indicateurs de compilation pour stocker les valeurs de configuration dans la partition vendor, et un service de la partition system accède à ces valeurs à l'aide de HIDL (cela vaut également pour Android 9). Toutefois, en raison de la forte consommation de mémoire et de la difficulté d'utilisation, le HAL ConfigStore a été abandonné.

Le HAL ConfigStore reste dans AOSP pour prendre en charge les anciennes partitions du fournisseur. Sur les appareils exécutant Android 10 ou version ultérieure, surfaceflinger lit d'abord les propriétés système. Si aucune propriété système n'est définie pour un élément de configuration dans `SurfaceFlingerProperties.sysprop`, `surfaceflinger` revient au HAL ConfigStore.

Android 8.0 divise le système d'exploitation Android monolithique en partitions génériques (system.img) et spécifiques au matériel (vendor.img et odm.img). En raison de ce changement, la compilation conditionnelle doit être supprimée des modules installés sur la partition système. Ces modules doivent déterminer la configuration du système au moment de l'exécution (et se comporter différemment en fonction de cette configuration).

Le HAL ConfigStore fournit un ensemble d'API permettant d'accéder aux éléments de configuration en lecture seule utilisés pour configurer le framework Android. Cette page décrit la conception de ConfigStore HAL (et pourquoi les propriétés système n'ont pas été utilisées à cette fin). Les autres pages de cette section détaillent l'interface HAL, l'implémentation du service et l'utilisation côté client, en utilisant surfaceflinger comme exemple. Pour obtenir de l'aide concernant les classes d'interface ConfigStore, consultez Ajouter des classes et des éléments d'interface.

Pourquoi ne pas utiliser les propriétés système ?

Nous avons envisagé d'utiliser des propriétés système, mais nous avons rencontré plusieurs problèmes fondamentaux, y compris les suivants :

Limites de longueur des valeurs. La longueur des valeurs des propriétés système est très limitée (92 octets). De plus, comme ces limites ont été directement exposées aux applications Android en tant que macros C, l'augmentation de la longueur peut entraîner des problèmes de rétrocompatibilité.
Aucun type n'est accepté. Toutes les valeurs sont essentiellement des chaînes, et les API analysent simplement la chaîne en int ou bool. Les autres types de données composés (par exemple, tableau et struct) doivent être encodés/décodés par les clients (par exemple, "aaa,bbb,ccc" peut être codé sous la forme d'un tableau de trois chaînes).
Remplacements : Étant donné que les propriétés système en lecture seule sont implémentées en tant que propriétés à écriture unique, les fournisseurs/ODM qui souhaitent remplacer les valeurs en lecture seule définies par l'AOSP doivent importer leurs propres valeurs en lecture seule avant les valeurs en lecture seule définies par l'AOSP. Cela entraîne la substitution des valeurs réinscriptibles définies par le fournisseur par les valeurs définies par l'AOSP.
Exigences concernant l'espace d'adressage. Les propriétés système occupent une quantité relativement importante d'espace d'adressage dans chaque processus. Les propriétés système sont regroupées dans des unités prop_area de taille fixe (128 Ko), qui sont toutes allouées à un espace d'adressage de processus, même si une seule propriété système y est consultée. Cela peut entraîner des problèmes sur les appareils 32 bits où l'espace d'adressage est précieux.

Nous avons tenté de surmonter ces limites sans sacrifier la compatibilité, mais nous avons continué à craindre que les propriétés système ne soient pas conçues pour permettre l'accès aux éléments de configuration en lecture seule. Nous avons finalement décidé que les propriétés système étaient plus adaptées au partage de quelques éléments mis à jour de manière dynamique sur l'ensemble d'Android en temps réel, et qu'un nouveau système était nécessaire pour accéder aux éléments de configuration en lecture seule.

Conception de la HAL ConfigStore

La conception de base est simple :

Conception de la HAL Configstore

Figure 1 : Conception de la HAL ConfigStore

Décrivez les indicateurs de compilation (actuellement utilisés pour compiler conditionnellement le framework) dans HIDL.
Les fournisseurs et les OEM fournissent des valeurs spécifiques au SoC et à l'appareil pour les indicateurs de compilation en implémentant le service HAL.
Modifiez le framework pour qu'il utilise le service HAL afin de trouver la valeur d'un élément de configuration au moment de l'exécution.

Les éléments de configuration actuellement référencés par le framework sont inclus dans un package HIDL versionné (android.hardware.configstore@1.0). Les fournisseurs/OEM fournissent des valeurs aux éléments de configuration en implémentant des interfaces dans ce package, et le framework utilise les interfaces lorsqu'il a besoin d'obtenir une valeur pour un élément de configuration.

Points à noter concernant la sécurité

Les indicateurs de compilation définis dans la même interface sont affectés par la même règle SELinux. Si une ou plusieurs options de compilation doivent avoir des règles SELinux différentes, elles doivent être séparées dans une autre interface. Cela peut nécessiter une révision majeure de android.hardware.configstore package, car les interfaces séparées ne sont plus rétrocompatibles.