Implemente a integridade 2.1

Observação: o HAL do Health 2.1 foi descontinuado. É recomendável implementar o HAL de AIDL de integridade diretamente, mesmo em dispositivos lançados antes do Android 11. A documentação para implementar o HAL do Health 2.1 é mantida aqui para referência.

No Android 11, todo o código healthd é reestruturado em libhealthloop e libhealth2impl, depois modificado para implementar a HAL health@2.1. Essas duas bibliotecas são vinculadas de forma estática por health@2.0-impl-2.1, a implementação de passagem do Google Fit 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 fazer pesquisas. Na inicialização, o health@2.1-service registra uma implementação da interface IHealth para hwservicemanager. Ao fazer upgrade de dispositivos com uma imagem do fornecedor Android 8.x ou 9 e um framework do Android 11, a imagem do fornecedor pode não fornecer o serviço health@2.1. A compatibilidade retroativa com imagens antigas do fornecedor é aplicada pelo programa de descontinuação.

Para garantir a compatibilidade com versões anteriores:

1. healthd registra IHealth em hwservicemanager, apesar de ser um daemon do sistema. IHealth é adicionado ao manifesto do sistema com o nome de instância "backup".
2. O framework e o storaged se comunicam com o healthd por meio de hwbinder em vez de binder.
3. O código do framework e do storaged é alterado para buscar a instância "padrão", se disponível, depois "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 o IHealth/padrão estiver amplamente disponível e as imagens do fornecedor do Android 8.1 forem descontinuadas, o IHealth/backup e o healthd poderão ser descontinuados. Para mais detalhes, consulte Suspensão de uso do health@1.0.

Variáveis de build específicas da placa para o healthd

BOARD_PERIODIC_CHORES_INTERVAL_* são variáveis específicas da placa usadas para criar healthd. Como parte da divisão de build do sistema/fabricante, os valores específicos da placa não podem ser definidos para módulos do sistema. Esses valores eram substituídos na função descontinuada healthd_board_init.

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

Implementar o serviço Health 2.1

Para 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. A vinculação a libbatterymonitor é envolvida em health@2.0-impl. Todas as chamadas para BatteryMonitor são substituídas por chamadas para a classe de implementação Health.

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

  Por motivos de segurança, os apps não podem chamar o HAL de integridade diretamente. No Android 9 e versões mais recentes, o serviço de vinculação IBatteryPropertiesRegistrar é fornecido por BatteryService em vez de healthd. O BatteryService delega a chamada à HAL de saúde para extrair as informações solicitadas.

• BatteryService. No Android 9 e versões mais recentes, BatteryService usa HealthServiceWrapper para determinar se vai usar a instância de serviço de integridade padrão de vendor ou a instância de serviço de integridade backup de healthd. Em seguida, BatteryService detecta eventos de integridade usando IHealth.registerCallback.

• Storaged. No Android 9 e versões mais recentes, storaged usa libhealthhalutils para determinar se é necessário usar a instância do serviço de integridade padrão de vendor ou a instância de serviço de integridade de backup de healthd. Em seguida, storaged detecta eventos de integridade usando IHealth.registerCallback e recupera informações de armazenamento.

Mudanças no SELinux

O HAL health@2.1 inclui as seguintes mudanças do SELinux na plataforma:

• O método android.hardware.health@2.1-service foi adicionado ao file_contexts.

Para dispositivos com implementação própria, algumas mudanças no SELinux do fornecedor 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 da bateria:

• /sys/class/power_supply/*/capacity_level (adicionado no app Saúde 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 na versão 2.1 do app Saúde)
• /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 na versão 2.1 do app Saúde)
• /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 use libbatterymonitor acessa essas interfaces do kernel por padrão, a menos que seja substituída no construtor da classe de implementação de integridade.

Se esses arquivos estiverem ausentes ou inacessíveis em healthd ou no serviço padrão (por exemplo, se o arquivo for um link simbólico para uma pasta específica do fornecedor que nega o acesso devido à configuração incorreta da política SELinux), eles podem não funcionar corretamente. Assim, podem ser necessárias outras mudanças no SELinux, mesmo que a implementação padrão seja usada.

Algumas interfaces do kernel usadas no Google Fit 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 incorretos do framework resultantes de interfaces do kernel ausentes, recomendamos escolher CL 1398913 antes de criar o serviço HAL de saúde 2.1.

Teste

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

Requisitos de informações sobre a bateria

A HAL do Health 2.0 declara um conjunto de requisitos na interface da HAL, mas os testes VTS correspondentes são relativamente flexíveis na aplicação deles. No Android 11, novos testes VTS foram adicionados para aplicar os seguintes requisitos em dispositivos lançados com o Android 11 e versões mais recentes:

• As unidades de corrente média e intática precisam ser microamplificadores (μA).
• O sinal de corrente instantânea e média da bateria precisa estar correto. Mais especificamente:
  • current == 0 quando o status da bateria é UNKNOWN
  • current > 0 quando o status da bateria é CHARGING
  • atual <= 0 quando o status da bateria é NOT_CHARGING
  • atual < 0 quando o status da bateria é DISCHARGING
  • Não é aplicada quando o status da bateria é FULL
• O status da bateria precisa estar correto, independentemente de uma fonte de energia estar conectada ou não. Mais especificamente:
  • o status da bateria precisará ser CHARGING, NOT_CHARGING ou FULL somente se uma fonte de energia estiver conectada;
  • O status da bateria precisa ser DISCHARGING se e somente se uma fonte de energia estiver desconectada.

Se você usar libbatterymonitor na implementação e transmitir valores de interfaces do kernel, verifique se os nós sysfs estão informando os valores corretos:

• Verifique se a corrente da bateria é informada com o sinal e as unidades corretos. Isso inclui os seguintes nós do sysfs:
  • /sys/class/power_supply/*/current_avg
  • /sys/class/power_supply/*/current_max
  • /sys/class/power_supply/*/current_now
  • Valores positivos indicam a corrente de entrada na bateria.
  • Os valores precisam estar em microampéres (μA).
• Verifique se a tensão da bateria é informada em microvolts (μV). Isso inclui os seguintes nós sysfs:
  • /sys/class/power_supply/*/voltage_max
  • /sys/class/power_supply/*/voltage_now
  • A implementação padrão da HAL divide voltage_now por 1.000 e informa valores em milivolts (mV). Consulte @1.0::HealthInfo.

Para saber mais, consulte Classe de fonte de alimentação do Linux.