Esta página foi traduzida pela API Cloud Translation.

Implementar Saúde 2.1

No Android 11, todo o código healthd é refatorado em libhealthloop e libhealth2impl e depois modificado para implementar o HAL health@2.1. Essas duas bibliotecas estã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 retroativa com imagens antigas de fornecedores é imposta pelo cronograma de descontinuação .

Para garantir compatibilidade com versões anteriores:

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

Variáveis de construção específicas da placa para saúde

BOARD_PERIODIC_CHORES_INTERVAL_* são variáveis específicas da placa usadas para construir healthd . Como parte da divisão de compilação sistema/fornecedor, valores específicos da placa não podem ser definidos para 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 .

Implementar o serviço Health 2.1

Para obter informações sobre a implementação do 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 está incluído em health@2.0-impl .
recuperação. A ligação ao libbatterymonitor está incluída 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 bateria. BatteryManager.queryProperty(int id) era o único cliente de IBatteryPropertiesRegistrar.getProperty . IBatteryPropertiesRegistrar.getProperty foi fornecido por healthd e lido diretamente /sys/class/power_supply .
Por uma questão de segurança, os aplicativos não podem chamar diretamente o HAL de saúde. No Android 9 e versões posteriores, 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 versões posteriores, BatteryService usa HealthServiceWrapper para determinar se deve usar a instância de serviço de integridade padrão do vendor ou a instância de serviço de integridade de backup de healthd . BatteryService então escuta eventos de integridade por meio de IHealth.registerCallback .
Armazenado. No Android 9 e versões posteriores, storaged usa libhealthhalutils para determinar se deve usar a instância de serviço de integridade padrão do vendor ou a instância de serviço de integridade de backup de healthd . storaged então escuta eventos de integridade por meio de IHealth.registerCallback e recupera informações de armazenamento.

Mudanças no SELinux

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

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

Para dispositivos com implementação própria, 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 da 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 HAL de integridade específica do dispositivo que use libbatterymonitor acessa essas interfaces de 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 pelo healthd ou pelo serviço padrão (por exemplo, o arquivo é um link simbólico para uma pasta específica do fornecedor que nega acesso devido a uma política SELinux configurada incorretamente), eles podem não funcionar corretamente. Portanto, alterações adicionais específicas do fornecedor no SELinux 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 incorretos da estrutura resultantes de interfaces de kernel ausentes, é recomendável escolher CL 1398913 antes de criar o serviço Health HAL 2.1.

Teste

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

Requisitos de informações da bateria

O Health 2.0 HAL estabelece um conjunto de requisitos na interface HAL, mas os testes VTS correspondentes são relativamente relaxados em aplicá-los. No Android 11, novos testes VTS foram adicionados para aplicar os seguintes requisitos em dispositivos lançados com Android 11 e versões posteriores:

As unidades de corrente interna e média da bateria devem ser microamperes (μA).
O sinal da corrente instantânea e média da bateria deve estar correto. Especificamente:
- atual == 0 quando o status da bateria é UNKNOWN
- corrente > 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 se uma fonte de alimentação estiver 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 estiver desconectada.

Se você usar libbatterymonitor em sua implementação e passar valores das interfaces do 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 microamperes (μA).
Certifique-se de que a tensão 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 Linux .