Implementando a Saúde 2.1

No Android 11, todo o código healthd é refatorado em libhealthloop e libhealth2impl e, em seguida, modificado para implementar o health@2.1 HAL. Essas duas bibliotecas são vinculadas estaticamente por health@2.0-impl-2.1 , a implementação de passagem do health 2.1. As bibliotecas vinculadas estaticamente permitem que health@2.0-impl-2.1 faça o mesmo trabalho que healthd , como executar healthd_mainloop e polling. No init, o health@2.1-service registra uma implementação da interface IHealth para hwservicemanager . Ao atualizar dispositivos com uma imagem de fornecedor do Android 8.x ou 9 e uma estrutura do Android 11, a imagem do fornecedor pode não fornecer o serviço health@2.1. A compatibilidade com versões anteriores com imagens de fornecedores antigos é imposta pelo cronograma de descontinuação .

Para garantir a compatibilidade com versões anteriores:

  1. healthd registra IHealth para hwservicemanager apesar de ser um daemon do sistema. IHealth é adicionado ao manifesto do sistema, com o nome da instância "backup".
  2. A estrutura e o storaged se comunicam com healthd via hwbinder em vez de binder .
  3. O código para framework e storaged são alterados para buscar a instância "default" se disponível, então "backup".
    • O código do cliente C++ usa a lógica definida em libhealthhalutils .
    • O código do cliente Java usa a lógica definida em HealthServiceWrapper .
  4. Depois que IHealth/default estiver amplamente disponível e as imagens de fornecedores do Android 8.1 forem preteridas, IHealth/backup e healthd poderão ser preteridos. Para obter mais detalhes, consulte Descontinuando health@1.0 .

Variáveis ​​de compilação específicas da placa para healthd

BOARD_PERIODIC_CHORES_INTERVAL_* são variáveis ​​específicas da placa usadas para construir healthd . Como parte da divisão de construção do sistema/fornecedor, os valores específicos da placa não podem ser definidos para os módulos do sistema. Esses valores costumavam ser substituídos na função obsoleta healthd_board_init .

No health@2.1, os fornecedores podem substituir esses dois valores de intervalo de tarefas periódicas na estrutura healthd_config antes de passar para o construtor da classe de implementação de integridade. A classe de implementação de integridade deve herdar de android::hardware::health::V2_1::implementation::Health .

Implementando o serviço Health 2.1

Para obter informações sobre como implementar o serviço Health 2.1, consulte hardware/interfaces/health/2.1/README.md .

Clientes de saúde

health@2.x tem os seguintes clientes:

  • carregador . O uso do código libbatterymonitor e healthd_common é encapsulado em health@2.0-impl .
  • recuperação . O link para libbatterymonitor é encapsulado em health@2.0-impl . Todas as chamadas para BatteryMonitor são substituídas por chamadas para a classe de implementação Health .

  • Gerenciador de baterias . BatteryManager.queryProperty(int id) era o único cliente de IBatteryPropertiesRegistrar.getProperty . IBatteryPropertiesRegistrar.getProperty foi fornecido por healthd e lido diretamente /sys/class/power_supply .

    Como consideração de segurança, os aplicativos não podem chamar diretamente o HAL de integridade. No Android 9 e superior, o serviço de fichário IBatteryPropertiesRegistrar é fornecido por BatteryService em vez de healthd . BatteryService delega a chamada ao HAL de integridade para recuperar as informações solicitadas.

  • Serviço de Bateria . No Android 9 e superior, BatteryService usa HealthServiceWrapper para determinar se deve usar a instância de serviço de integridade padrão do vendor ou usar a instância de serviço de integridade de backup de healthd . BatteryService então escuta eventos de saúde via IHealth.registerCallback .

  • Armazenado . No Android 9 e superior, storaged usa libhealthhalutils para determinar se deve usar a instância de serviço de integridade padrão do vendor ou usar a instância de serviço de integridade de backup de healthd . storaged então escuta eventos de integridade por meio IHealth.registerCallback e recupera informações de armazenamento.

Alterações do SELinux

O health@2.1 HAL inclui as seguintes alterações do SELinux na plataforma:

  • Adiciona android.hardware.health@2.1-service a file_contexts .

Para dispositivos com sua própria implementação, algumas alterações do fornecedor SELinux podem ser necessárias. Exemplo:

# device/<manufacturer>/<device>/sepolicy/vendor/hal_health_default.te
# Add device specific permissions to hal_health_default domain, especially
# if it links to board-specific libhealthd or implements storage APIs.

Interfaces do kernel

O daemon healthd e a implementação padrão android.hardware.health@2.0-impl-2.1 acessam as seguintes interfaces do kernel para recuperar informações sobre a bateria:

  • /sys/class/power_supply/*/capacity_level (adicionado no health 2.1)
  • /sys/class/power_supply/*/capacity
  • /sys/class/power_supply/*/charge_counter
  • /sys/class/power_supply/*/charge_full
  • /sys/class/power_supply/*/charge_full_design (adicionado no health 2.1)
  • /sys/class/power_supply/*/current_avg
  • /sys/class/power_supply/*/current_max
  • /sys/class/power_supply/*/current_now
  • /sys/class/power_supply/*/cycle_count
  • /sys/class/power_supply/*/health
  • /sys/class/power_supply/*/online
  • /sys/class/power_supply/*/present
  • /sys/class/power_supply/*/status
  • /sys/class/power_supply/*/technology
  • /sys/class/power_supply/*/temp
  • /sys/class/power_supply/*/time_to_full_now (adicionado no health 2.1)
  • /sys/class/power_supply/*/type
  • /sys/class/power_supply/*/voltage_max
  • /sys/class/power_supply/*/voltage_now

Qualquer implementação de HAL de integridade específica do dispositivo que usa libbatterymonitor acessa essas interfaces de kernel por padrão, a menos que substituída no construtor da classe de implementação de integridade.

Se esses arquivos estiverem ausentes ou inacessíveis a partir do healthd ou do serviço padrão (por exemplo, o arquivo é um link simbólico para uma pasta específica do fornecedor que nega acesso devido à configuração incorreta da política do SELinux), eles podem não funcionar corretamente. Portanto, alterações adicionais do SELinux específicas do fornecedor podem ser necessárias, mesmo que a implementação padrão seja usada.

Algumas interfaces de kernel usadas no Health 2.1, como /sys/class/power_supply/*/capacity_level e /sys/class/power_supply/*/time_to_full_now , podem ser opcionais. No entanto, para evitar comportamentos de estrutura incorretos resultantes de interfaces de kernel ausentes, é recomendável selecionar CL 1398913 antes de criar o serviço HAL 2.1 de integridade.

Teste

O Android 11 inclui novos testes VTS escritos especificamente para o health@2.1 HAL. Se um dispositivo declara health@2.1 HAL no manifesto do dispositivo, ele deve passar nos testes VTS correspondentes. Os testes são escritos para a instância padrão (para garantir que o dispositivo implemente a HAL corretamente) e para a instância de backup (para garantir que healthd continue funcionando corretamente antes de ser removido).

Requisitos de informações da bateria

O Health 2.0 HAL declara um conjunto de requisitos na interface HAL, mas os testes VTS correspondentes são relativamente relaxados ao aplicá-los. No Android 11, novos testes VTS são adicionados para aplicar os seguintes requisitos em dispositivos iniciados com Android 11 e superior:

  • As unidades de corrente instantânea e média da bateria devem ser microamps (μA).
  • O sinal de corrente instantânea e média da bateria deve estar correto. Especificamente:
    • atual == 0 quando o status da bateria é UNKNOWN
    • atual > 0 quando o status da bateria está CHARGING
    • atual <= 0 quando o status da bateria é NOT_CHARGING
    • corrente < 0 quando o status da bateria está DISCHARGING
    • Não aplicado quando o status da bateria está FULL
  • O status da bateria deve estar correto em relação a uma fonte de alimentação conectada ou não. Especificamente:
    • o status da bateria deve ser CHARGING , NOT_CHARGING ou FULL se e somente se uma fonte de alimentação estiver conectada;
    • o status da bateria deve ser DISCHARGING se e somente se uma fonte de alimentação for desconectada.

Se você usar libbatterymonitor em sua implementação e passar valores de interfaces de kernel, certifique-se de que os nós sysfs estejam relatando valores corretos:

  • Certifique-se de que a corrente da bateria seja informada com o sinal e as unidades corretos. Isso inclui os seguintes nós sysfs:
    • /sys/class/power_supply/*/current_avg
    • /sys/class/power_supply/*/current_max
    • /sys/class/power_supply/*/current_now
    • Valores positivos indicam corrente de entrada na bateria.
    • Os valores devem estar em microamps (μA).
  • Certifique-se de que a voltagem da bateria seja informada em microvolts (μV). Isso inclui os seguintes nós sysfs:
    • /sys/class/power_supply/*/voltage_max
    • /sys/class/power_supply/*/voltage_now
    • Observe que a implementação HAL padrão divide voltage_now por 1000 e relata valores em milivolts (mV). Consulte @1.0::HealthInfo .

Para obter detalhes, consulte Classe de fonte de alimentação do Linux .