Integridade do sistema Android

O Android 9 inclui a HAL 2.0 android.hardware.health, uma atualização importante da versão da HAL health@1.0. Essa nova HAL tem as seguintes vantagens:

  • Separação mais limpa entre o framework e o código do fornecedor.
  • O daemon healthd desnecessário foi descontinuado.
  • Maior liberdade para a personalização do fornecedor nos relatórios de informações de saúde.
  • Mais informações sobre a integridade do dispositivo, além da bateria.

O Android 11 inclui a HAL android.hardware.health 2.1, uma pequena atualização da versão da HAL health@2.0. Essa nova HAL tem as seguintes vantagens:

  • Mais fáceis de implementar
  • Melhor conformidade com as APIs HAL 2.0 atuais
  • Melhor separação de agudos no código de carregamento fora do modo
  • Melhor suporte ao framework para indicar a integridade da bateria do dispositivo

O Android 13 inclui a HAL AIDL android.hardware.health, uma conversão da HAL health@2.1. Essa nova HAL tem as seguintes vantagens:

  • Remover APIs relacionadas a carregadores não usadas
  • Remover StorageAttribute e campos relacionados não usados
  • Suporte para carregamento na base.

Requisitos

Dispositivos com o Android 9 e o Android 10

Os dispositivos lançados com o Android 9 precisam fornecer a HAL 2.x (e não a 1.0) ou a HAL AIDL. Os dispositivos que não são lançados com o Android 9, mas planejam atualizar a imagem do fornecedor para a versão 3 da Matriz de compatibilidade do Framework de destino versão 3 (lançada no Android 9), precisam remover as implementações da HAL 1.0 existentes e fornecer a HAL 2.x ou a HAL da AIDL.

O AOSP inclui várias bibliotecas auxiliares projetadas para ajudar você a implementar a HAL 2.0 e a transição da antiga HAL 1.0.

Dispositivos com o Android 11 e 12

Os dispositivos lançados com o Android 11 precisam fornecer a HAL 2.1 (e não a HAL 1.0 ou 2.0) ou a HAL AIDL. Os dispositivos que não são lançados com o Android 11, mas que planejam atualizar a imagem do fornecedor para a versão 5 da matriz de compatibilidade do framework de destino (lançada no Android 11), precisam remover as implementações de HAL 2.0 existentes e fornecer o HAL 2.1 ou o HAL AIDL. Os dispositivos que não são lançados com o Android 11 e que não planejam atualizar a imagem do fornecedor também precisam fornecer o HAL 2.1.

O AOSP inclui várias bibliotecas auxiliares projetadas para ajudar você a implementar a HAL 2.1 e a transição da antiga HAL 1.0.

Dispositivos com o Android 13 e versões mais recentes

Os dispositivos lançados com o Android 13 precisam fornecer a HAL AIDL (e não a HAL HIDL). Os dispositivos que não forem lançados com o Android 13, mas que planejam atualizar a imagem do fornecedor para a versão 7 da matriz de compatibilidade do framework de destino (lançada no Android 13), precisam remover as implementações de HAL HIDL atuais e fornecer a HAL AIDL. Os dispositivos que não forem lançados com o Android 13 e que não planejam atualizar a imagem do fornecedor também são recomendados para fornecer a HAL AIDL.

Os dispositivos não podem fornecer o HAL HIDL 1.0.

O AOSP inclui várias bibliotecas auxiliares projetadas para ajudar a implementar o HAL AIDL e a transição das antigas HALs HIDL.

Terminologia

  • health@1.0: abreviação de android.hardware.health@1.0. Refere-se à HAL de integridade HIDL versão 1.0 lançada no Android 8.0.
  • health@2.0: abreviação de android.hardware.health@2.0. Se refere à HAL de saúde HIDL versão 2.0 lançada no Android 9.
  • health@2.1: abreviação de android.hardware.health@2.1. Refere-se à HAL de saúde HIDL versão 2.1 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 a animação de carregamento do smartphone.
  • recovery: executável em modo de recuperação que precisa 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 executado no Android que extrai 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 pelo framework para se comunicar com o hardware.
  • healthd faz uma vinculação estática a libhealthd_android, libbatterymonitor e libbatteryservice.
  • health@1.0-impl vincula-se estaticamente a libhealthd.BOARD.

Cada placa pode personalizar um libhealthd.BOARD diferente. Isso é determinado no momento da criação a que carregador, health@1.0-impl e link de recuperação.

Para outros modos:

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

Figura 2. Saúde no Android 8.x, carregamento no modo de espera e modo de recuperação.

  • carregador se conecta estaticamente a libhealthd.BOARD, libhealthd_charger e libbatterymonitor.
  • A recuperação é vinculada 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.

O framework tenta recuperar o serviço health@2.0 de hwservicemanager. Se falhar, ele vai chamar o health@1.0 (no Android 8.x). O caminho do código legado é mantido para que a imagem do sistema do Android 9 seja compatível com a imagem do fornecedor do Android 8.x. O framework não recupera informações das duas HALs porque apenas uma versão de serviço (1.0 ou 2.0) pode existir no dispositivo.

Para outros modos:

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

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 abaixo:

[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 voltará 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:

Infraestrutura da HAL de integridade 2.1

Figura 5. Infraestrutura da HAL de saúde 2.1.

Saúde no Android 13

No Android 13, a HAL de saúde AIDL foi introduzida. O componente de integridade funciona conforme detalhado no diagrama a seguir:

Infraestrutura HAL de AIDL de saúde

Figura 6. Infraestrutura da HAL de AIDL de saúde.

Interface HAL para HIDL 2.0

O HAL health@2.0 oferece a mesma funcionalidade ao framework que o antigo daemon healthd. Ele também fornece APIs semelhantes àquelas fornecidas anteriormente como um serviço de binder (ou seja, IBatteryPropertiesRegistrar).

A interface principal, IHealth, oferece 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 por:
    • getChargeCounter
    • getCurrentNow
    • getCurrentAverage
    • getCapacity
    • getEnergyCounter
    • getChargeStatus
    • getHealthInfo

Além disso, IHealth fornece as seguintes novas APIs para storaged extrair informações relacionadas ao armazenamento específicas do fornecedor:

  • getStorageInfo
  • getDiskStats

Um novo struct, @2.0::HealthInfo, é retornado por callbacks e getHealthInfo. Essa estrutura contém todas as informações de integridade do dispositivo disponíveis pelo HAL health@2.0, incluindo:

  • Informações de carregamento (CA/USB/sem fio, corrente, tensão etc.)
  • Informações sobre a bateria (presença, nível, corrente, tensão, carga, tecnologia etc.)
  • Informações de armazenamento (informações do dispositivo de armazenamento, estatísticas do disco)

Para informações sobre como implementar o serviço de saúde 2.0, consulte Como implementar o Google Fit 2.0.

Interface HAL de HIDL 2.1

A HAL health@2.1 oferece suporte ao carregamento no modo desativado e fornece mais informações sobre a bateria.

A interface principal, IHealth, oferece as seguintes funções adicionais:

  • getHealthConfig: para recuperar a configuração desse HAL
  • getHealthInfo_2_1: um upgrade de versão secundária para getHealthInfo
  • shouldKeepScreenOn: para determinar se a tela precisa ser mantida no modo de carregador

Além disso, a implementação de @2.1::IHealth é necessária para oferecer suporte a @2.1::IHealthInfoCallback para as funções registerCallback e unregisterCallback herdadas. A nova interface de callback retorna informações de integridade para o cliente usando a função healthInfoChanged_2_1 em vez da função healthInfoChanged herdada.

Uma nova struct, @2.1::HealthInfo, é retornada por callbacks e getHealthInfo_2_1. Esse struct contém outras informações sobre a integridade do dispositivo, disponíveis pela HAL health@2.0, incluindo:

  • Nível de capacidade da bateria
  • Tempo de carga da bateria até ficar cheia (em segundos)
  • Capacidade de projeto de carga total da bateria (em μAh)

Consulte o seguinte diagrama UML para ver as classes úteis para a implementação da HAL de saúde:

Diagrama UML do HAL do Health 2.1

Figura 7. Diagrama UML da HAL de saúde 2.1.

Para ver 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 da versão 1 da AIDL oferece suporte a APIs semelhantes à HAL da HIDL 2.1. Em comparação com a interface HIDL 2.1, as seguintes mudanças foram feitas na API:

  • As APIs relacionadas ao carregador introduzidas na HAL de HIDL 2.1 não são transferidas para a HAL AIDL. Como a funcionalidade de carregamento fora do modo existe apenas na partição /vendor, as APIs na interface do fornecedor não são necessárias. Para implementar o carregamento fora do modo corretamente, consulte carregador abaixo.
  • O tipo StorageAttribute e os campos relacionados são removidos porque não são usados.
  • chargerDockOnline foi adicionado a HealthInfo para oferecer suporte ao carregamento na base.

Implementação

Consulte o diagrama UML a seguir para conferir as classes úteis para a implementação do HAL de integridade:

Diagrama de UML da HAL de saúde AIDL

Figura 8. Diagrama UML da HAL da AIDL de saúde.

Para informações sobre como implementar o serviço de AIDL de saúde, consulte Como implementar o HAL de AIDL de saúde.

Recuperação

O Android 13 oferece suporte a vinculação na recuperação. A instalação do serviço AIDL de integridade permite que ele seja executado no modo de recuperação.

Para informações sobre como instalar o serviço de 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 o Android 13, se eles oferecem suporte ao carregamento fora do modo, o binário do serviço HAL precisa oferecer suporte ao modo de carregador. Para fazer isso, consulte como implementar o carregador.

Propriedades do sistema do carregador

As propriedades ro.charger.* não são mais legíveis pelo binário charger em /vendor. Se o dispositivo tiver alguma das propriedades do sistema ro.charger.* definidas, consulte as propriedades do sistema para o carregador.