No Android 10, a HAL ConfigStore usa flags de build para armazenar
valores de configuração na partição vendor
, e um serviço na partição system
acessa esses valores usando HIDL. Isso também é verdadeiro no Android 9. No entanto, devido ao alto
consumo de memória e à dificuldade de uso, a HAL ConfigStore foi descontinuada.
A HAL ConfigStore continua no AOSP para oferecer suporte a partições legados do fornecedor. Em
dispositivos com Android 10 ou versões mais recentes, o surfaceflinger
lê as propriedades do sistema primeiro. Se nenhuma propriedade do sistema for definida para um item
de configuração em "SurfaceFlingerProperties.sysprop", "surfaceflinger" retorna à
HAL ConfigStore.
O Android 8.0 divide o SO Android monolítico em partições genéricas
(system.img
) e específicas de hardware (vendor.img
e
odm.img
). Como resultado dessa
mudança, a compilação condicional precisa ser removida dos módulos instalados na
partição do sistema e esses módulos precisam determinar a configuração do
sistema no momento da execução (e se comportar de maneira diferente dependendo dessa configuração).
O HAL do ConfigStore fornece um conjunto de APIs para acessar itens de configuração
somente leitura usados para configurar o framework do Android. Esta página descreve
o design da HAL ConfigStore (e por que as propriedades do sistema não foram usadas para essa
finalidade). Outras páginas nesta seção detalham a
interface da HAL, a
implementação
do serviço e o
uso do lado do cliente,
todas usando surfaceflinger
como exemplo. Para ajuda com classes de interface
ConfigStore, consulte
Como adicionar classes
e itens de interface.
Por que não usar propriedades do sistema?
Consideramos usar propriedades do sistema, mas encontramos vários problemas fundamentais, incluindo:
- Limites de tamanho para os valores. As propriedades do sistema têm limites rígidos no comprimento dos valores (92 bytes). Além disso, como esses limites foram expostos diretamente aos apps Android como macros C, aumentar o comprimento pode causar problemas de compatibilidade com versões anteriores.
- Nenhum tipo de suporte. Todos os valores são essencialmente strings, e
as APIs simplesmente analisam a string em um
int
oubool
. Outros tipos de dados compostos (por exemplo, matriz e struct) precisam ser codificados/decodificados pelos clientes. Por exemplo,"aaa,bbb,ccc"
pode ser codificado como uma matriz de três strings. - Substituições. Como as propriedades do sistema somente leitura são implementadas como propriedades de gravação única, os fornecedores/ODMs que querem substituir valores somente leitura definidos pelo AOSP precisam importar os próprios valores somente leitura antes dos valores somente leitura definidos pelo AOSP. Isso, por sua vez, faz com que os valores regraváveis definidos pelo fornecedor sejam substituídos por valores definidos pelo AOSP.
- Requisitos de espaço de endereços. As propriedades do sistema usam uma
quantidade relativamente grande de espaço de endereço em cada processo. As propriedades do sistema são
agrupadas em unidades
prop_area
com um tamanho fixo de 128 KB, que são alocadas em um espaço de endereço de processo, mesmo que apenas uma única propriedade do sistema esteja sendo acessada. Isso pode causar problemas em dispositivos de 32 bits em que o espaço de endereço é precioso.
Tentamos superar essas limitações sem sacrificar a compatibilidade, mas continuamos preocupados com o fato de as propriedades do sistema não terem sido projetadas para oferecer suporte ao acesso de itens de configuração somente leitura. Eventualmente, decidimos que as propriedades do sistema são mais adequadas para compartilhar alguns itens atualizados dinamicamente em todo o Android em tempo real e que havia uma necessidade de um novo sistema dedicado ao acesso de itens de configuração somente leitura.
Design do HAL ConfigStore
O design básico é simples:
Figura 1. Design da HAL ConfigStore
- Descreve flags de build (atualmente usadas para compilar condicionalmente o framework) em HIDL.
- Os fornecedores e OEMs fornecem valores específicos do SoC e do dispositivo para flags de build implementando o serviço HAL.
- Modifique o framework para usar o serviço HAL e encontrar o valor de um item de configuração no momento da execução.
Os itens de configuração referenciados atualmente pelo framework estão incluídos em um
pacote HIDL com versão (android.hardware.configstore@1.0
).
Os fornecedores/OEMs fornecem valores aos itens de configuração implementando
interfaces nesse pacote, e o framework usa as interfaces quando precisa
extrair um valor para um item de configuração.
Considerações sobre segurança
Os flags de build definidos na mesma interface são afetados pela mesma política
do SELinux. Se um ou mais flags de build tiverem políticas SELinux diferentes,
eles precisam ser separados para outra interface. Isso pode exigir
uma revisão importante do android.hardware.configstore package
, já que as
interfaces separadas não são mais compatíveis com versões anteriores.