Implemente a integridade 2.1

Observação: a HAL de saúde 2.1 foi descontinuada. É recomendável implementar a HAL de saúde AIDL diretamente, mesmo em dispositivos lançados antes do Android 11. A documentação para implementação da HAL de saúde 2.1 é mantidos aqui para referência.

No Android 11, todo o código healthd é refatorado no libhealthloop e libhealth2impl, depois modificados para implementar a API health@2.1 HAL Essas duas bibliotecas são vinculadas estaticamente por health@2.0-impl-2.1, a implementação passthrough do Health 2.1. Bibliotecas vinculadas estaticamente permitir que health@2.0-impl-2.1 faça o mesmo trabalho que healthd, como executar healthd_mainloop e sondagem. No init, o health@2.1-service registra uma implementação da interface IHealth para hwservicemanager. Ao fazer upgrade dispositivos com Android 8.x ou 9 imagem de fornecedor e um framework do Android 11, a imagem do fornecedor pode não fornecer o serviço health@2.1. Voltar a compatibilidade com imagens antigas de fornecedores é aplicada pelo programação de descontinuação.

Para garantir a compatibilidade com versões anteriores:

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

Variáveis de build específicas da placa para integridade

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

Na Health@2.1, os fornecedores podem substituir esses dois valores de intervalos de tarefas periódicas no struct healthd_config antes passando para o construtor da classe de implementação de saúde. A integridade classe de implementação deve 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

A health@2.x tem os seguintes clientes:

• carregador. O uso dos códigos libbatterymonitor e healthd_common é unidos em health@2.0-impl.
• recuperação. A vinculação com libbatterymonitor está encapsulada health@2.0-impl. Todas as chamadas para BatteryMonitor são substituídas pelas chamadas para a classe de implementação Health.

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

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

• BateriaService. No Android 9 e versões mais recentes, O BatteryService usa HealthServiceWrapper para determinar se o instância do serviço de saúde padrão de vendor ou usar o comando backup instância de serviço de saúde de healthd. BatteryService então ouve eventos de saúde pelo IHealth.registerCallback.

• Armazenado. No Android 9 e versões mais recentes, O storaged usa libhealthhalutils para determinar se o instância do serviço de saúde padrão de vendor ou usar o comando backup instância de serviço de saúde de healthd. storaged, então detecta eventos de saúde usando IHealth.registerCallback e recupera informações de armazenamento.

Mudanças no SELinux

A HAL health@2.1 inclui as seguintes mudanças de SELinux na plataforma:

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

Para dispositivos com implementação própria, algumas mudanças no SELinux do fornecedor podem ser necessários. 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 de kernel para recuperar informações da bateria:

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

Se esses arquivos estiverem ausentes ou inacessíveis pelo healthd ou pelo serviço padrão (por exemplo, o arquivo é um link simbólico para uma pasta específica do fornecedor que negue acesso devido a uma política do SELinux configurada incorretamente), eles podem a funcionar corretamente. Portanto, outras mudanças no SELinux específicas dos fornecedores podem ser necessário, 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, pode ser opcional. No entanto, evitar comportamentos incorretos de framework resultantes da ausência de interfaces do kernel; é recomendável escolher a dedo CL 1398913 (link em inglês) antes de criar o serviço HAL de saúde 2.1.

Teste

O Android 11 inclui os novos Testes VTS escrita especificamente para a HAL health@2.1. Se um dispositivo declarar HAL health@2.1 no manifesto do dispositivo, ele precisa passar nos testes de VTS correspondentes. Os testes são criados para a instância padrão (para garantir que o dispositivo implementa a HAL corretamente) e a instância de backup (para garantir que healthd continua a funcionar corretamente antes de ser removido).

Requisitos de informações da bateria

A HAL Health 2.0 estabelece um conjunto de requisitos na interface HAL, mas a testes VTS correspondentes são relativamente flexíveis quanto à aplicação delas. No Android 11, novos testes VTS são adicionados para aplicar a requisitos a seguir em dispositivos lançados com Android 11 e mais recentes:

• As unidades de corrente média e intática precisam ser microamplificadores (μA).
• Os sinais de corrente instantânea e média da bateria precisam estar corretos. Especificamente:
  • atual == 0 quando a bateria está em UNKNOWN
  • atual > 0 quando o status da bateria for CHARGING
  • atual <= 0 quando o status da bateria é NOT_CHARGING
  • atual < 0 quando o status da bateria for DISCHARGING
  • Não aplicado quando o status da bateria é FULL
• O status da bateria deve estar correto em relação a uma fonte de energia conectados. Especificamente:
  • o status da bateria deverá ser CHARGING, NOT_CHARGING ou FULL se e somente se houver uma fonte de energia conectada.
  • o status da bateria precisará ser DISCHARGING somente se uma fonte de energia estiver desconectado.

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

• Verifique se a corrente da bateria é informada com a placa e as unidades corretas. 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 corrente de entrada para a bateria.
  • Os valores precisam estar em microamplificadores (μA).
• Verifique se a tensão da bateria é informada em microvolts (μV). Isso inclui 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 mais detalhes, consulte Classe da fonte de alimentação do Linux.