Dans Android 10, la HAL ConfigStore 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 est également vrai dans Android 9). Toutefois, en raison de sa forte consommation de mémoire et de sa difficulté d'utilisation, la HAL ConfigStore a été abandonnée.
La HAL ConfigStore reste dans AOSP pour prendre en charge les partitions de fournisseur héritées. Sur les appareils exécutant Android 10 ou une 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 à la HAL ConfigStore.
Android 8.0 divise l'OS Android monolithique en partitions génériques (system.img) et spécifiques au matériel (vendor.img et odm.img). Par conséquent, la compilation conditionnelle doit être supprimée des modules installés dans la partition système, et ces modules doivent déterminer la configuration du système au moment de l'exécution (et se comporter différemment selon cette configuration).
La 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 la HAL ConfigStore (et pourquoi les propriétés système n'ont pas été utilisées à cette
fin). D'autres pages de cette section décrivent
l'interface HAL,
l'implémentation
du service, et
l'utilisation côté client,
en utilisant surfaceflinger comme exemple. Pour obtenir de l'aide sur les classes d'interface ConfigStore, consultez la section
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, dont les suivants :
- Limites de longueur des valeurs. Les propriétés système ont des limites strictes quant à la longueur de leurs valeurs (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é.
- Aucune prise en charge des types. Toutes les valeurs sont essentiellement des chaînes, et les API analysent simplement la chaîne en
intoubool. Les autres types de données composites (par exemple, les tableaux et les structures) doivent être encodés/décodés par les clients (par exemple,"aaa,bbb,ccc"peut être codé sous forme de tableau de trois chaînes). - Écrasements. É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 AOSP doivent importer leurs propres valeurs en lecture seule avant les valeurs en lecture seule définies par AOSP. Par conséquent, les valeurs réinscriptibles définies par le fournisseur sont remplacées par les valeurs définies par 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_aread'une taille fixe de 128 Ko, qui sont toutes allouées à un espace d'adressage de processus, même si une seule propriété système y est accessible. Cela peut poser 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é à nous inquiéter du fait que les propriétés système n'étaient pas conçues pour prendre en charge 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 dans l'ensemble d'Android en temps réel, et qu'un nouveau système dédié à l'accès aux éléments de configuration en lecture seule était nécessaire.
Conception de la HAL ConfigStore
La conception de base est simple :
Figure 1. Conception de la HAL ConfigStore
- Décrivez les indicateurs de compilation (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 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 doit 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 stratégie SELinux. Si un ou plusieurs indicateurs de compilation doivent avoir des stratégies SELinux différentes, ils doivent être séparés dans une autre interface. Cela peut nécessiter une révision majeure du android.hardware.configstore package, car les interfaces séparées ne sont plus rétrocompatibles.