ConfigStore HAL

Dans Android 10, ConfigStore HAL utilise des indicateurs de build 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). Cependant, en raison d'une consommation de mémoire élevée et d'une utilisation difficile, ConfigStore HAL est obsolète.

Le HAL ConfigStore reste dans AOSP pour prendre en charge les partitions des anciens fournisseurs. Sur les appareils exécutant Android 10 ou version ultérieure, surfaceflinger lit d'abord les propriétés du 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 et 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 ConfigStore HAL fournit un ensemble d'API pour 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) ; d'autres pages de cette section détaillent l' interface HAL , l'implémentation du service et l'utilisation côté client , le tout en utilisant surfaceflinger comme exemple. Pour obtenir de l'aide sur les classes d'interface ConfigStore, consultez Ajout de classes et d'éléments d'interface .

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

Nous avons envisagé d'utiliser les propriétés du système, mais avons découvert plusieurs problèmes fondamentaux, notamment :

• 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 compatibilité ascendante.
• Aucune prise en charge des types. Toutes les valeurs sont essentiellement des chaînes et les API analysent simplement la chaîne en un int ou bool . D'autres types de données composés (par exemple, array et struct) doivent être codé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).
• Écrase. Étant donné que les propriétés système en lecture seule sont implémentées en tant que propriétés en é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 à son tour le remplacement des valeurs réinscriptibles définies par le fournisseur par les valeurs définies par l'AOSP.
• Répondre aux besoins en espace. 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 en unités prop_area d'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 est accessible. 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 limitations sans sacrifier la compatibilité, mais nous restions préoccupés par le fait que les propriétés du système n'étaient pas conçues pour prendre en charge l'accès aux éléments de configuration en lecture seule. Finalement, nous avons décidé que les propriétés du système étaient mieux adaptées au partage de quelques éléments mis à jour dynamiquement sur tout Android en temps réel, et qu'il existait un besoin pour un nouveau système dédié à l'accès aux éléments de configuration en lecture seule.

Conception de ConfigStore HAL

La conception de base est simple :

Figure 1. Conception de ConfigStore HAL

• Décrivez les indicateurs de build (actuellement utilisés pour compiler conditionnellement le framework) dans HIDL.
• Les fournisseurs et les OEM fournissent des valeurs spécifiques au SoC et aux appareils pour les indicateurs de build en implémentant le service HAL.
• Modifiez l'infrastructure pour utiliser le service HAL afin de rechercher 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.

Considérations de sécurité

Les indicateurs de build définis dans la même interface sont affectés par la même politique SELinux. Si un ou plusieurs indicateurs de build doivent avoir des politiques 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.