O AOSP oferece as seguintes opções para armazenar informações de configuração em um dispositivo:
- Propriedades do sistema
- Configuração do dispositivo de inicialização antecipada
- Propriedades da camada de abstração de hardware (HAL)
- Arquivos XML de configuração do sistema
- Sobreposições de recursos (estáticas e no momento da execução)
Propriedades do sistema
As propriedades do sistema são pares de chave-valor de string armazenados no dicionário global build.prop. As propriedades do sistema são recursos em todo o sistema que são fáceis de usar e têm uma baixa sobrecarga de desempenho. Ao usar propriedades do sistema, não é necessário usar a comunicação entre processos (IPC, na sigla em inglês), mesmo que uma propriedade do sistema seja compartilhada em vários processos. No entanto, as propriedades do sistema são semelhantes às variáveis globais e podem ser prejudiciais quando usadas de maneira inadequada. O uso indevido de propriedades do sistema pode
resultar em problemas como vulnerabilidades de segurança e apps inacessíveis
para os usuários. Antes de usar propriedades do sistema para armazenar informações de configuração, considere as outras opções.
Para mais informações sobre propriedades do sistema, consulte Adicionar propriedades do sistema
Configuração do dispositivo de inicialização antecipada
No Android 17 e versões mais recentes, o serviço init_dev_config oferece suporte à
configuração do dispositivo e à inicialização de propriedades do sistema. Esse mecanismo arquitetônico dinâmico é executado automaticamente na inicialização antecipada.
Quando uma única imagem de sistema ou fornecedor precisa ser compatível com várias variantes de hardware, os valores de configuração nem sempre podem ser codificados no momento da criação. O serviço
init_dev_config é executado durante a fase early-init, logo antes de
apexd-bootstrap, permitindo que os fornecedores inspecionem o estado do hardware (por exemplo, de
argumentos do carregador de inicialização, partições montadas no início ou tabelas de configuração
de hardware) e inicializem dinamicamente as propriedades do sistema antes que os serviços
e bibliotecas dependentes sejam inicializados.
Integração e ciclo de vida do serviço
O serviço init_dev_config é definido por padrão no sistema
init.rc e executado de forma síncrona durante early-init, antes de
apexd-bootstrap. Os integradores não precisam declarar um novo serviço init.
Em vez disso, o serviço atual usa a expansão de propriedade no caminho executável,
desvinculando a declaração de serviço do sistema do binário do fornecedor. Os integradores
especificam o caminho para o binário do fornecedor usando a propriedade
ro.vendor.init_dev_config.path e o configuram com os
rótulos e permissões do SELinux necessários.
Requisitos de implementação do fornecedor
Para integrar com init_dev_config:
Configure o caminho binário do fornecedor no tempo de build usando
PRODUCT_VENDOR_PROPERTIES. O caminho binário fornecido precisa ser um caminho válido para um binário instalado no sistema:PRODUCT_VENDOR_PROPERTIES += \ ro.vendor.init_dev_config.path=/vendor/bin/init_dev_configSe essa propriedade não estiver definida, o
initvai pular a execução do serviço e a inicialização vai continuar normalmente.Como o serviço é executado antes do
apexd-bootstrap, as bibliotecas bionic completas fornecidas pelo APEX ainda não estão disponíveis. EmAndroid.bp, definabootstrap: true:rust_binary { name: "init_dev_config", vendor: true, srcs: ["src/main.rs"], rustlibs: [ "librustutils", ], bootstrap: true, }Escreva a lógica de serviço para detectar a variante de hardware e defina as propriedades do sistema adequadas:
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"); }Marque o binário do fornecedor com
init_dev_config_exec:/vendor/bin/init_dev_config u:object_r:init_dev_config_exec:s0Conceda a permissão de domínio
init_dev_configpara definir os tipos de propriedade necessários:set_prop(init_dev_config, vendor_my_sku_prop)
Para informações sobre como usar init_dev_config para ativação e desativação do APEX,
consulte Seleção do APEX do fornecedor na inicialização.
Propriedades da HAL
Quando a fonte de verdade de uma configuração é um componente de hardware em um dispositivo, a HAL do hardware precisa fornecer as informações desse componente. Defina um novo método HAL no HAL atual para acessar a configuração. Para mais informações sobre o desenvolvimento de uma HAL, consulte AIDL para HALs.
Arquivos XML de configuração do sistema
Quando os dados de configuração são estáticos, mas complicados (estruturados), considere usar XML ou outros formatos semelhantes. Verifique se o esquema de arquivo permanece estável. Para arquivos XML, use
xsd_config
para manter o esquema estável e aproveitar um analisador XML
gerado automaticamente.
Sobreposição de recursos
É possível usar sobreposições de recursos para personalizar um produto. Há dois tipos de substituições de recursos:
Sobreposição de recursos padrão usada para personalizar um produto no tempo de build. Para informações sobre sobreposições de recursos padrão, consulte Como personalizar o build com sobreposições de recursos.
A sobreposição de recursos no momento da execução (RRO) é usada para mudar os valores de recursos de um pacote de destino no tempo de execução. Por exemplo, um app instalado na imagem do sistema pode mudar o comportamento com base no valor de um recurso. Em vez de codificar o valor do recurso no momento da build, uma RRO instalada em uma partição diferente pode mudar os valores dos recursos do app no ambiente de execução. Para mais informações sobre RROs, consulte Mudar o valor dos recursos de um app no momento da execução.