HAL de ConfigStore

En Android 10, la HAL de ConfigStore usa marcas de compilación para almacenar valores de configuración en la partición vendor, y un servicio en la partición system accede a esos valores con HIDL (esto también se aplica a Android 9). Sin embargo, debido al alto consumo de memoria y a la dificultad de uso, se dio de baja la HAL de ConfigStore.

La HAL de ConfigStore permanece en AOSP para admitir particiones heredadas del proveedor. En los dispositivos que ejecutan Android 10 o versiones posteriores, surfaceflinger primero lee las propiedades del sistema. Si no se define ninguna propiedad del sistema para un elemento de configuración en `SurfaceFlingerProperties.sysprop`, `surfaceflinger` recurre a la HAL de ConfigStore.

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

El HAL de ConfigStore proporciona un conjunto de APIs para acceder a elementos de configuración de solo lectura que se usan para configurar el framework de Android. En esta página, se describe el diseño de la HAL de ConfigStore (y por qué no se usaron propiedades del sistema para este propósito). En otras páginas de esta sección, se detallan la interfaz de HAL, la implementación del servicio y el uso del cliente, todo con surfaceflinger como ejemplo. Para obtener ayuda con las clases de interfaz de ConfigStore, consulta Cómo agregar elementos y clases de interfaz.

¿Por qué no usar propiedades del sistema?

Consideramos usar propiedades del sistema, pero encontramos varios problemas fundamentales, incluidos los siguientes:

• Límites de longitud en los valores. Las propiedades del sistema tienen límites estrictos en la longitud de sus valores (92 bytes). Además, como estos límites se expusieron directamente a las apps para Android como macros de C, aumentar la longitud puede causar problemas de compatibilidad con versiones anteriores.
• No se admite el tipo. Todos los valores son básicamente cadenas, y las APIs simplemente analizan la cadena en un int o bool. Los clientes deben codificar y decodificar otros tipos de datos compuestos (por ejemplo, array y struct). Por ejemplo, "aaa,bbb,ccc" se puede codificar como un array de tres cadenas.
• Reemplazos. Dado que las propiedades del sistema de solo lectura se implementan como propiedades de escritura única, los proveedores o los ODM que deseen anular los valores de solo lectura definidos por el AOSP deben importar sus propios valores de solo lectura antes que los valores de solo lectura definidos por el AOSP. Esto, a su vez, hace que los valores reescribibles definidos por el proveedor se anulen con los valores definidos por el AOSP.
• Requisitos 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 de prop_area con un tamaño fijo de 128 KB, todas las cuales se asignan a un espacio de direcciones de proceso, incluso si solo se accede a una sola propiedad del sistema en él. Esto puede causar problemas en dispositivos de 32 bits, en los que el espacio de direcciones es valioso.

Intentamos superar estas limitaciones sin sacrificar la compatibilidad, pero seguíamos preocupados por el hecho de que las propiedades del sistema no se diseñaron para admitir 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 de forma dinámica 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 del HAL de ConfigStore

El diseño básico es simple:

Figura 1: Diseño del HAL de ConfigStore

• Describe las marcas de compilación (actualmente se usan para compilar el framework de forma condicional) en HIDL.
• Los proveedores y los OEM proporcionan valores específicos del SoC y del dispositivo para las marcas de compilación implementando el servicio HAL.
• Modifica el framework para usar el servicio HAL y encontrar el valor de un elemento de configuración durante el tiempo de ejecución.

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

Consideraciones de seguridad

Las marcas de compilación definidas en la misma interfaz se ven afectadas por la misma política de SELinux. Si una o más marcas de compilación deben tener políticas de SELinux diferentes, se deben separar en otra interfaz. Esto puede requerir una revisión importante de android.hardware.configstore package, ya que las interfaces separadas ya no son retrocompatibles.