État du système Android

Android 9 inclut android.hardware.health HAL 2.0, une mise à niveau de version majeure de health@1.0 HAL. Ce nouveau HAL dispose des éléments suivants : avantages:

  • Séparation plus claire entre le framework et le code fournisseur.
  • Abandon du daemon healthd inutile.
  • Meilleur degré de liberté pour personnaliser les fournisseurs d'informations de santé rapports.
  • Plus d'informations sur l'état de l'appareil en plus de la batterie.

Android 11 inclut android.hardware.health HAL 2.1, une mise à niveau vers une version mineure de health@2.0 HAL. Ce nouveau HAL dispose des éléments suivants : avantages:

  • Plus facile à implémenter
  • Meilleure conformité avec les API HAL 2.0 existantes
  • Meilleure séparation des aigus en cas de code de recharge hors mode
  • Meilleure prise en charge du framework pour indiquer l'état de la batterie du appareil

Android 13 inclut android.hardware.health AIDL HAL, une conversion de health@2.1 HAL. Ce nouveau HAL dispose des éléments suivants : avantages:

  • Supprimer les API liées aux chargeurs inutilisées
  • Supprimer les StorageAttribute inutilisés et les champs associés
  • Prenez en charge la recharge sur la station d'accueil.

Conditions requises

Appareils fonctionnant sous Android 9 et Android 10

Les appareils équipés d'Android 9 doivent fournir la version 2.x HAL (sans fournir la version 1.0 du HAL) ou le HAL AIDL. Les appareils ne se lancent pas avec Android 9, mais nous prévoyons de modifier l'image du fournisseur à Target Framework Compatibility Matrix version 3 (publiée sous Android 9) doivent supprimer les implémentations HAL 1.0 existantes et fournir le HAL 2.x ou le HAL AIDL.

AOSP comprend plusieurs bibliothèques d'aide conçues pour vous aider à implémenter la version 2.0 HAL et la transition depuis l'ancienne version 1.0.

Appareils fonctionnant sous Android 11 et Android 12

Les appareils équipés d'Android 11 doivent disposer de la version 2.1 HAL (sans fournir le HAL 1.0 ou 2.0) ou le HAL AIDL. Appareils non compatibles avec Android 11, mais nous prévoyons de mettre à jour image du fournisseur vers Target Framework Compatibility Matrix Version 5 (publiée dans Android 11) doit supprimer la version HAL 2.0 existante des implémentations et fournir le HAL 2.1 ou le HAL AIDL. Les appareils ne se lancent pas avec Android 11 et ne prévoyez pas de mettre à jour le fournisseur nous vous recommandons également de fournir l'image HAL 2.1.

AOSP comprend plusieurs bibliothèques d'aide conçues pour vous aider à implémenter la version 2.1 HAL et la transition depuis l'ancienne version 1.0.

Appareils fonctionnant sous Android 13 ou version ultérieure

Les appareils équipés d'Android 13 doivent fournir l'AIDL HAL (et ne doit pas fournir HIDL HAL). Appareils qui ne sont pas lancés avec Android 13, mais prévoient de mettre à jour l'image du fournisseur vers Target Framework Compatibility Matrix version 7 (publiée dans Android 13) doit supprimer les implémentations HIDL HAL existantes et fournir le HAL AIDL. Les appareils qui ne sont pas lancés avec Android 13 et qui ne prévoient pas de mettre à jour l'image du fournisseur sont également il est recommandé de fournir le HAL AIDL.

Les appareils ne doivent pas fournir le HAL HIDL 1.0.

AOSP comprend plusieurs bibliothèques d'aide conçues pour vous aider à implémenter AIDL HAL et la transition des anciens HAL HIDL.

Terminologie

  • health@1.0: abréviation de android.hardware.health@1.0. Désigne Health HIDL HAL version 1.0 publié sur Android 8.0.
  • health@2.0: abréviation de android.hardware.health@2.0. Désigne Health HIDL HAL version 2.0 publié sous Android 9.
  • health@2.1: abréviation de android.hardware.health@2.1. Désigne Health HIDL HAL version 2.1 publiée sous Android 11.
  • health AIDL HAL: abréviation de android.hardware.health.
    • La version 1 est publiée sous Android 13.
  • charger: fichier exécutable en charge hors mode qui affiche le de recharge du téléphone.
  • recovery: fichier exécutable en mode Recovery qui doit récupérer la batterie des informations.
  • healthd: ancien daemon s'exécutant sur Android qui récupère les problèmes liés à l'état d'informations et les fournit au framework.
  • storaged: daemon s'exécutant sur Android qui récupère les informations de stockage et les fournit au framework.

Santé dans Android 8.x

Dans Android 8.x, le composant "health" fonctionne comme indiqué dans le schéma suivant:

Santé dans Android 8.x

Figure 1 : Santé dans Android 8.x.

Dans ce diagramme:

  • Un (1) appel de liaison et un (1) appel de liaison sont utilisés par le framework pour communiquer avec le matériel.
  • healthd renvoie de manière statique vers libhealthd_android, libbatterymonitor et libbatteryservice
  • health@1.0-impl renvoie de manière statique vers libhealthd.BOARD

Chaque tableau peut personnaliser un libhealthd.BOARD différent. Lors de la compilation, il est déterminé quels sont les composants chargeur, health@1.0-impl et lien de récupération auxquelles vous souhaitez vous connecter.

Pour les autres modes:

Mode hors mode de chargement et de récupération dans Android 8.x

Figure 2. Santé sous Android 8.x, recharge hors connexion et mode Recovery.

  • le chargeur est associé de manière statique à libhealthd.BOARD, libhealthd_charger et libbatterymonitor.
  • la récupération est associée de manière statique à libhealthd.BOARD et libbatterymonitor

Santé dans Android 9

Sous Android 9, le composant Health fonctionne de la même manière dans le schéma suivant: Santé dans Android 9

Figure 3. Santé dans Android 9.

Le framework tente de récupérer le service health@2.0 à partir de hwservicemanager. En cas d'échec, l'appel est envoyé à health@1.0 (sous Android 8.x). L'ancien chemin de code est conservé afin que l’image système Android 9 soit compatible avec l'image du fournisseur Android 8.x. Le framework ne récupère pas d'informations les deux HAL, car une seule version de service (1.0 ou 2.0) peut exister sur l'appareil.

Pour les autres modes:

Rechargement et récupération hors mode sous Android 9

Figure 4. Santé sous Android 9, recharge hors mode et mode Récupération.

Santé dans Android 11

Dans Android 11, le composant "health" fonctionne de la manière dans le schéma suivant:

[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)      ] |
+-------------------------------------+

Si l'implémentation de l'état 2.1 n'existe pas, le système bascule sur l'ancien chemin de code, comme décrit dans les sections précédentes.

Pour les autres modes:

[       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)      ] |
+-------------------------------------+

Consultez le schéma simplifié suivant pour les différents modes:

Infrastructure HAL 2.1 Health

Figure 5. Infrastructure HAL 2.1 Health

Santé dans Android 13

Dans Android 13, le HAL AIDL d'état est introduit. La Le composant Health fonctionne comme indiqué dans le schéma suivant:

Infrastructure HAL AIDL Health

Figure 6. Infrastructure HAL AIDL Health.

Interface HIDL HAL 2.0

Le HAL health@2.0 fournit au framework les mêmes fonctionnalités que l'ancien le daemon "healthd". Il fournit également des API semblables à celles précédemment fourni en tant que service de liaison (par exemple, IBatteriePropertiesRegistrar).

L'interface principale, IHealth , fournit les fonctions suivantes:

  • registerCallback pour remplacer IBatteryPropertiesRegistrar.registerListener
  • unregisterCallback pour remplacer IBatteryPropertiesRegistrar.unregisterListener
  • update, pour remplacer IBatteryPropertiesRegistrar.scheduleUpdate
  • IBatteryPropertiesRegistrar.getProperties sont remplacés par ce qui suit: <ph type="x-smartling-placeholder">
      </ph>
    • getChargeCounter
    • getCurrentNow
    • getCurrentAverage
    • getCapacity
    • getEnergyCounter
    • getChargeStatus
    • getHealthInfo

De plus, IHealth fournit les nouvelles API suivantes pour storaged afin de permettre Récupérez les informations liées au stockage propres au fournisseur:

  • getStorageInfo
  • getDiskStats

Un nouveau struct, @2.0::HealthInfo, est renvoyé via des rappels et getHealthInfo. Ce struct contient toutes les informations sur l'état de l'appareil disponibles via health@2.0. HAL, y compris:

  • Informations sur le rechargement (CA/USB/sans fil, courant, tension, etc.)
  • Informations sur la batterie (présence, niveau de la batterie, intensité, tension, charge, technologie, etc.)
  • Informations sur le stockage (informations sur les périphériques de stockage, statistiques sur le disque)

Pour en savoir plus sur l'implémentation du service Santé 2.0, consultez Implémenter Santé 2.0

Interface HIDL HAL 2.1

Le HAL health@2.1 prend en charge la recharge hors connexion et fournit plus d'informations sur la batterie.

L'interface principale, IHealth, propose les fonctions supplémentaires suivantes :

  • getHealthConfig: pour récupérer la configuration de ce HAL
  • getHealthInfo_2_1: mise à niveau d'une version mineure vers getHealthInfo
  • shouldKeepScreenOn: permet de déterminer si l'écran doit rester allumé dans mode chargeur

De plus, l'implémentation de @2.1::IHealth est requise pour prendre en charge @2.1::IHealthInfoCallback pour ses registerCallback hérités et Fonctions unregisterCallback. La nouvelle interface de rappel renvoie l'état des informations au client à l'aide de sa fonction healthInfoChanged_2_1 au lieu de la fonction healthInfoChanged héritée.

Un nouveau struct, @2.1::HealthInfo, est renvoyé via des rappels et getHealthInfo_2_1 Ce struct contient des informations supplémentaires sur l'état de l'appareil disponibles via health@2.0 HAL, y compris:

  • Niveau de charge de la batterie
  • Temps de charge actuel de la batterie (en secondes)
  • Capacité nominale de la batterie à charge complète (en μAh)

Consultez le schéma UML suivant pour connaître les classes utiles à l'implémentation de HAL pour l'état de santé:

Diagramme UML HAL Health 2.1

Figure 7. Diagramme UML de la HAL Health 2.1.

Pour en savoir plus sur l'implémentation du service Santé 2.1, consultez Implémenter Health 2.1.

Interface HAL AIDL version 1

Modifications apportées à l'API

La version 1 du HAL d'AIDL est compatible avec des API semblables à celles du HAL HIDL 2.1. Par rapport à l'interface HIDL 2.1, les éléments suivants sont modifiés dans l'API:

  • Les API liées au chargeur introduites dans HIDL HAL 2.1 ne sont pas transférées vers AIDL CARL. La fonctionnalité de recharge hors mode ne peut être rechargée que sur le /vendor, les API sur l'interface fournisseur ne sont pas nécessaires. À pour mettre en place la recharge hors mode correctement, consultez la section Chargeur ci-dessous.
  • Le type StorageAttribute et les champs associés ont été supprimés, car ils sont non utilisé.
  • chargerDockOnline a été ajouté à HealthInfo pour permettre la recharge sur la station d'accueil.

Implémentation

Consultez le schéma UML suivant pour connaître les classes utiles à l'implémentation de HAL pour l'état de santé:

Diagramme UML HAL Health AIDL

Figure 8. Diagramme UML HAL de Health AIDL.

Pour en savoir plus sur l'implémentation du service Health AIDL, consultez Implémenter Santé AIDL HAL

Récupération

Android 13 prend en charge le binder pour la récupération. Installer la Le service Health AIDL de récupération lui permet de s'exécuter en mode Recovery.

Pour en savoir plus sur l'installation du service Health AIDL pour la récupération, consultez le suivantes:

Chargeur

La fonctionnalité de recharge hors mode a été déplacée de /system vers /vendor. Pour sur les appareils équipés d'Android 13, s'ils prennent en charge charge hors tension, le binaire du service HAL doit être compatible avec le mode chargeur. Pour ce faire, se référer à mettre en place le chargeur.

Propriétés du système de chargeur

Les propriétés ro.charger.* ne sont plus lisibles par le binaire charger dans /vendor Si l'une des propriétés système ro.charger.* est définie sur votre appareil, se référer à propriétés système du chargeur.