O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

Saúde do Android

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:

Saúde no Android 8.x

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 a libhealthd_android , libbatterymonitor e libbatteryservice .
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:

Modo de carregamento e recuperação fora do modo no Android 8.x

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 e libbatterymonitor .
recovery vincula estaticamente a libhealthd. BOARD e libbatterymonitor .

Saúde no Android 9

No Android 9, o componente de integridade funciona conforme detalhado no diagrama a seguir: Saúde no Android 9

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:

Carga e recuperação fora do modo no Android 9

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:

Infraestrutura HAL 2.1 de saúde

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:

Infraestrutura AIDL HAL de saúde

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 substituir IBatteryPropertiesRegistrar.registerListener
unregisterCallback , para substituir IBatteryPropertiesRegistrar.unregisterListener
update , para substituir IBatteryPropertiesRegistrar.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 para getHealthInfo
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:

Diagrama UML de saúde 2.1 HAL

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 para HealthInfo suporte ao carregamento do dock.

Implementação

Veja o seguinte diagrama UML para as classes úteis para a implementação de HAL de integridade:

Diagrama UML de saúde AIDL HAL

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 .