O Android 9 inclui a HAL 2.0 android.hardware.health
,
uma atualização de versão principal da HAL health@1.0. Essa nova HAL tem os seguintes
vantagens:
- Separação mais limpa entre o framework e o código do fornecedor.
- Descontinua o daemon
healthd
desnecessário. - Maiores graus de liberdade para personalização do fornecedor nas informações sobre saúde. e detecção de ameaças.
- Mais informações sobre a integridade do dispositivo além da bateria.
O Android 11 inclui a HAL 2.1 android.hardware.health
,
uma atualização de versão secundária da HAL health@2.0 Essa nova HAL tem os seguintes
vantagens:
- Mais fáceis de implementar
- Melhor conformidade com as APIs 2.0 HAL existentes
- Melhor separação do Treble no código de carregamento no modo desativado
- Melhor suporte para que o framework indique a integridade da bateria do dispositivo
O Android 13 inclui a HAL de AIDL android.hardware.health
,
uma conversão da HAL health@2.1. Essa nova HAL tem os seguintes
vantagens:
- Remover APIs relacionadas a carregadores não utilizadas
- Remover
StorageAttribute
não usado e campos relacionados - Ofereça suporte ao carregamento da base.
Requisitos
Dispositivos com o Android 9 e o Android 10
Os dispositivos lançados com o Android 9 precisam fornecer a versão 2.x HAL (e não pode fornecer a HAL 1.0) ou HAL AIDL. Dispositivos que não estão iniciando com o Android 9, mas planejamos atualizar a imagem do fornecedor à Matriz de compatibilidade de framework de destino versão 3 (lançada no Android 9) precisam remover as implementações da HAL 1.0 fornecem a HAL 2.x ou a HAL AIDL.
O AOSP inclui várias bibliotecas auxiliares projetadas para ajudar você a implementar a versão 2.0 HAL e a transição da HAL 1.0 antiga.
Dispositivos com o Android 11 e 12
Dispositivos lançados com o Android 11 precisam fornecer a versão 2.1 HAL (e não pode fornecer a HAL 1.0 ou 2.0) ou HAL da AIDL. Dispositivos que não são sendo lançado com o Android 11, mas planejamos atualizar imagem do fornecedor para a Matriz de Compatibilidade de Framework de Destino versão 5 (lançada em O Android 11) precisa remover a HAL 2.0 existente. e fornecer a HAL 2.1 ou a HAL AIDL. Dispositivos que não estão iniciando com o Android 11 e não planeja atualizar o fornecedor também são recomendadas para fornecer a HAL 2.1.
O AOSP inclui várias bibliotecas auxiliares projetadas para ajudar você a implementar a versão 2.1 HAL e a transição da HAL 1.0 antiga.
Dispositivos com o Android 13 ou mais recente
Os dispositivos lançados com o Android 13 precisam fornecer a AIDL HAL (e não pode fornecer HIDL HAL). Dispositivos que não serão lançados com o Android 13, mas planejam atualizar a imagem do fornecedor para o Target A versão 7 da Matriz de compatibilidade de framework (lançada no Android 13) precisa remover as implementações de HIDL HAL e fornecem a HAL da AIDL. Os dispositivos que não são lançados com o Android 13 e não planejam atualizar a imagem do fornecedor também estão recomendado para fornecer a HAL de AIDL.
Os dispositivos não podem oferecer a HAL HIDL 1.0.
O AOSP inclui várias bibliotecas auxiliares projetadas para ajudar a implementar a AIDL HAL e a transição das HALs HIDL antigas.
Terminologia
- health@1.0: abreviação de
android.hardware.health@1.0
. Refere-se a versão 1.0 da HAL de saúde HIDL lançada no Android 8.0. - health@2.0: abreviação de
android.hardware.health@2.0
. Refere-se a versão 2.0 da HAL de saúde HIDL lançada no Android 9. - health@2.1: abreviação de
android.hardware.health@2.1
. Refere-se a versão 2.1 da HAL de saúde HIDL lançada no Android 11. - HAL de saúde AIDL: abreviação de
android.hardware.health
.- A versão 1 foi lançada no Android 13.
- charger: executável em execução no modo de carregamento que exibe o animação do carregamento do smartphone.
- recovery: executável em modo de recuperação que precisa recuperar a bateria informações imprecisas ou inadequadas.
- healthd: daemon legado em execução no Android que recupera informações relacionadas à saúde informações e as fornece à estrutura.
- storaged: daemon em execução no Android que recupera informações de armazenamento e os fornece à estrutura.
Saúde no Android 8.x
No Android 8.x, o componente de saúde 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 pelo framework para para comunicação com o hardware.
healthd
é vinculado estaticamente alibhealthd_android
,libbatterymonitor
elibbatteryservice
.- health@1.0-impl vincula estaticamente a
libhealthd.BOARD
:
Cada quadro pode personalizar um libhealthd.BOARD
diferente.
é determinado no momento da criação que carregador, health@1.0-impl e link de recuperação
Para outros modos:
Figura 2. Saúde no Android 8.x, modo de carregamento desativado e modo de recuperação.
- o carregador se conecta estaticamente ao
libhealthd.BOARD
,libhealthd_charger
elibbatterymonitor
. - A recuperação é vinculada estaticamente ao
libhealthd.BOARD
elibbatterymonitor
.
Saúde no Android 9
No Android 9, o componente de saúde funciona da forma no diagrama a seguir:
Figura 3. Saúde no Android 9.
O framework tenta recuperar o serviço health@2.0 de hwservicemanager
.
Em caso de falha, ele chama health@1.0 (no Android 8.x). O caminho do código legado
mantidas para que a imagem do sistema Android 9 seja compatível com
imagem do fornecedor do Android 8.x. O framework não recupera informações
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, modo de carregamento desativado e modo de recuperação.
Saúde no Android 11
No Android 11, o componente de saúde 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 de integridade 2.1 não existir, o sistema recorrerá 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) ] |
+-------------------------------------+
Consulte o diagrama simplificado abaixo para diferentes modos:
Figura 5. Infraestrutura da HAL de integridade 2.1.
Saúde no Android 13
No Android 13, a HAL de saúde AIDL foi lançada. A componente de integridade funciona conforme detalhado no diagrama a seguir:
Figura 6. Infraestrutura de HAL de saúde AIDL.
Interface HIDL HAL 2.0
A HAL health@2.0 fornece ao framework a mesma funcionalidade da antiga o daemon íntegro. Ele também fornece APIs semelhantes às APIs fornecidos anteriormente como um serviço de vinculação (por exemplo, IBatteryPropertiesRegistrar).
A interface principal, IHealth (em inglês) , fornece as seguintes funções:
registerCallback
, para substituirIBatteryPropertiesRegistrar.registerListener
unregisterCallback
, para substituirIBatteryPropertiesRegistrar.unregisterListener
update
, para substituirIBatteryPropertiesRegistrar.scheduleUpdate
IBatteryPropertiesRegistrar.getProperties
foram substituídos pelos seguintes:getChargeCounter
getCurrentNow
getCurrentAverage
getCapacity
getEnergyCounter
getChargeStatus
getHealthInfo
Além disso, o 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 callbacks e getHealthInfo
.
Este struct contém todas as informações sobre a integridade do dispositivo disponíveis por health@2.0
HAL, incluindo:
- Informações de carregamento (CA/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 informações sobre como implementar o serviço de saúde 2.0, consulte Como implementar o Health 2.0.
Interface HIDL HAL 2.1
A HAL health@2.1 é compatível com carregamento no modo desativado e oferece mais informações sobre a bateria.
A interface principal, IHealth, fornece as seguintes funções adicionais
getHealthConfig
: para extrair a configuração dessa HAL.getHealthInfo_2_1
: um upgrade da versão secundária paragetHealthInfo
shouldKeepScreenOn
: para determinar se a tela precisa ser mantida ativada. modo carregador
Além disso, a implementação de @2.1::IHealth
é necessária para oferecer suporte
@2.1::IHealthInfoCallback
para o registerCallback
herdado e
unregisterCallback
. A nova interface de callback retorna integridade
informações ao cliente usando a função healthInfoChanged_2_1
em vez de
a função healthInfoChanged
herdada.
Um novo struct, @2.1::HealthInfo
, é retornado por callbacks e
getHealthInfo_2_1
. Este struct contém mais informações sobre a integridade do dispositivo
disponíveis pela HAL health@2.0, incluindo:
- Nível de capacidade da bateria
- Tempo de carregamento da bateria até a carga completa (em segundos)
- Capacidade do design de carregamento total da bateria (em μAh)
Consulte o seguinte diagrama UML para as classes úteis para a implementação da HAL de saúde:
Figura 7. Diagrama UML da HAL de saúde 2.1.
Para informações sobre como implementar o serviço Saúde 2.1, consulte Como implementar o Health 2.1.
Versão 1 da interface da HAL de AIDL
Mudanças na API
A HAL de versão 1 da AIDL oferece suporte a APIs semelhantes à HAL HIDL 2.1. Comparado a interface HIDL 2.1, a API fará as seguintes alterações:
- As APIs relacionadas ao carregador introduzidas na HAL 2.1 de HIDL não são portadas para a AIDL.
HAL Como a funcionalidade do carregamento no modo desativado reside apenas no
/vendor
, as APIs na interface do fornecedor não são necessárias. Para implementar o carregamento fora do modo corretamente, consulte o carregador abaixo. - O tipo
StorageAttribute
e os campos relacionados foram removidos porque são o que não é usado. - O
chargerDockOnline
foi adicionado aHealthInfo
para oferecer suporte ao carregamento da base.
Implementação
Consulte o seguinte diagrama UML para as classes úteis para a implementação da HAL de saúde:
Figura 8. Diagrama UML da HAL de saúde AIDL.
Para informações sobre como implementar o serviço AIDL de saúde, consulte Como implementar a HAL de saúde AIDL.
Recuperação
O Android 13 oferece suporte ao binder na recuperação. Instalar o O serviço AIDL de integridade permite que ele seja executado no modo de recuperação.
Para informações sobre como instalar o serviço AIDL de integridade para recuperação, consulte a seguintes:
Carregador
A funcionalidade de carregamento desativado no modo foi movida de /system
para /vendor
. Para
dispositivos lançados com o Android 13, se tiverem suporte
no modo de carregamento desativado, o binário de serviço HAL precisa ser compatível com o modo de carregador. Para isso,
consulte
implementar carregador.
Propriedades do sistema do carregador
As propriedades ro.charger.*
não são mais legíveis pelo binário charger
na
/vendor
Caso seu dispositivo tenha alguma das propriedades do sistema do ro.charger.*
definidas,
consulte
propriedades do sistema para o carregador.