HAL du magasin de configuration

Android 8.0 divise l'OS Android monolithique dans générique ( system.img ) et spécifiques au matériel ( vendor.img et odm.img partitions). À 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 dans cette section en détail l' interface HAL , la mise en surfaceflinger œuvre de services et utilisation côté client , tout en utilisant surfaceflinger comme un exemple. Pour de l' aide avec les classes d'interface ConfigStore, voir Ajout Classes et objets 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 nous avons trouvé 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 compatibilité descendante.
  • Aucune prise en charge des types. Toutes les valeurs sont essentiellement des chaînes, et les API analysent simplement la chaîne dans un int ou bool . D' autres types de données composite (par exemple, réseau et struct) doivent être codées / décodées par les clients (par exemple, "aaa,bbb,ccc" peuvent être codées comme une rangée de trois cordes).
  • Écrase. É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 l'AOSP.
  • Espace d'adressage requis. Les propriétés système occupent une quantité relativement importante d'espace d'adressage dans chaque processus. Propriétés du système sont regroupés dans prop_area unités avec une taille fixe de 128 Ko, dont la totalité est alloué à un espace d'adressage du processus , même si une seule propriété système en cours d' accès. Cela peut causer 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 avons continué à craindre que les propriétés du système ne soient 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 de ConfigStore HAL

La conception de base est simple :

Conception HAL du magasin de configuration

Figure 1. Conception ConfigStore HAL

  • Décrire les indicateurs de construction (actuellement utilisés pour la compilation conditionnelle du 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 pour 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 cadre sont inclus dans un paquet 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 drapeaux de construction devraient avoir des politiques de SELinux, ils doivent être séparés à une autre interface. Cela peut nécessiter une révision majeure de android.hardware.configstore package que les interfaces séparées ne sont plus rétrocompatible.