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:
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 verslibhealthd_android
,libbatterymonitor
etlibbatteryservice
- 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:
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
etlibbatterymonitor
. - la récupération est associée
de manière statique à
libhealthd.BOARD
etlibbatterymonitor
Santé dans Android 9
Sous Android 9, le composant Health fonctionne de la même manière dans le schéma suivant:
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:
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:
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:
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 remplacerIBatteryPropertiesRegistrar.registerListener
unregisterCallback
pour remplacerIBatteryPropertiesRegistrar.unregisterListener
update
, pour remplacerIBatteryPropertiesRegistrar.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 HALgetHealthInfo_2_1
: mise à niveau d'une version mineure versgetHealthInfo
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é:
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é:
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.