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.
- Desaprova o daemon
healthd
desnecessário. - Maiores graus de liberdade para personalização de fornecedores em relatórios de informações de saúde.
- Mais informações sobre a saúde 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 as APIs HAL 2.0 existentes
- Melhor separação de agudos no código de carregamento fora do modo
- Melhor suporte para a estrutura para indicar a integridade 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 as APIs relacionadas ao carregador não utilizadas
- Remova
StorageAttribute
não utilizado e campos relacionados - Suporte de carregamento dock.
Requisitos
Dispositivos com Android 9 e Android 10
Os dispositivos iniciados com o Android 9 devem fornecer o 2.x HAL (e não devem fornecer o 1.0 HAL) ou o AIDL HAL. Os dispositivos que não são iniciados com o Android 9, mas que planejam atualizar a imagem do fornecedor para o Target Framework Compatibility Matrix Versão 3 (lançado no Android 9) devem remover as implementações 1.0 HAL existentes e fornecer o 2.x HAL ou o AIDL HAL.
O AOSP inclui várias bibliotecas auxiliares projetadas para ajudá-lo a implementar o 2.0 HAL e a transição do antigo 1.0 HAL.
Dispositivos com Android 11 e Android 12
Os dispositivos iniciados com o Android 11 devem fornecer o 2.1 HAL (e não devem fornecer o 1.0 ou 2.0 HAL) ou o AIDL HAL. Os dispositivos que não são iniciados com o Android 11, mas que planejam atualizar a imagem do fornecedor para a Target Framework Compatibility Matrix Versão 5 (lançada no Android 11) devem remover as implementações de HAL 2.0 existentes e fornecer o HAL 2.1 ou o AIDL HAL. Os dispositivos que não iniciam com o Android 11 e não planejam atualizar a imagem do fornecedor também são recomendados para fornecer a HAL 2.1.
O AOSP inclui várias bibliotecas auxiliares projetadas para ajudá-lo a implementar o 2.1 HAL e a transição do antigo 1.0 HAL.
Dispositivos com Android 13 e superior
Dispositivos iniciados com Android 13 devem fornecer o AIDL HAL (e não devem fornecer HIDL HAL). Os dispositivos que não são iniciados com o Android 13, mas que planejam atualizar a imagem do fornecedor para a Target Framework Compatibility Matrix Versão 7 (lançado no Android 13) devem remover as implementações de HIDL HAL existentes e fornecer o AIDL HAL. Os dispositivos que não iniciam com o 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.
O AOSP inclui várias bibliotecas auxiliares projetadas para ajudá-lo a implementar o AIDL HAL e a transição dos antigos HIDL HALs.
Terminologia
- health@1.0 : abreviatura de
android.hardware.health@1.0
. Refere-se à saúde HIDL HAL versão 1.0 lançada no Android 8.0. - health@2.0 : abreviatura de
android.hardware.health@2.0
. Refere-se à saúde HIDL HAL versão 2.0 lançada no Android 9. - health@2.1 : abreviatura de
android.hardware.health@2.1
. Refere-se à saúde HIDL HAL versão 2.1 lançada no Android 11. - saúde AIDL HAL : abreviatura de
android.hardware.health
.- A versão 1 é lançada no Android 13.
- carregador : executável rodando no modo off de carregamento que exibe a animação de carregamento do telefone.
- recovery : executável rodando em modo de recuperação que deve recuperar as 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 estaticamente alibhealthd_android
,libbatterymonitor
elibbatteryservice
. - health@1.0-impl vincula estaticamente a
libhealthd. BOARD
.
Cada placa pode personalizar uma libhealthd. BOARD
; é determinado no momento da construção para qual carregador, health@1.0-impl e link de recuperação.
Para outros modos:
Figura 2. Saúde no Android 8.x, carregamento fora do modo e modo de recuperação
- O carregador vincula estaticamente ao
libhealthd. BOARD
,libhealthd_charger
elibbatterymonitor
. - recovery vincula estaticamente a
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 do 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 apenas 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, modo de carregamento e recuperação fora do modo
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 de 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) ] |
+-------------------------------------+
Veja 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 integridade funciona conforme detalhado no diagrama a seguir:
Figura 6. Infraestrutura AIDL HAL de saúde
Interface HIDL HAL 2.0
A HAL health@2.0 fornece à estrutura a mesma funcionalidade que o daemon healthd antigo. Ele também fornece APIs semelhantes às que 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, a IHealth
fornece as seguintes novas APIs para storaged
para recuperar informações relacionadas ao armazenamento específico do fornecedor:
-
getStorageInfo
-
getDiskStats
Um novo struct, @2.0::HealthInfo
, é retornado por meio de callbacks e getHealthInfo
. Esta estrutura contém todas as informações de integridade do dispositivo disponíveis por meio do 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 do disco)
Para obter informações sobre como implementar o serviço Health 2.0, consulte Implementing Health 2.0 .
Interface HIDL HAL 2.1
O health@2.1 HAL suporta carregamento em modo desligado 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 de carregador
Além disso, a implementação de @2.1::IHealth
é necessária para dar suporte a @2.1::IHealthInfoCallback
para suas funções herdadas registerCallback
e unregisterCallback
. A nova interface de retorno de chamada retorna informações de integridade de integridade para o cliente usando sua função healthInfoChanged_2_1
em vez da função herdada healthInfoChanged
.
Um novo struct, @2.1::HealthInfo
, é retornado por meio de callbacks e getHealthInfo_2_1
. Este struct contém informações adicionais sobre a integridade do dispositivo disponíveis por meio do health@2.0 HAL, incluindo:
- Nível de capacidade da bateria
- Tempo de carga da bateria para completo agora (em segundos)
- Capacidade de projeto de carga total da bateria (em μAh)
Veja o seguinte diagrama UML para as classes úteis para a implementação de HAL de integridade:
Figura 7. Diagrama UML do Health HAL 2.1
Para obter informações sobre como implementar o serviço Health 2.1, consulte Implementing Health 2.1 .
Interface AIDL HAL versão 1
Alterações da API
O AIDL versão 1 HAL suporta APIs semelhantes ao HIDL 2.1 HAL. Em comparação com a interface HIDL 2.1, o seguinte é alterado na API:
- As APIs relacionadas ao carregador introduzidas no HIDL HAL 2.1 não são portadas para o AIDL HAL. Como a funcionalidade de carregamento fora do modo reside apenas na partição
/vendor
, as APIs na interface do fornecedor não são necessárias. Para implementar o carregamento no modo desligado corretamente, consulte o carregador abaixo. - O tipo
StorageAttribute
e os campos relacionados são removidos porque não são usados. - O carregadorDockOnline é adicionado ao
chargerDockOnline
paraHealthInfo
suporte ao carregamento do dock.
Implementação
Veja o seguinte diagrama UML para as classes úteis para a implementação de HAL de integridade:
Figura 8. Diagrama UML de Health AIDL HAL
Para obter informações sobre como implementar o serviço AIDL de integridade, consulte Implementando HAL de AIDL de integridade .
Recuperação
O Android 13 é compatível com o fichário em 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 é movida de /system
para /vendor
. Para dispositivos iniciados com o Android 13, se eles forem compatíveis com carregamento no modo desligado, o binário do serviço HAL deverá ser compatível com o modo carregador. Para isso, consulte a implementação do carregador .
Propriedades do sistema do carregador
As propriedades ro.charger.*
não são mais legíveis pelo binário do charger
em /vendor
. Se o seu dispositivo tiver qualquer uma das propriedades do sistema ro.charger.*
definidas, consulte as propriedades do sistema para o carregador .