Integridade do sistema Android

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 a libhealthd_android, libbatterymonitor e libbatteryservice.
• 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 e libbatterymonitor.
• A recuperação é vinculada estaticamente ao libhealthd.BOARD e libbatterymonitor.

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

• Usar o exemplo de serviço HAL de saúde AIDL
• Mudanças no sistema de build

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.