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

Saúde do Android

Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

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 .