O Android 9 inclui android.hardware.health
HAL 2.0, uma atualização de versão principal do health@1.0 HAL. Este novo HAL tem as seguintes vantagens:
- Separação mais limpa entre a estrutura e o código do fornecedor.
- Descontinua o daemon
healthd
desnecessário. - Maiores graus de liberdade para personalização do fornecedor em relatórios de informações de saúde.
- Mais informações sobre a integridade do dispositivo do que apenas a bateria.
O Android 11 inclui android.hardware.health
HAL 2.1, uma atualização de versão secundária do health@2.0 HAL. Este novo HAL tem as seguintes vantagens:
- Mais fácil de implementar
- Melhor conformidade com APIs HAL 2.0 existentes
- Melhor separação de agudos no código de carregamento fora do modo
- Melhor suporte para o framework indicar a saúde da bateria do dispositivo
O Android 13 inclui android.hardware.health
AIDL HAL, uma conversão de health@2.1 HAL. Este novo HAL tem as seguintes vantagens:
- Remova APIs relacionadas ao carregador não utilizadas
- Remover
StorageAttribute
não utilizado e campos relacionados - Suporte para carregamento de dock.
Requisitos
Dispositivos com Android 9 e Android 10
Os dispositivos lançados com Android 9 devem fornecer o HAL 2.x (e não devem fornecer o HAL 1.0) ou o AIDL HAL. Os dispositivos que não são lançados com o Android 9, mas que planejam atualizar a imagem do fornecedor para a Matriz de compatibilidade do Target Framework versão 3 (lançada no Android 9), devem remover as implementações HAL 1.0 existentes e fornecer o HAL 2.x ou o AIDL HAL.
AOSP inclui várias bibliotecas auxiliares projetadas para ajudá-lo a implementar o HAL 2.0 e a transição do antigo HAL 1.0.
Dispositivos com Android 11 e Android 12
Os dispositivos lançados com Android 11 devem fornecer o HAL 2.1 (e não devem fornecer o HAL 1.0 ou 2.0) ou o AIDL HAL. Os dispositivos que não são lançados com o Android 11, mas planejam atualizar a imagem do fornecedor para a matriz de compatibilidade do Target Framework versão 5 (lançada no Android 11) devem remover as implementações HAL 2.0 existentes e fornecer o HAL 2.1 ou o AIDL HAL. Dispositivos que não iniciam com Android 11 e que não planejam atualizar a imagem do fornecedor também são recomendados para fornecer o HAL 2.1.
AOSP inclui várias bibliotecas auxiliares projetadas para ajudá-lo a implementar o HAL 2.1 e a transição do antigo HAL 1.0.
Dispositivos com Android 13 e superior
Os dispositivos lançados com Android 13 devem fornecer AIDL HAL (e não devem fornecer HIDL HAL). Os dispositivos que não são lançados com o Android 13, mas que planejam atualizar a imagem do fornecedor para a Target Framework Compatibility Matrix versão 7 (lançada no Android 13), devem remover as implementações existentes do HIDL HAL e fornecer o AIDL HAL. Dispositivos que não iniciam com Android 13 e não planejam atualizar a imagem do fornecedor também são recomendados para fornecer o AIDL HAL.
Os dispositivos não devem fornecer o HIDL 1.0 HAL.
AOSP inclui várias bibliotecas auxiliares projetadas para ajudá-lo a implementar o AIDL HAL e a transição dos antigos HALs HIDL.
Terminologia
- health@1.0 : abreviatura de
android.hardware.health@1.0
. Refere-se à versão 1.0 do HIDL HAL de saúde lançada no Android 8.0. - health@2.0 : abreviatura de
android.hardware.health@2.0
. Refere-se à versão 2.0 do HIDL HAL de saúde lançada no Android 9. - health@2.1 : abreviatura de
android.hardware.health@2.1
. Refere-se à versão 2.1 do HIDL HAL de saúde lançada no Android 11. - saúde AIDL HAL : abreviatura de
android.hardware.health
.- A versão 1 é lançada no Android 13.
- charger : executável em execução no modo de carregamento desligado que exibe a animação de carregamento do telefone.
- recuperação : executável em execução no modo de recuperação que deve recuperar informações da bateria.
- healthd : daemon legado em execução no Android que recupera informações relacionadas à saúde e as fornece ao framework.
- storaged : daemon em execução no Android que recupera informações de armazenamento e as fornece ao framework.
Saúde no Android 8.x
No Android 8.x, o componente de integridade funciona conforme detalhado no diagrama a seguir:
Figura 1 . Saúde no Android 8.x.
Neste diagrama:
- Uma (1) chamada de binder e uma (1) chamada de hwbinder são usadas pela estrutura para se comunicar com o hardware.
-
healthd
vincula-se estaticamente alibhealthd_android
,libbatterymonitor
elibbatteryservice
. - health@1.0-impl vincula-se estaticamente a
libhealthd. BOARD
.
Cada placa pode personalizar um libhealthd. BOARD
; é determinado no momento da construção a qual carregador, health@1.0-impl e link de recuperação estão vinculados.
Para outros modos:
Figura 2. Saúde no Android 8.x, carregamento fora do modo e modo de recuperação.
- O carregador está vinculado estaticamente ao
libhealthd. BOARD
,libhealthd_charger
elibbatterymonitor
. - a recuperação está vinculada estaticamente ao
libhealthd. BOARD
elibbatterymonitor
.
Saúde no Android 9
No Android 9, o componente de integridade funciona conforme detalhado no diagrama a seguir:
Figura 3 . Saúde no Android 9.
A estrutura tenta recuperar o serviço health@2.0 de hwservicemanager
. Se falhar, ele chama health@1.0 (no Android 8.x). O caminho do código legado é mantido para que a imagem do sistema Android 9 seja compatível com a imagem do fornecedor do Android 8.x. A estrutura não recupera informações de ambas as HALs porque somente uma versão de serviço (1.0 ou 2.0) pode existir no dispositivo.
Para outros modos:
Figura 4. Saúde no Android 9, carregamento fora do modo e modo de recuperação.
Saúde no Android 11
No Android 11, o componente de integridade funciona conforme detalhado no diagrama a seguir:
[system]
| getService()
V
[health@2.1-service]
| getService(stub=true)
V
[ health@2.0-impl-2.1-<device>.so ]
| | (device-dependent linkage)
V V
+---------Helper libs for impl--------+ [libhealthd.device]
| [libhealthloop (uevent, wakealarm)] |
| [libhealth2impl (IHealth impl) ] |
| [libbatterymonitor (battery) ] |
+-------------------------------------+
Se a implementação do health 2.1 não existir, o sistema retornará ao caminho do código legado conforme descrito nas seções anteriores
Para outros modos:
[ charger ]
| getService() | (legacy code path)
V +-------------------------------------------------+
[health@2.1-service] |
| getService(stub=true) |
V |
[ health@2.0-impl-2.1-<device>.so ] |
| | (device-dependent linkage) |
V V |
+---------Helper libs for impl--------+ [libhealthd.device] |
| [libhealthloop (uevent, wakealarm)] | |
| [libhealth2impl (IHealth impl) ] | <---------------------------------+
| [libbatterymonitor (battery) ] |
+-------------------------------------+
[recovery]
| getService() w/o hwservicemanager
V
[ health@2.0-impl-2.1-<device>.so ]
| | (device-dependent linkage)
V V
+---------Helper libs for impl--------+ [libhealthd.device]
| [libhealthloop (uevent, wakealarm)] |
| [libhealth2impl (IHealth impl) ] |
| [libbatterymonitor (battery) ] |
+-------------------------------------+
Consulte o seguinte diagrama simplificado para diferentes modos:
Figura 5. Infraestrutura HAL 2.1 de saúde.
Saúde no Android 13
No Android 13, o AIDL HAL de saúde é introduzido. O componente de saúde funciona conforme detalhado no diagrama a seguir:
Figura 6. Infraestrutura HAL do AIDL de saúde.
Interface HIDL HAL 2.0
O HAL health@2.0 fornece à estrutura a mesma funcionalidade que o antigo daemon healthd. Ele também fornece APIs semelhantes às que o healthd fornecia anteriormente como um serviço de fichário (ou seja, IBatteryPropertiesRegistrar ).
A interface principal, IHealth , fornece as seguintes funções:
-
registerCallback
, para substituirIBatteryPropertiesRegistrar.registerListener
-
unregisterCallback
, para substituirIBatteryPropertiesRegistrar.unregisterListener
-
update
, para substituirIBatteryPropertiesRegistrar.scheduleUpdate
-
IBatteryPropertiesRegistrar.getProperties
são substituídos pelo seguinte:-
getChargeCounter
-
getCurrentNow
-
getCurrentAverage
-
getCapacity
-
getEnergyCounter
-
getChargeStatus
-
getHealthInfo
-
Além disso, IHealth
fornece as seguintes novas APIs de storaged
para recuperar informações relacionadas ao armazenamento específico do fornecedor:
-
getStorageInfo
-
getDiskStats
Uma nova estrutura, @2.0::HealthInfo
, é retornada por meio de retornos de chamada e getHealthInfo
. Esta estrutura contém todas as informações de integridade do dispositivo disponíveis por meio de health@2.0 HAL, incluindo:
- Informações de carregamento (AC/USB/sem fio, corrente, tensão, etc.)
- Informações da bateria (presença, nível da bateria, corrente, tensão, carga, tecnologia, etc.)
- Informações de armazenamento (informações do dispositivo de armazenamento, estatísticas de disco)
Para obter informações sobre a implementação do serviço Health 2.0, consulte Implementando Health 2.0 .
Interface HIDL HAL 2.1
O health@2.1 HAL suporta carregamento fora do modo e fornece mais informações sobre a bateria.
A interface principal, IHealth , fornece as seguintes funções adicionais
-
getHealthConfig
: para recuperar a configuração deste HAL -
getHealthInfo_2_1
: uma atualização de versão secundária paragetHealthInfo
-
shouldKeepScreenOn
: para determinar se a tela deve ser mantida no modo carregador
Além disso, a implementação de @2.1::IHealth
é necessária para suportar @2.1::IHealthInfoCallback
para suas funções herdadas registerCallback
e unregisterCallback
. A nova interface de retorno de chamada retorna informações de saúde ao cliente usando sua função healthInfoChanged_2_1
em vez da função healthInfoChanged
herdada.
Uma nova estrutura, @2.1::HealthInfo
, é retornada por meio de retornos de chamada e getHealthInfo_2_1
. Esta estrutura contém informações adicionais sobre a integridade do dispositivo disponíveis por meio de health@2.0 HAL, incluindo:
- Nível de capacidade da bateria
- Tempo de carga da bateria totalmente agora (em segundos)
- Capacidade projetada de carga total da bateria (em μAh)
Consulte o seguinte diagrama UML para as classes úteis para a implementação de HAL de integridade:
Figura 7. Diagrama UML Health HAL 2.1.
Para obter informações sobre a implementação do serviço de Saúde 2.1, consulte Implementando Saúde 2.1 .
Interface AIDL HAL versão 1
Mudanças de API
A HAL AIDL versão 1 suporta APIs semelhantes à HAL HIDL 2.1. Em comparação com a interface HIDL 2.1, o seguinte foi alterado na API:
- APIs relacionadas ao carregador introduzidas no HIDL HAL 2.1 não são portadas para o AIDL HAL. Como a funcionalidade de cobrança fora do modo reside apenas na partição
/vendor
, as APIs na interface do fornecedor não são necessárias. Para implementar corretamente o carregamento fora do modo, consulte o carregador abaixo. - O tipo
StorageAttribute
e os campos relacionados são removidos porque não são usados. -
chargerDockOnline
é adicionado aoHealthInfo
para oferecer suporte ao carregamento em dock.
Implementação
Consulte o seguinte diagrama UML para as classes úteis para a implementação de HAL de integridade:
Figura 8. Diagrama UML Health AIDL HAL.
Para obter informações sobre a implementação do serviço AIDL de funcionamento, consulte Implementando Health AIDL HAL .
Recuperação
O Android 13 oferece suporte ao fichário na recuperação. A instalação do serviço Health AIDL para recuperação permite que ele seja executado no modo de recuperação.
Para obter informações sobre como instalar o serviço AIDL de integridade para recuperação, consulte o seguinte:
Carregador
A funcionalidade de carregamento fora do modo foi movida de /system
para /vendor
. Para dispositivos lançados com Android 13, se eles oferecerem suporte ao carregamento no modo desligado, o binário do serviço HAL deverá oferecer suporte ao modo carregador. Para fazer isso, consulte implementação do carregador .
Propriedades do sistema de carregador
As propriedades ro.charger.*
não são mais legíveis pelo binário charger
em /vendor
. Se o seu dispositivo tiver alguma das propriedades do sistema ro.charger.*
definidas, consulte propriedades do sistema para charger .