Pour prendre en charge la gestion de l'alimentation spécifique au véhicule, Android fournit un service CarPowerManagementService
et une interface CarPowerManager
.
Les transitions d'état sont déclenchées par l'unité de contrôle principale du véhicule (VMCU). Pour communiquer avec le VMCU, les intégrateurs doivent implémenter plusieurs composants. Les intégrateurs sont responsables de l'intégration avec la couche d'abstraction matérielle du véhicule (VHAL) et de l'implémentation du noyau. Les intégrateurs sont également chargés de désactiver les sources de réveil et de veiller à ce que les arrêts ne soient pas reportés indéfiniment.
Terminologie
Ces termes sont utilisés tout au long de ce document :
suspend()
et shutdown()
.Conception du système
Cette section décrit comment AAOS représente l'état d'alimentation du processeur d'application et quels modules implémentent le système de gestion de l'alimentation. Ce document décrit également comment ces modules fonctionnent ensemble et comment les transitions d'état se produisent généralement.
Machine d'état de puissance de voiture
AAOS utilise une machine à états pour représenter l'état d'alimentation du point d'accès. La machine à états fournit les états illustrés ci-dessous :
Figure 1. Machine à états de puissance de voiture.
Les transitions les plus courantes sont surlignées en bleu. Voici les états et transitions courantes :
- Suspension vers la RAM. Le véhicule et le SoC sont éteints. Aucun code n'est en cours d'exécution. L'alimentation est maintenue dans la RAM du SoC.
- Attendez VHAL. Lorsque le conducteur interagit avec le véhicule, par exemple en ouvrant une porte, le VMCU alimente le SoC. AAOS revient de Suspend-to-RAM et entre en attente de VHAL, où il attend la coordination avec le VHAL.
- Sur. Le VHAL indique à AAOS d'entrer dans l'état On. Dans cet état, AAOS fonctionne pleinement et interagit avec le pilote.
- Arrêt Préparez-vous. Lorsque le conducteur a fini de conduire, le VHAL demande à l'AAOS d'entrer dans la préparation à l'arrêt. Dans cet état, l'affichage et le son sont désactivés et AAOS n'interagit pas avec le pilote. Le système Android est toujours en cours d'exécution et vous pouvez mettre à jour librement les applications et le système Android. Lorsque les mises à jour, le cas échéant, sont terminées, le système Android entre dans Attendre la fin de VHAL.
- Attendez la fin de VHAL. À ce stade, AAOS informe le VHAL qu'il est prêt à s'arrêter. Le VMCU devrait placer le SoC en veille profonde et couper l'alimentation du processeur de l'application. AAOS est alors dans l'état Suspend-to-RAM, bien qu'aucun code ne soit exécuté.
Modules de gestion de l'alimentation
Le système de gestion de l'énergie est composé de ces modules :
Nom du module | Description |
---|---|
CarPowerManager | API Java ou C++. |
CarPowerManagementService | Coordonne les transitions d’état d’alimentation. |
Démon CarPowerPolicy | Communique avec les clients de stratégie d’alimentation natifs. |
Véhicule HAL | Interface vers la VMCU. |
Noyau | Suspendre à l'implémentation de la RAM ou du disque. |
La fonctionnalité de veille prolongée/hibernation (suspension d'Android sur la RAM/le disque) est implémentée dans le noyau. Cette fonctionnalité est exposée à l'espace utilisateur sous la forme d'un fichier spécial situé dans /sys/power/state
. AAOS est suspendu en écrivant mem
ou disk
dans ce fichier.
Le CPMS coordonne l’état de l’énergie avec d’autres services et HAL. Le CPMS implémente la machine à états décrite ci-dessus et envoie des notifications à chaque observateur lorsqu'une transition d'état d'alimentation se produit. Ce service utilise également le VHAL pour envoyer des messages au matériel.
Le CPPD gère la politique énergétique jusqu'à ce que le CPMS en prenne le contrôle. Il envoie également des notifications de changement de politique d'alimentation aux auditeurs natifs.
Certaines propriétés sont définies dans le VHAL. Pour communiquer avec le VMCU, le CPMS lit et écrit ces propriétés. les applications peuvent utiliser l'interface définie dans le CPM pour surveiller les changements d'état d'alimentation. Cette interface permet également aux applications d'enregistrer les écouteurs de stratégie d'alimentation . Cette API peut être appelée depuis Java et est annotée avec l'API @hide / @System, ce qui signifie qu'elle n'est disponible que pour les applications privilégiées. La relation entre ces modules, applications et services est illustrée ci-dessous :
Figure 2. Schéma de référence des composants de puissance.
Séquence de messages
La section précédente a décrit les modules qui composent le système de gestion de l'alimentation. Cette section utilise les exemples d'entrée et de sortie du sommeil profond pour expliquer comment les modules et les applications communiquent :
Entrez dans le sommeil profond
Seule la VMCU peut lancer une veille profonde. Une fois le sommeil profond lancé, le VMCU envoie une notification au CPMS via le VHAL. Le CPMS change l'état en SHUTDOWN PREPARE et diffuse cette transition d'état à tous les observateurs (les applications et services qui surveillent le CPMS) en appelant la méthode onStateChanged()
avec un nouvel ID d'état fourni par le CPM.
Le CPM sert d'intermédiaire entre les applications/services et le CPMS. La méthode onStateChanged()
pour les applications/services est invoquée de manière synchrone dans la méthode onStateChanged()
du CPM. La plupart des applications et services doivent terminer leur préparation avant de revenir de cet appel. Les services privilégiés sont autorisés à poursuivre leurs préparations de manière asynchrone après leur retour pour PRE_SHUTDOWN_PREPARE
, SUSPEND_ENTER
, POST_SUSPEND_ENTER
. Dans ce cas, le service privilégié est censé appeler complete() sur l'objet CompletablePowerStateChangeFuture
fourni lorsqu'il termine sa préparation. Notez que la préparation asynchrone n'est pas autorisée pour SHUTDOWN_PREPARE
. Avant que DEEP_SLEEP_ENTRY
ne soit envoyé au VHAL, le CPMS envoie périodiquement des demandes de report d'arrêt au VHAL.
Lorsque tous les objets CPM ont terminé les préparatifs d'arrêt, le CPMS envoie AP_POWER_STATE_REPORT
au VHAL, qui informe ensuite le VMCU que l'AP est prêt à suspendre. Le CPMS appelle également sa méthode suspend, qui suspend le noyau.
La séquence décrite ci-dessus est illustrée ci-dessous :
Figure 3. Entrez dans le sommeil profond.
Interfaces de programmation fournies par CPM
Cette section décrit l'API Java fournie par le CPM pour les applications et services système. Cette API permet au logiciel système de :
- Surveillez les changements d’état d’alimentation dans le point d’accès.
- Appliquer des politiques d’alimentation.
Utilisez ces étapes pour appeler les API fournies par le CPM :
- Pour acquérir l'instance CPM, appelez l'API Car.
- Appelez la méthode appropriée sur l'objet créé à l'étape 1.
Créer un objet CarPowerManager
Pour créer un objet CPM, appelez la méthode getCarManager()
de l'objet Car. Cette méthode est une façade utilisée pour créer des objets CPM. Spécifiez android.car.Car.POWER_SERVICE
comme argument pour créer un objet CPM.
Car car = Car.createCar(this); CarPowerManager powerManager = (CarPowerManager) car.getCarManager(android.car.Car.POWER_SERVICE);
CarPowerStateListener et enregistrement
Les applications et services système peuvent recevoir des notifications de changement d'état d'alimentation en implémentant CarPowerManager.CarPowerStateListener
. Cette interface définit une méthode onStateChanged()
, qui est une fonction de rappel invoquée lorsque l'état d'alimentation du CPMS est modifié. L'exemple suivant définit une nouvelle classe anonyme qui implémente l'interface :
private final CarPowerManager.CarPowerStateListener powerListener = new CarPowerManager.CarPowerStateListener () { @Override public void onStateChanged(int state) { Log.i(TAG, "onStateChanged() state = " + state); } };
Pour demander à cet objet d'écoute de surveiller une transition d'état d'alimentation, créez un nouveau thread d'exécution et enregistrez l'écouteur et ce thread dans l'objet CPM :
executor = new ThreadPerTaskExecutor(); powerManager.setListener(powerListener, executor);
Lorsque l'état d'alimentation est modifié, la méthode onStateChanged()
de l'objet écouteur est invoquée avec une valeur pour représenter le nouvel état d'alimentation. L'association entre la valeur réelle et l'état de puissance est définie dans CarPowerManager
et est présentée dans le tableau suivant :
Nom | Description |
---|---|
ETAT_ON | Entrez l'état activé. Le système est pleinement opérationnel. |
STATE_SHUTDOWN_CANCELLED | L'arrêt est annulé et l'état d'alimentation revient à l'état normal. |
STATE_SHUTDOWN_ENTER | les applications devraient être nettoyées et prêtes à être arrêtées. |
STATE_POST_SHUTDOWN_ENTER | Les préparatifs pour l'arrêt sont terminés et VMCU est prêt à être arrêté. Entrez dans l'état d'arrêt. |
STATE_PRE_SHUTDOWN_PREPARE | Le processus d'arrêt est demandé mais CPMS ne démarre pas encore le processus. L'affichage et le son sont toujours activés |
STATE_SHUTDOWN_PREPARE | Le mode Garage peut fonctionner pendant cette période. |
STATE_SUSPEND_ENTER | les applications devraient être nettoyées et prêtes à être suspendues dans la RAM. |
STATE_POST_SUSPEND_ENTER | Les préparatifs pour la suspension vers la RAM sont terminés et VMCU est prêt pour la suspension vers la RAM. Entrez dans l'état de suspension. |
STATE_SUSPEND_EXIT | Réveillez-vous après une suspension ou reprenez après une suspension annulée. |
STATE_HIBERNATION_ENTER | les applications devraient être nettoyées et prêtes pour la mise en veille prolongée. |
STATE_POST_HIBERNATION_ENTER | Les préparatifs pour l'hibernation sont terminés et VMCU est prêt pour l'hibernation. Entrez dans l'état d'hibernation. |
STATE_HIBERNATION_EXIT | Réveillez-vous d'une hibernation ou reprenez une hibernation annulée. |
STATE_WAIT_FOR_VHAL | Le système démarre, mais attend d'établir la communication avec le VHAL avant de passer à l'état ON. |
Désinscription de CarPowerStateListener
Pour désinscrire tous les objets d'écoute enregistrés sur CPM, appelez la méthode clearListener
:
powerManager.clearListener();
Intégration système sur votre implémentation Android
Les intégrateurs sont responsables des éléments suivants :
- Implémentation de l'interface du noyau pour suspendre Android.
- Implémentation des fonctions VHAL pour :
- Propager le lancement de la suspension ou de l'arrêt de la voiture vers Android.
- Envoyez le message prêt à l'arrêt d'Android à la voiture.
- Lancez l’arrêt ou la suspension d’Android via l’interface du noyau Linux.
- Assurez-vous que toutes les sources de réveil sont désactivées lorsque l'appareil est en suspension.
- Assurez-vous que les applications s'arrêtent suffisamment rapidement pour ne pas retarder indéfiniment le processus d'arrêt.
- Assurez-vous que le BSP allume (ou éteint) les composants de l'appareil conformément à la politique d'alimentation afin de ne pas bloquer la suspension ou l'hibernation.
Interface noyau : /sys/power/state
AAOS place un appareil en mode suspension lorsqu'une application ou un service écrit mem
pour une suspension sur RAM ou disk
pour une suspension sur disque dans un fichier situé dans /sys/power/state
. L'intégrateur doit fournir une fonction qui surveille ce fichier et met Linux en état de suspension d'alimentation. Cette fonction peut envoyer un GPIO à la VMCU pour informer la VMCU que l'appareil s'est complètement arrêté. L'intégrateur est également chargé de supprimer toute condition de concurrence entre VHAL envoyant le message final au VMCU et le passage du système en mode suspension ou arrêt.
Responsabilité du VHAL
Le VHAL fournit une interface entre le réseau du véhicule et Android. Le VHAL :
- Propage le lancement de la suspension ou de l'arrêt de la voiture vers Android.
- Envoie le message prêt à l'arrêt d'Android à la voiture.
- Initie l'arrêt ou la suspension d'Android via l'interface du noyau Linux.
Lorsque le CPMS informe le VHAL qu'il est prêt à s'arrêter, le VHAL envoie le message prêt à l'arrêt au VMCU. En règle générale, les périphériques intégrés tels que UART, SPI et USB transmettent le message. Une fois le message envoyé, le CPMS appelle la commande du noyau pour suspendre ou arrêter l'appareil. Avant de faire cela, le VHAL ou le BSP peut activer un GPIO pour indiquer au VMCU qu'il est possible de couper l'alimentation de l'appareil en toute sécurité.
Le VHAL doit prendre en charge les propriétés suivantes, qui contrôlent la gestion de l'alimentation via le VHAL :
Nom | Description |
---|---|
AP_POWER_STATE_REPORT | Android signale les transitions d'état vers la VMCU avec cette propriété, à l'aide des valeurs d'énumération VehicleApPowerStateReport. |
AP_POWER_STATE_REQ | La VMCU utilise cette propriété pour demander à Android de passer à différents états d'alimentation, à l'aide des valeurs d'énumération VehicleApPowerStateReq. |
AP_POWER_STATE_REPORT
Utilisez cette propriété pour signaler l'état actuel de la gestion de l'alimentation d'Android. Cette propriété contient deux entiers :
-
int32Values[0]
: énumération VehicleApPowerStateReport de l’état actuel. -
int32Values[1]
: Temps en millisecondes pour reporter, mettre en veille ou arrêter. La signification de cette valeur dépend de la première valeur.
La première valeur peut prendre l'une des valeurs suivantes. VehicleApPowerStateReport.aidl
contient des descriptions plus spécifiques, qui sont stockées dans le hardware/interfaces/automotive/vehicle/aidl/android/hardware/automotive/vehicle
.
Nom de la valeur | Description | Deuxième valeur |
---|---|---|
WAIT_FOR_VHAL | AP démarre et doit établir la communication avec le VHAL. | |
DEEP_SLEEP_ENTRY | AP entre dans l’état de sommeil profond. La VMCU doit réactiver le point d'accès après le délai spécifié dans la deuxième valeur. | Doit être réglé |
DEEP_SLEEP_EXIT | AP sort de l’état de sommeil profond. | |
HIBERNATION_ENTRY | AP entre en état d’hibernation. La VMCU doit réactiver le point d'accès après le délai spécifié dans la deuxième valeur. | Doit être réglé |
HIBERNATION_EXIT | AP sort de l'état d'hibernation. | |
SHUTDOWN_POSTPONE | Android n'est pas prêt à s'arrêter. La VMCU doit attendre le temps spécifié dans la deuxième valeur avant d'arrêter le point d'accès. Android peut demander un report supplémentaire en émettant des rapports SHUTDOWN_POSTPONE supplémentaires. | Doit être réglé |
SHUTDOWN_PREPARE | Android se prépare à s'arrêter. | Doit être réglé |
SHUTDOWN_START | AP est prêt à s'arrêter. La VMCU doit réactiver le point d'accès après le délai spécifié dans la deuxième valeur. (Le VMCU n'est pas tenu de prendre en charge la fonctionnalité d'activation programmée.) | Doit être réglé |
SHUTDOWN_CANCELLED | Android cesse de se préparer à l'arrêt et passera à WAIT_FOR_VHAL. | |
SUR | Android fonctionne normalement. |
L'état peut être défini de manière autonome ou en réponse à une demande via la VMCU.
AP_POWER_STATE_REQ
Cette propriété est envoyée par la VMCU pour faire passer Android à un état d'alimentation différent et contient deux entiers :
-
int32Values[0]
: valeur enumVehicleApPowerStateReq
, qui représente le nouvel état vers lequel passer. -
int32Values[1]
: valeur d'énumérationVehicleApPowerStateShutdownParam
. Cette valeur est envoyée uniquement pour un messageSHUTDOWN_PREPARE
et transmet à Android les options qu'elle contient.
La première valeur entière représente le nouvel état dans lequel Android doit transiter. La sémantique est définie dans VehicleApPowerStateReq.aidl
et fournie ci-dessous :
Nom de la valeur | Description |
---|---|
SUR | AP devrait commencer à fonctionner pleinement. |
SHUTDOWN_PREPARE | L'AP doit se préparer à s'arrêter. La deuxième valeur indique si le point d'accès est autorisé à reporter l'arrêt et s'il doit s'attendre à s'éteindre ou à entrer en veille profonde. |
CANCEL_SHUTDOWN | Le point d'accès doit cesser de se préparer à s'arrêter et se préparer à se rallumer. |
FINI | L'AP va maintenant être arrêté ou suspendu. |
VehicleApPowerStateShutdownParam
est défini dans VehicleApPowerStateShutdownParam.aidl
. Cette énumération contient ces éléments :
Nom de la valeur | Description |
---|---|
PEUT DORMIR | AP peut entrer en veille profonde au lieu de s'arrêter complètement. Le report est autorisé. |
CAN_HIBERNATE | AP peut entrer en veille prolongée au lieu de s'arrêter complètement. Le report est autorisé. |
SHUTDOWN_ONLY | AP devrait s'arrêter. Le report est autorisé. Le sommeil profond n'est pas autorisé. |
DORMIR_IMMEDIATELY | AP peut entrer en veille profonde, mais doit soit dormir, soit s'arrêter immédiatement. Le report n’est pas autorisé. |
HIBERNATE_IMMEDIATELY | AP peut entrer en suspension sur disque, mais doit soit se mettre en veille prolongée, soit s'arrêter immédiatement. Le report n’est pas autorisé. |
SHUTDOWN_IMMEDIATELY | AP doit s'arrêter immédiatement. Le report n'est pas autorisé. Le sommeil profond n'est pas autorisé. |
Sources de réveil
L'intégrateur doit désactiver les sources de réveil appropriées lorsque l'appareil est en mode suspension. Les sources de réveil courantes incluent les battements de cœur, le modem, le Wi-Fi et le Bluetooth. La seule source de réveil valide doit être une interruption de la VMCU pour réveiller le SoC. Cela suppose que la VMCU peut écouter le modem pour les événements de réveil à distance (tels que le démarrage du moteur à distance). Si cette fonctionnalité est transmise au point d'accès, une autre source de réveil pour desservir le modem doit être ajoutée.
applications
Les OEM doivent veiller à écrire des applications de manière à ce qu’elles puissent être arrêtées rapidement et à ne pas retarder le processus indéfiniment.
annexe
Répertoires dans l'arborescence du code source
Contenu | Annuaire |
---|---|
Code associé à CarPowerManager. | packages/services/Car/car-lib/src/android/car/hardware/power |
CarPowerManagementService et ainsi de suite. | packages/services/Car/service/src/com/android/car/power |
Services traitant du VHAL, tels que VehicleHal et HAlClient . | packages/services/Car/service/src/com/android/car/hal |
Interface VHAL et définitions de propriétés. | hardware/interfaces/automotive/vehicle/aidl/android/hardware/automotive/vehicle/ |
Exemple d'application pour donner une idée sur CarPowerManager | packages/services/Car/tests/EmbeddedKitchenSinkApp/src/com/google/android/car/kitchensink |
Diagramme de classes
Ce diagramme de classes affiche les classes et interfaces Java dans le système de gestion de l'alimentation :
Figure 4. Diagramme de classe de puissance.
Relation d'objet
La figure 5 illustre quels objets ont des références à d'autres objets. Un bord signifie que l'objet source contient une référence à l'objet cible. Par exemple, VehicleHAL a une référence à un objet PropertyHalService.
Figure 5. Diagramme de référence d'objet.