HAL ConfigStore

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 é válido no Android 9). No entanto, devido ao alto consumo de memória e à dificuldade de uso, a HAL ConfigStore foi descontinuada.

A HAL ConfigStore permanece no AOSP para oferecer suporte a partições legadas do fornecedor. Em dispositivos com Android 10 ou mais recente, surfaceflinger lê primeiro as propriedades do sistema. Se nenhuma propriedade do sistema for definida para um item de configuração em "SurfaceFlingerProperties.sysprop", o "surfaceflinger" vai usar a HAL ConfigStore.

O Android 8.0 divide o SO Android monolítico em partições genéricas (system.img) e específicas do 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 tempo de execução (e se comportar de maneira diferente dependendo dessa configuração).

A HAL ConfigStore fornece um conjunto de APIs para acessar itens de configuração somente leitura usados para configurar o framework 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 HAL, a implementação do serviço e o uso do lado do cliente, tudo usando surfaceflinger como exemplo. Para receber ajuda com as classes de interface do 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 nos valores. As propriedades do sistema têm limites rígidos no tamanho 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.
  • Sem suporte a tipos. Todos os valores são essencialmente strings, e as APIs simplesmente analisam a string em um int ou bool. 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 os valores somente leitura definidos pelo AOSP precisam importar os próprios valores somente leitura antes dos valores definidos pelo AOSP. Isso, por sua vez, faz com que os valores reescrevíveis definidos pelo fornecedor sejam substituídos pelos valores definidos pelo AOSP.
  • Requisitos de espaço de endereço. As propriedades do sistema ocupam 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, todas alocadas para um espaço de endereço de processo, mesmo que apenas uma 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 que as propriedades do sistema não foram projetadas para oferecer suporte ao acesso a itens de configuração somente leitura. Decidimos que as propriedades do sistema são mais adequadas para compartilhar alguns itens atualizados dinamicamente em todo o Android em tempo real. Além disso, percebemos que era necessário um novo sistema dedicado ao acesso a itens de configuração somente leitura.

Design da HAL ConfigStore

O design básico é simples:

Design da HAL ConfigStore

Figura 1. Design da HAL ConfigStore

  • Descrever 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 durante a execução.

Os itens de configuração atualmente referenciados 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 receber um valor para um item de configuração.

Considerações sobre segurança

As flags de build definidas na mesma interface são afetadas pela mesma política do SELinux. Se uma ou mais flags de build precisarem ter políticas do SELinux diferentes, elas precisam ser separadas em outra interface. Isso pode exigir uma revisão importante de android.hardware.configstore package, já que as interfaces separadas não são mais compatíveis com versões anteriores.