Android 9 inclut android.hardware.health
HAL 2.0, une mise à niveau majeure de la version de health@1.0 HAL. Cette nouvelle HAL présente les avantages suivants :
- Séparation plus nette entre le framework et le code du fournisseur.
-
healthd
le démon sain inutile. - Degrés de liberté accrus pour la personnalisation des fournisseurs dans les rapports d'informations sur la santé.
- Plus d'informations sur l'état de l'appareil que la simple batterie.
Android 11 inclut android.hardware.health
HAL 2.1, une mise à niveau de version mineure de health@2.0 HAL. Cette nouvelle HAL présente les avantages suivants :
- Plus facile à mettre en œuvre
- Meilleure conformité avec les API HAL 2.0 existantes
- Meilleure séparation des aigus dans le code de charge hors mode
- Meilleure prise en charge du cadre pour indiquer la santé de la batterie de l'appareil
Android 13 inclut android.hardware.health
AIDL HAL, une conversion de health@2.1 HAL. Cette nouvelle HAL présente les avantages suivants :
- Supprimer les API liées au chargeur inutilisées
- Supprimer
StorageAttribute
inutilisé et les champs associés - Prend en charge la charge de la station d'accueil.
Conditions
Appareils exécutant Android 9 et Android 10
Les appareils lancés avec Android 9 doivent fournir la HAL 2.x (et ne doivent pas fournir la HAL 1.0) ou la HAL AIDL. Les appareils qui ne se lancent pas avec Android 9 mais qui prévoient de mettre à jour l'image du fournisseur vers Target Framework Compatibility Matrix Version 3 (publiée dans Android 9) doivent supprimer les implémentations HAL 1.0 existantes et fournir la HAL 2.x ou la HAL AIDL.
AOSP comprend plusieurs bibliothèques d'assistance conçues pour vous aider à implémenter la HAL 2.0 et la transition depuis l'ancienne HAL 1.0.
Appareils exécutant Android 11 et Android 12
Les appareils lancés avec Android 11 doivent fournir la HAL 2.1 (et ne doivent pas fournir la HAL 1.0 ou 2.0) ou la HAL AIDL. Les appareils qui ne se lancent pas avec Android 11 mais qui prévoient de mettre à jour l'image du fournisseur vers Target Framework Compatibility Matrix Version 5 (publié dans Android 11) doivent supprimer les implémentations HAL 2.0 existantes et fournir la HAL 2.1 ou la HAL AIDL. Il est également recommandé aux appareils qui ne se lancent pas avec Android 11 et qui ne prévoient pas de mettre à jour l'image du fournisseur de fournir la HAL 2.1.
AOSP comprend plusieurs bibliothèques d'assistance conçues pour vous aider à implémenter la HAL 2.1 et la transition depuis l'ancienne HAL 1.0.
Appareils exécutant Android 13 et versions ultérieures
Les appareils lancés avec Android 13 doivent fournir l'AIDL HAL (et ne doivent pas fournir l'HIDL HAL). Les appareils qui ne se lancent pas avec Android 13 mais qui prévoient de mettre à jour l'image du fournisseur vers Target Framework Compatibility Matrix Version 7 (publié dans Android 13) doivent supprimer les implémentations HIDL HAL existantes et fournir l'AIDL HAL. Il est également recommandé aux appareils qui ne se lancent pas avec Android 13 et qui ne prévoient pas de mettre à jour l'image du fournisseur de fournir l'AIDL HAL.
Les appareils ne doivent pas fournir le HIDL 1.0 HAL.
AOSP comprend plusieurs bibliothèques d'assistance conçues pour vous aider à implémenter AIDL HAL et la transition depuis les anciens HIDL HAL.
Terminologie
- health@1.0 : abréviation de
android.hardware.health@1.0
. Fait référence à la santé HIDL HAL version 1.0 publiée dans Android 8.0. - health@2.0 : abréviation de
android.hardware.health@2.0
. Fait référence à la santé HIDL HAL version 2.0 publiée dans Android 9. - health@2.1 : abréviation de
android.hardware.health@2.1
. Fait référence à la santé HIDL HAL version 2.1 publiée dans Android 11. - santé AIDL HAL : abréviation de
android.hardware.health
.- La version 1 est publiée dans Android 13.
- chargeur : exécutable fonctionnant en charge hors mode qui affiche l'animation de charge du téléphone.
- recovery : exécutable tournant en mode recovery qui doit récupérer les informations de la batterie.
- healthd : démon hérité fonctionnant sous Android qui récupère les informations relatives à la santé et les fournit au framework.
- storaged : démon fonctionnant sous 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 de santé fonctionne comme détaillé dans le schéma suivant :
Figure 1 . Santé dans Android 8.x
Dans ce schéma :
- Un (1) appel binder et un (1) appel hwbinder sont utilisés par le framework pour communiquer avec le matériel.
-
healthd
statiquement àlibhealthd_android
,libbatterymonitor
etlibbatteryservice
. - health@1.0-impl établit un lien statique vers
libhealthd. BOARD
.
Chaque carte peut personnaliser un libhealthd. BOARD
; il est déterminé au moment de la construction à quel chargeur, health@1.0-impl et recovery sont liés.
Pour les autres modes :
Figure 2. Santé sous Android 8.x, mode de charge et de récupération hors mode
- chargeur établit un lien statique avec
libhealthd. BOARD
,libhealthd_charger
etlibbatterymonitor
. - recovery est lié de manière statique à
libhealthd. BOARD
etlibbatterymonitor
.
Santé dans Android 9
Dans Android 9, le composant de santé fonctionne comme détaillé dans le schéma suivant :
Illustration 3 . Santé dans Android 9
Le framework tente de récupérer le service health@2.0 à partir de hwservicemanager
. En cas d'échec, il appelle health@1.0 (sous Android 8.x). Le chemin de code hérité est conservé afin que l'image système Android 9 soit compatible avec l'image du fournisseur Android 8.x. La structure ne récupère pas les informations des 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, mode de charge et de récupération hors mode
Santé dans Android 11
Dans Android 11, le composant de santé fonctionne comme détaillé 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 d'intégrité 2.1 n'existe pas, le système revient au chemin de code hérité, 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) ] |
+-------------------------------------+
Voir le schéma simplifié suivant pour les différents modes :
Figure 5. Infrastructure HAL 2.1 Santé
Santé dans Android 13
Dans Android 13, la santé AIDL HAL est introduite. Le composant de santé fonctionne comme détaillé dans le schéma suivant :
Figure 6. Infrastructure HAL Santé AIDL
Interface HIDL HAL 2.0
L'HAL health@2.0 fournit la même fonctionnalité au framework que l'ancien démon healthd. Il fournit également des API similaires à celles fournies précédemment par healthd en tant que service de classeur (c'est-à-dire IBatteryPropertiesRegistrar ).
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 :-
getChargeCounter
-
getCurrentNow
-
getCurrentAverage
-
getCapacity
-
getEnergyCounter
-
getChargeStatus
-
getHealthInfo
-
En outre, IHealth
fournit les nouvelles API suivantes pour storaged
afin de récupérer des informations relatives au stockage spécifiques au fournisseur :
-
getStorageInfo
-
getDiskStats
Une nouvelle structure, @2.0::HealthInfo
, est renvoyée via des rappels et getHealthInfo
. Cette structure contient toutes les informations sur l'état de l'appareil disponibles via health@2.0 HAL, notamment :
- Informations de charge (AC/USB/sans fil, courant, tension, etc.)
- Informations sur la batterie (présence, niveau de la batterie, courant, tension, charge, technologie, etc.)
- Informations de stockage (informations sur le périphérique de stockage, statistiques sur le disque)
Pour plus d'informations sur l'implémentation du service Health 2.0, voir Implémentation de Health 2.0 .
Interface HIDL HAL 2.1
La santé@2.1 HAL prend en charge la charge en mode hors tension et fournit plus d'informations sur la batterie.
L'interface principale, IHealth , fournit les fonctions supplémentaires suivantes
-
getHealthConfig
: pour récupérer la configuration de cette HAL -
getHealthInfo_2_1
: une mise à niveau de version mineure versgetHealthInfo
-
shouldKeepScreenOn
: pour déterminer si l'écran doit rester allumé en mode chargeur
De plus, l'implémentation de @2.1::IHealth
est nécessaire pour prendre en charge @2.1::IHealthInfoCallback
pour ses fonctions héritées registerCallback
et unregisterCallback
. La nouvelle interface de rappel renvoie des informations sur la santé au client à l'aide de sa fonction healthInfoChanged_2_1
au lieu de la fonction héritée healthInfoChanged
.
Une nouvelle structure, @2.1::HealthInfo
, est renvoyée via des rappels et getHealthInfo_2_1
. Cette structure contient des informations supplémentaires sur l'intégrité de l'appareil disponibles via health@2.0 HAL, notamment :
- Niveau de capacité de la batterie
- Temps de charge complet de la batterie maintenant (en secondes)
- Capacité nominale de charge complète de la batterie (en μAh)
Voir le diagramme UML suivant pour les classes utiles à l'implémentation HAL de santé :
Figure 7. Diagramme UML HAL 2.1 Santé
Pour plus d'informations sur l'implémentation du service Health 2.1, voir Implémentation de Health 2.1 .
Interface AIDL HAL version 1
Modifications de l'API
La HAL AIDL version 1 prend en charge des API similaires à la 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 portées sur AIDL HAL. Étant donné que la fonctionnalité de charge en mode hors tension n'existe que sur la partition
/vendor
, les API de l'interface fournisseur ne sont pas nécessaires. Pour mettre en œuvre correctement la charge hors mode, voir le chargeur ci-dessous. - Le type
StorageAttribute
et les champs associés sont supprimés car ils ne sont pas utilisés. -
chargerDockOnline
est ajouté àHealthInfo
pour prendre en charge la charge de la station d'accueil.
Mise en œuvre
Voir le diagramme UML suivant pour les classes utiles à l'implémentation HAL de santé :
Figure 8. Diagramme UML HAL Health AIDL
Pour plus d'informations sur l'implémentation du service Health AIDL, consultez Implémentation de Health AIDL HAL .
Récupération
Android 13 prend en charge le classeur dans la récupération. L'installation du service Health AIDL pour la récupération lui permet de s'exécuter en mode de récupération.
Pour plus d'informations sur l'installation du service Health AIDL pour la récupération, consultez les éléments suivants :
Chargeur
La fonctionnalité de charge en mode hors tension est déplacée de /system
vers /vendor
. Pour les appareils lancés avec Android 13, s'ils prennent en charge la charge en mode hors tension, le binaire du service HAL doit prendre en charge le mode chargeur. Pour ce faire, reportez-vous à la section mise en œuvre du 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, reportez-vous aux propriétés système du chargeur .