ConfigStore HAL

Dans Android 10, le HAL ConfigStore utilise des options 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 (ce qui est également vrai dans Android 9). Toutefois, en raison d'une consommation de mémoire élevée et d'une utilisation difficile, le HAL pour ConfigStore est obsolète.

Le HAL ConfigStore reste dans AOSP pour prendre en charge les anciennes partitions de fournisseurs. Sur les appareils équipés d'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" utilise l'HAL de 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). En raison de ce changement, la compilation conditionnelle doit être supprimée des modules installés dans 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 du HAL ConfigStore (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, le tout 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 avons détecté plusieurs problèmes fondamentaux, y compris:

  • Limites de longueur pour les valeurs. La longueur des valeurs des propriétés système est limitée (92 octets). De plus, comme ces limites ont été directement exposées aux applications Android en tant que macros C, augmenter la longueur peut entraîner des problèmes de rétrocompatibilité.
  • Aucun type compatible. 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ées (tableau et structure, par exemple) 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).
  • Écrasements. Étant donné que les propriétés système en lecture seule sont implémentées en tant que propriétés en écriture seule, les fournisseurs/OEM 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. Par conséquent, les valeurs réécrites définies par le fournisseur sont remplacées par des 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 en unités prop_area d'une taille fixe de 128 ko, toutes allouées à un espace d'adressage de processus, même si une seule propriété système y est accessible. Cela peut entraîner des problèmes sur les appareils 32 bits, où l'espace d'adressage est précieux.

Nous avons essayé de surmonter ces limites sans sacrifier la compatibilité, mais nous restions préoccupés par le fait que les propriétés système n'étaient 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 sont mieux adaptées au partage de quelques éléments mis à jour dynamiquement sur 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 du HAL ConfigStore

La conception de base est simple:

Conception HAL pour Configstore

Figure 1 : Conception du HAL ConfigStore

  • Décrire les options de compilation (actuellement utilisées pour compiler le framework de manière conditionnelle) 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.
  • Modifier le framework pour utiliser 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 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 règle SELinux. Si un ou plusieurs indicateurs de compilation doivent avoir des règles SELinux différentes, ils doivent être séparés 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.