Descripción general de la configuración

El AOSP ofrece las siguientes opciones para almacenar información de configuración en un dispositivo:

• Propiedades del sistema
• Configuración del dispositivo de inicio anticipado
• Propiedades de la capa de abstracción de hardware (HAL)
• Archivos XML de configuración del sistema
• Superposiciones de recursos (estáticas y en tiempo de ejecución)

Propiedades del sistema

Las propiedades del sistema son pares clave-valor de cadena almacenados en el diccionario global de build.prop. Las propiedades del sistema son recursos de todo el sistema que son fáciles de usar y tienen una sobrecarga de rendimiento baja. Cuando usas propiedades del sistema, no necesitas usar la comunicación entre procesos (IPC) incluso si una propiedad del sistema se comparte entre varios procesos. Sin embargo, las propiedades del sistema son similares a las variables globales y pueden ser perjudiciales si se usan de forma inadecuada. El uso inadecuado de las propiedades del sistema puede provocar problemas como vulnerabilidades de seguridad y que los usuarios no puedan acceder a las apps. Antes de usar las propiedades del sistema para almacenar información de configuración, considera las otras opciones de configuración.

Para obtener más información sobre las propiedades del sistema, consulta Cómo agregar propiedades del sistema.

Configuración del dispositivo de inicio anticipado

En Android 17 y versiones posteriores, el servicio init_dev_config proporciona compatibilidad con la configuración del dispositivo y la inicialización de propiedades del sistema. Este mecanismo arquitectónico dinámico se ejecuta automáticamente durante el inicio anticipado.

Cuando una sola imagen del sistema o del proveedor debe admitir varias variantes de hardware, los valores de configuración no siempre se pueden codificar de forma rígida en el tiempo de compilación. El servicio init_dev_config se ejecuta durante la fase early-init, justo antes de apexd-bootstrap, lo que permite que los proveedores inspeccionen el estado del hardware (por ejemplo, desde argumentos del cargador de arranque, particiones montadas de forma anticipada o tablas de configuración de hardware) y, luego, inicialicen de forma dinámica las propiedades del sistema antes de que se inicialicen los servicios y las bibliotecas dependientes.

Integración y ciclo de vida del servicio

El servicio init_dev_config se define de forma predeterminada en el init.rc del sistema y se ejecuta de forma síncrona durante early-init, antes de apexd-bootstrap. Los integradores no necesitan declarar un nuevo servicio de init.

En cambio, el servicio existente usa la expansión de propiedades en su ruta ejecutable, lo que desacopla la declaración del servicio del sistema del archivo binario del proveedor. Los integradores especifican la ruta de acceso a su binario del proveedor con la propiedad ro.vendor.init_dev_config.path y lo configuran con las etiquetas y los permisos de SELinux requeridos.

Requisitos de implementación para proveedores

Para realizar la integración con init_dev_config, haz lo siguiente:

1. Configura la ruta de acceso binaria del proveedor en el momento de la compilación con PRODUCT_VENDOR_PROPERTIES. La ruta de acceso binaria proporcionada debe ser una ruta de acceso válida a un archivo binario instalado en el sistema:

   PRODUCT_VENDOR_PROPERTIES += \
       ro.vendor.init_dev_config.path=/vendor/bin/init_dev_config
   

   Si esta propiedad no está configurada, init omite la ejecución del servicio y el inicio continúa con normalidad.

2. Debido a que el servicio se ejecuta antes de apexd-bootstrap, las bibliotecas de Bionic completas proporcionadas por APEX aún no están disponibles. En Android.bp, establece bootstrap: true:

   rust_binary {
       name: "init_dev_config",
       vendor: true,
       srcs: ["src/main.rs"],
       rustlibs: [
           "librustutils",
       ],
       bootstrap: true,
   }
   

3. Escribe la lógica del servicio para detectar la variante de hardware y establecer las propiedades del sistema adecuadas:

   use rustutils::system_properties;
   
   fn main() {
       let hw_sku = read_hardware_sku();
   
       // Dynamically initialize vendor-specific properties:
       let display_type = match hw_sku {
           1 => "oled",
           _ => "lcd",
       };
       system_properties::write("vendor.display.panel_type", display_type)
           .expect("Failed to set vendor display property");
   }
   

4. Etiqueta el objeto binario del proveedor con init_dev_config_exec:

    /vendor/bin/init_dev_config u:object_r:init_dev_config_exec:s0
   

5. Otorga permiso al dominio init_dev_config para establecer los tipos de propiedad requeridos:

    set_prop(init_dev_config, vendor_my_sku_prop)
   

Para obtener información sobre el uso de init_dev_config para la activación y la inhabilitación de APEX, consulta Selección de APEX del proveedor durante el inicio.

Propiedades de HAL

Cuando la fuente de verdad de una configuración proviene de un componente de hardware en un dispositivo, la HAL del hardware debe proporcionar la información de ese componente. Define un nuevo método HAL en el HAL existente para acceder a la configuración. Para obtener más información sobre cómo desarrollar un HAL, consulta AIDL para HALs.

Archivos XML de configuración del sistema

Cuando los datos de configuración son estáticos pero complejos (estructurados), considera usar XML o algún otro formato similar para los datos de configuración. Asegúrate de que el esquema del archivo permanezca estable. En el caso de los archivos XML, puedes usar xsd_config para mantener el esquema estable y aprovechar un analizador de XML generado automáticamente.

Superposición de recursos

Puedes usar superposiciones de recursos para personalizar un producto. Existen dos tipos de superposiciones de recursos:

• Superposición de recursos estándar que se usa para personalizar un producto en el tiempo de compilación. Para obtener información sobre las superposiciones de recursos estándar, consulta Cómo personalizar la compilación con superposiciones de recursos.

• La superposición de recursos en tiempo de ejecución (RRO) se usa para cambiar los valores de los recursos de un paquete objetivo en tiempo de ejecución. Por ejemplo, una app instalada en la imagen del sistema podría cambiar su comportamiento según el valor de un recurso. En lugar de codificar de forma rígida el valor del recurso en el tiempo de compilación, un RRO instalado en una partición diferente puede cambiar los valores de los recursos de la app en el tiempo de ejecución. Para obtener más información sobre las RRO, consulta Cómo cambiar el valor de los recursos de una app en el tiempo de ejecución.