ConfigStore HAL

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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 ). À la suite 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 selon 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 , toutes 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 système, mais nous avons constaté plusieurs problèmes fondamentaux, notamment :

  • Limites de longueur sur les valeurs. Les propriétés système ont des limites strictes sur 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 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é comme un tableau de trois chaînes).
  • Remplace. É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. Ceci, à son tour, entraîne le remplacement des valeurs réinscriptibles définies par le fournisseur par les valeurs définies par AOSP.
  • Répondre aux exigences d'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 dans des 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 causer des problèmes sur les périphériques 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 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 pour partager 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 HAL de ConfigStore

La conception de base est simple :

Conception HAL de Configstore

Figure 1. Conception HAL de ConfigStore

  • Décrire les drapeaux de construction (actuellement utilisés pour compiler conditionnellement le framework) dans HIDL.
  • Les fournisseurs et les OEM fournissent des valeurs SoC et spécifiques à l'appareil pour les indicateurs de construction en implémentant le service HAL.
  • Modifiez le framework pour utiliser le service HAL afin de trouver la valeur d'un élément de configuration lors 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 drapeaux de construction définis dans la même interface sont affectés par la même politique SELinux. Si un ou plusieurs indicateurs de construction doivent avoir des politiques SELinux différentes, ils doivent être séparés sur 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.