Google se compromete a impulsar la igualdad racial para las comunidades afrodescendientes. Obtén información al respecto.

Almacén de configuración HAL

Organiza tus páginas con colecciones Guarda y categoriza el contenido según tus preferencias.

En Android 10, ConfigStore HAL usa indicadores de compilación para almacenar valores de configuración en la partición del vendor , y un servicio en la partición del system accede a esos valores mediante HIDL (esto también es cierto en Android 9). Sin embargo, debido al alto consumo de memoria y al uso difícil, ConfigStore HAL ha quedado obsoleto.

ConfigStore HAL permanece en AOSP para admitir particiones de proveedores heredados. En los dispositivos que ejecutan Android 10 o posterior, surfaceflinger lee primero las propiedades del sistema; si no se define ninguna propiedad del sistema para un elemento de configuración en `SurfaceFlingerProperties.sysprop`, `surfaceflinger` recurre a ConfigStore HAL.

Android 8.0 divide el sistema operativo Android monolítico en particiones genéricas ( system.img ) y específicas de hardware ( vendor.img y odm.img ). Como resultado de este cambio, la compilación condicional debe eliminarse de los módulos instalados en la partición del sistema y dichos módulos deben determinar la configuración del sistema en tiempo de ejecución (y comportarse de manera diferente según esa configuración).

ConfigStore HAL proporciona un conjunto de API para acceder a los elementos de configuración de solo lectura que se utilizan para configurar el marco de trabajo de Android. Esta página describe el diseño de ConfigStore HAL (y por qué no se usaron las propiedades del sistema para este propósito); otras páginas en esta sección detallan la interfaz HAL , la implementación del servicio y el uso del lado del cliente , todo usando surfaceflinger como ejemplo. Para obtener ayuda con las clases de interfaz de ConfigStore, consulte Agregar clases de interfaz y elementos .

¿Por qué no usar las propiedades del sistema?

Consideramos usar las propiedades del sistema, pero encontramos varios problemas fundamentales, que incluyen:

  • Límites de longitud de los valores. Las propiedades del sistema tienen límites estrictos en la longitud de sus valores (92 bytes). Además, dado que estos límites se han expuesto directamente a las aplicaciones de Android como macros C, aumentar la longitud puede causar problemas de compatibilidad con versiones anteriores.
  • Sin soporte de tipo. Todos los valores son esencialmente cadenas, y las API simplemente analizan la cadena en un int o bool . Los clientes deben codificar o descodificar otros tipos de datos compuestos (por ejemplo, matriz y estructura) (por ejemplo, "aaa,bbb,ccc" se puede codificar como una matriz de tres cadenas).
  • Sobrescribe. Debido a que las propiedades del sistema de solo lectura se implementan como propiedades de una sola escritura, los proveedores/ODM que desean anular los valores de solo lectura definidos por AOSP deben importar sus propios valores de solo lectura antes que los valores de solo lectura definidos por AOSP. Esto, a su vez, da como resultado que los valores reescribibles definidos por el proveedor sean reemplazados por valores definidos por AOSP.
  • Requerimientos de espacio de direcciones. Las propiedades del sistema ocupan una cantidad relativamente grande de espacio de direcciones en cada proceso. Las propiedades del sistema se agrupan en unidades prop_area con un tamaño fijo de 128 KB, todo lo cual se asigna a un espacio de direcciones de proceso incluso si solo se accede a una propiedad del sistema. Esto puede causar problemas en dispositivos de 32 bits donde el espacio de direcciones es valioso.

Intentamos superar estas limitaciones sin sacrificar la compatibilidad, pero seguíamos preocupados porque las propiedades del sistema no estaban diseñadas para permitir el acceso a elementos de configuración de solo lectura. Finalmente, decidimos que las propiedades del sistema son más adecuadas para compartir algunos elementos actualizados dinámicamente en todo Android en tiempo real, y que existía la necesidad de un nuevo sistema dedicado a acceder a elementos de configuración de solo lectura.

Diseño HAL de ConfigStore

El diseño básico es simple:

Diseño HAL de la tienda de configuración

Figura 1. Diseño HAL de ConfigStore

  • Describa los indicadores de compilación (actualmente utilizados para compilar condicionalmente el marco) en HIDL.
  • Los proveedores y los OEM proporcionan SoC y valores específicos del dispositivo para los indicadores de compilación mediante la implementación del servicio HAL.
  • Modifique el marco para usar el servicio HAL para encontrar el valor de un elemento de configuración en tiempo de ejecución.

Los elementos de configuración a los que actualmente hace referencia el marco se incluyen en un paquete HIDL versionado ( android.hardware.configstore@1.0 ). Los proveedores/OEM proporcionan valores a los elementos de configuración mediante la implementación de interfaces en este paquete, y el marco usa las interfaces cuando necesita obtener un valor para un elemento de configuración.

Consideraciones de Seguridad

Los indicadores de compilación definidos en la misma interfaz se ven afectados por la misma política de SELinux. Si uno o más indicadores de compilación deben tener diferentes políticas de SELinux, deben separarse para otra interfaz . Esto puede requerir una revisión importante del android.hardware.configstore package ya que las interfaces separadas ya no son compatibles con versiones anteriores.