Gestion de l'alimentation

Pour prendre en charge la gestion de l'alimentation spécifique aux véhicules, Android fournit un service CarPowerManagementService et une interface CarPowerManager.

Les transitions d'état sont déclenchées par l'unité de commande principale du véhicule (VMCU, Vehicle Master Control Unit). Pour communiquer avec le VMCU, les intégrateurs doivent implémenter plusieurs composants. Les intégrateurs sont responsables de l'intégration à la couche d'abstraction matérielle du véhicule (VHAL) et à l'implémentation du noyau. Les intégrateurs sont également responsables de la désactivation des sources de sortie de veille et de la garantie que les arrêts ne sont pas reportés indéfiniment.

Terminologie

Les termes suivants sont utilisés dans ce document :

Conception du système

Cette section décrit comment AAOS représente l'état d'alimentation du processeur d'application et les modules qui implémentent le système de gestion de l'alimentation. Ce contenu décrit également le fonctionnement de ces modules ensemble et la façon dont les transitions d'état se produisent généralement.

Machine à états de l'alimentation de la voiture

AAOS utilise une machine à états pour représenter l'état d'alimentation de l'AP. La machine à états fournit les états illustrés ci-dessous :

Figure 1. Machine à états de l'alimentation de la voiture.

Les transitions les plus courantes sont mises en évidence en bleu. Voici les états et les transitions courantes :

• Suspendre vers la RAM Le véhicule et le SoC sont éteints. Aucun code n'est exécuté. L'alimentation est maintenue pour la RAM du SoC.
• Attendez VHAL. Lorsque le conducteur interagit avec le véhicule, par exemple en ouvrant une portière, le VMCU alimente le SoC. AAOS reprend l'exécution à partir de la suspension vers la RAM et passe à l'état "Attente de VHAL", où il attend la coordination avec le VHAL.
• Activé Le VHAL indique à AAOS de passer à l'état "On" (Activé). Dans cet état, AAOS est entièrement opérationnel et interagit avec le conducteur.
• Préparation avant la mise hors service Lorsque le conducteur a terminé de conduire, la VHAL indique à AAOS de passer à la phase de préparation à l'arrêt en envoyant SHUTDOWN_PREPARE. Dans cet état, les écouteurs de changement d'état de l'alimentation reçoivent STATE_PRE_SHUTDOWN_PREPARE. Cela sert d'avertissement précoce indiquant que l'arrêt est en cours.
• Préparez-vous à l'arrêt. Lorsque tous les écouteurs sont terminés ou que le délai d'expiration de la préparation avant l'arrêt est atteint, le système Android passe à la phase de préparation avant l'arrêt du cœur, en informant les écouteurs avec STATE_SHUTDOWN_PREPARE. L'écran et le son sont désactivés, et AAOS n'interagit pas avec le conducteur. Le système Android est toujours en cours d'exécution et peut effectuer des opérations de nettoyage et de mise à jour, comme l'exécution du mode Garage.
• Attendez que la VHAL ait terminé. À ce stade, AAOS informe le VHAL qu'il est prêt à s'éteindre. Le VMCU est censé mettre le SoC en veille profonde et couper l'alimentation du processeur d'application. AAOS est alors en état de suspension vers la RAM, bien qu'aucun code ne soit exécuté.

Modules de gestion de l'alimentation

Le système de gestion de l'alimentation se compose des modules suivants :

La fonctionnalité de veille prolongée/hibernation (suspension d'Android vers 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é à l'adresse /sys/power/state. AAOS est suspendu en écrivant mem ou disk dans ce fichier.

Le CPMS coordonne l'état de l'alimentation 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 la VHAL pour envoyer des messages au matériel.

Le CPPD est la source de vérité pour les règles d'alimentation. Il gère les règles d'alimentation tout au long du cycle de vie de l'appareil et informe le CPMS, le VHAL et les autres écouteurs natifs des modifications apportées aux règles d'alimentation. Le CPMS délègue les demandes de modification des règles relatives à l'alimentation au CPPD.

Le CPMS communique avec le VMCU en lisant et en écrivant les propriétés VHAL liées à l'état de l'alimentation, telles que AP_POWER_STATE_REQ et AP_POWER_STATE_REPORT. Les applications peuvent utiliser l'interface définie dans le CPM pour surveiller les changements d'état de l'alimentation. Cette interface permet également aux applications d'enregistrer des écouteurs de règles d'alimentation. Cette API Java est annotée avec @SystemApi et @hide, ce qui la rend disponible uniquement 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 d'alimentation.

Séquence de messages

La section précédente décrivait les modules qui composent le système de gestion de l'alimentation. Cette section utilise les exemples enter deep sleep et exit deep sleep pour expliquer comment les modules et les applications communiquent :

Passer en sommeil profond

Seul le VMCU peut initier le mode veille prolongée. Une fois le mode veille profonde initié, le VMCU envoie une notification au CPMS via le VHAL. Le CPMS passe à l'état 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 appelée de manière synchrone dans la méthode onStateChanged() du CPM. La plupart des applications et des services doivent terminer leur préparation avant de revenir de cet appel. Les services privilégiés sont autorisés à poursuivre leurs préparatifs de manière asynchrone après le 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 a terminé 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é à la VHAL, le CPMS envoie régulièrement des demandes de report de l'arrêt à la VHAL.

Une fois que 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 à être suspendu. Le CPMS appelle également sa méthode de suspension, qui suspend le noyau.

La séquence décrite ci-dessus est illustrée ci-dessous :

Figure 3. Passer en mode 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 :

• Surveillez les changements d'état de l'alimentation du point d'accès.
• Appliquez les règles d'alimentation.

Pour appeler les API fournies par le CPM, procédez comme suit :

1. Pour obtenir l'instance CPM, appelez l'API Car.
2. 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 de l'alimentation en implémentant CarPowerManager.CarPowerStateListener. Cette interface définit une méthode onStateChanged(), qui est une fonction de rappel appelé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'écouteur de surveiller une transition d'état de l'alimentation, créez un 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 de l'alimentation est modifié, la méthode onStateChanged() de l'objet d'écouteur est appelée avec une valeur représentant le nouvel état de l'alimentation. L'association entre la valeur réelle et l'état d'alimentation est définie dans CarPowerManager et est indiquée dans le tableau suivant :

Désinscription de CarPowerStateListener

Pour annuler l'enregistrement de tous les objets d'écouteur enregistrés auprès du CPM, appelez la méthode clearListener :

powerManager.clearListener();

Intégration du système à votre implémentation Android

Les intégrateurs sont responsables des éléments suivants :

• Implémenter l'interface du noyau pour suspendre Android.
• Implémentez les fonctions VHAL pour :
  • Propagez l'initiation 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 sortie de veille sont désactivées lorsque l'appareil est en veille.
• Assurez-vous que les applications s'arrêtent assez rapidement pour ne pas reporter indéfiniment le processus d'arrêt.
• Assurez-vous que le BSP active (ou désactive) les composants de l'appareil conformément à la stratégie d'alimentation afin de ne pas bloquer la suspension ou l'hibernation.

Interface du noyau : /sys/power/state

AAOS place un appareil en mode veille lorsqu'une application ou un service écrit mem pour la mise en veille avec RAM ou disk pour la mise en veille avec disque dans un fichier situé à l'adresse /sys/power/state. L'intégrateur doit fournir une fonction qui surveille ce fichier et met Linux en état de suspension. Cette fonction peut envoyer un GPIO au VMCU pour l'informer que l'appareil est complètement éteint. L'intégrateur est également responsable de la suppression des conditions de concurrence entre le VHAL qui envoie le message final au VMCU et le système qui passe en mode veille ou arrêt.

Responsabilité du VHAL

La VHAL fournit une interface entre le réseau du véhicule et Android. VHAL :

• Propage l'initiation de la suspension ou de l'arrêt de la voiture à Android.
• Envoie le message "arrêt prêt" d'Android à la voiture.
• Lance l'arrêt ou la mise en veille 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 "shutdown ready" (arrêt prêt) au VMCU. En règle générale, les périphériques sur puce 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 le faire, le VHAL ou le BSP peuvent activer un GPIO pour indiquer au VMCU qu'il est possible de couper l'alimentation de l'appareil.

Le VHAL doit être compatible avec les propriétés suivantes, qui contrôlent la gestion de l'alimentation via le VHAL :

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 nombres entiers :

• int32Values[0] : énumération VehicleApPowerStateReport de l'état actuel.
• int32Values[1] : durée en millisecondes pour mettre en veille, suspendre 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, stockées dans hardware/interfaces/automotive/vehicle/aidl/android/hardware/automotive/vehicle.

L'état peut être défini de manière autonome ou en réponse à une requête via le VMCU.

AP_POWER_STATE_REQ

Cette propriété est envoyée par le VMCU pour faire passer Android à un autre état d'alimentation. Elle contient deux entiers :

• int32Values[0] : valeur d'énumération VehicleApPowerStateReq, qui représente le nouvel état vers lequel effectuer la transition.
• int32Values[1] : valeur d'énumération VehicleApPowerStateShutdownParam. Cette valeur n'est envoyée que pour un message SHUTDOWN_PREPARE et transmet à Android les options qu'il contient.

La première valeur entière représente le nouvel état dans lequel Android doit passer. La sémantique est définie dans VehicleApPowerStateReq.aidl et fournie ci-dessous :

VehicleApPowerStateShutdownParam est défini dans VehicleApPowerStateShutdownParam.aidl. Cette énumération comporte les éléments suivants :

Sources d'activation

L'intégrateur doit désactiver les sources de réveil appropriées lorsque l'appareil est en mode suspendu. Les sources de réveil courantes incluent les battements de cœur, le modem, le Wi-Fi et le Bluetooth. La seule source de sortie de veille valide doit être une interruption du VMCU pour sortir le SoC de veille. Cela suppose que le VMCU peut écouter le modem pour les événements de sortie de veille à distance (comme le démarrage du moteur à distance). Si cette fonctionnalité est transférée au processeur d'applications, une autre source de sortie de veille pour desservir le modem doit être ajoutée.

Applications

Les OEM doivent veiller à écrire des applications qui peuvent être arrêtées rapidement et ne pas reporter le processus indéfiniment.

Annexe

Répertoires dans l'arborescence du code source

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 Power.

Relation entre les objets

La figure 5 illustre les objets qui contiennent des références à d'autres objets. Une arête signifie que l'objet source contient une référence à l'objet cible. Par exemple, VehicleHAL possède une référence à un objet PropertyHalService.

Figure 5. Diagramme de référence d'objet.