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 do fornecedor 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:
-
healthd
registraIHealth
parahwservicemanager
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 comhealthd
viahwbinder
em vez debinder
. - O código para framework e
storaged
são alterados 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
.
- O código do cliente C++ usa a lógica definida em
- Depois que IHealth/default estiver amplamente disponível e as imagens de fornecedores do Android 8.1 forem descontinuadas, IHealth/backup e
healthd
poderão ser descontinuadas. Para obter mais detalhes, consulte Deprecating 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
.
Em 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 de 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
ehealthd_common
é agrupado emhealth@2.0-impl
. - recuperação . A vinculação ao
libbatterymonitor
é agrupada emhealth@2.0-impl
. Todas as chamadas paraBatteryMonitor
são substituídas por chamadas para a classe de implementaçãoHealth
. BatteryManager .
BatteryManager.queryProperty(int id)
era o único cliente deIBatteryPropertiesRegistrar.getProperty
.IBatteryPropertiesRegistrar.getProperty
foi fornecido porhealthd
e lido diretamente/sys/class/power_supply
.Como uma consideração de segurança, os aplicativos não têm permissão para chamar o HAL de saúde diretamente. No Android 9 e superior, o serviço de fichário
IBatteryPropertiesRegistrar
é fornecido porBatteryService
em vez dehealthd
.BatteryService
delega a chamada ao HAL de integridade para recuperar as informações solicitadas.BatteryService . No Android 9 e superior,
BatteryService
usaHealthServiceWrapper
para determinar se deve usar a instância de serviço de integridade padrão dovendor
ou usar a instância de serviço de integridade de backup dehealthd
.BatteryService
então escuta eventos de saúde viaIHealth.registerCallback
.Armazenado . No Android 9 e superior,
storaged
usalibhealthhalutils
para determinar se deve usar a instância de serviço de integridade padrão dovendor
ou usar a instância de serviço de integridade de backup dehealthd
.storaged
então escuta eventos de integridade viaIHealth.registerCallback
e recupera informações de armazenamento.
Mudanças no SELinux
O health@2.1 HAL inclui as seguintes alterações do SELinux na plataforma:
- Adiciona
android.hardware.health@2.1-service
afile_contexts
.
Para dispositivos com sua própria implementação, algumas alterações do 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 na integridade 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 integridade 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 na integridade 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 seja substituída no construtor de classe de implementação de integridade.
Se esses arquivos estiverem ausentes ou inacessíveis 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 à política SELinux mal configurada), 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 declarar health@2.1 HAL no manifesto do dispositivo, ele deverá 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 para a instância de backup (para garantir que healthd
continue a funcionar 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 em aplicá-los. No Android 11, novos testes VTS foram adicionados para impor os seguintes requisitos em dispositivos lançados com Android 11 e superior:
- As unidades de corrente instantânea 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
- atual > 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 aplicado quando o status da bateria está
FULL
- atual == 0 quando o status da bateria é
- O status da bateria deve estar correto independentemente de uma fonte de alimentação estar ou não conectada. Especificamente:
- o status da bateria deve ser
CHARGING
,NOT_CHARGING
, ouFULL
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.
- o status da bateria deve ser
Se você usar libbatterymonitor
em sua implementação e passar os valores das interfaces do kernel, verifique se os nós sysfs estão relatando os 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 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 1.000 e relata os valores em milivolts (mV). Consulte @1.0::HealthInfo .
-
Para obter detalhes, consulte Classe de fonte de alimentação do Linux .