Gestion de l'alimentation

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 :

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 :

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 :

1. Pour acquérir 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 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 :

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 :

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 .

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 enum VehicleApPowerStateReq , qui représente le nouvel état vers lequel passer.
• int32Values[1] : valeur d'énumération VehicleApPowerStateShutdownParam . Cette valeur est envoyée uniquement pour un message SHUTDOWN_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 :

VehicleApPowerStateShutdownParam est défini dans VehicleApPowerStateShutdownParam.aidl . Cette énumération contient ces éléments :

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

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.