Gestion de l'alimentation

Restez organisé à l'aide des collections Enregistrez et classez les contenus selon vos préférences.

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, Vehicle Master Control Unit). Pour communiquer avec la VMCU, les intégrateurs doivent implémenter plusieurs composants. Les intégrateurs sont chargés de l'intégration avec la couche d'abstraction matérielle du véhicule (VHAL) et l'implémentation du noyau. Les intégrateurs sont également chargés de désactiver les sources de réveil et de s'assurer 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 explique 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 l'alimentation de la 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 la puissance de la voiture.

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

• Suspendre en RAM Le véhicule et le SoC sont éteints. Aucun code n'est exécuté. La RAM du SoC est maintenue sous tension.
• Attendez VHAL. Lorsque le conducteur interagit avec le véhicule, par exemple en ouvrant une porte, le VMCU alimente le SoC. AAOS reprend à partir de la suspension dans la RAM et passe en mode "Attente de VHAL", où il attend la coordination avec le VHAL.
• Activée Le VHAL indique à AAOS de passer à l'état "On" (Activé). Dans cet état, AAOS est entièrement en cours d'exécution et interagit avec le pilote.
• Préparation à l'arrêt Lorsque le conducteur a terminé de conduire, le VHAL indique à l'AAOS de passer en mode Préparation à l'arrêt. Dans cet état, l'écran et l'audio sont désactivés, et l'AAOS n'interagit pas avec le conducteur. Le système Android est toujours en cours d'exécution et peut mettre à jour les applications et le système Android. Une fois les mises à jour, le cas échéant, terminées, le système Android passe en mode "Attente de la fin de VHAL".
• Attendez que VHAL ait terminé. À ce stade, AAOS informe le VHAL qu'il est prêt à s'arrêter. Le VMCU doit placer le SoC en mode veille prolongée et couper l'alimentation du processeur de l'application. AAOS est alors dans l'état "Suspend-to-RAM", même si aucun code n'est 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 (suspendre Android dans la RAM/sur le disque) est implémentée dans le noyau. Cette fonctionnalité est exposée à l'espace utilisateur en tant que 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'alimentation avec d'autres services et HAL. Le CPMS implémente la machine d'état 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 stratégie d'alimentation jusqu'à ce que le CPMS prenne le contrôle. Il envoie également des notifications de modification de la stratégie d'alimentation aux écouteurs 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 de l'alimentation. Cette interface permet également aux applications d'enregistrer des écouteurs de stratégie d'alimentation. Cette API peut être appelée à partir de Java et est annotée avec @hide / @System API, 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 d'alimentation.

Séquence des messages

La section précédente décrit les modules qui composent le système de gestion de l'alimentation. Cette section utilise les exemples entrer en mode veille profonde et sortir du mode veille profonde pour expliquer comment les modules et les applications communiquent:

Passer en mode veille prolongée

Seul le VMCU peut lancer le mode veille profonde. Une fois le mode veille profonde activé, le VMCU envoie une notification au CPMS via le VHAL. Le CPMS définit l'état sur 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 les CPMS. La méthode onStateChanged() des 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éparations de manière asynchrone après le retour pour PRE_SHUTDOWN_PREPARE, SUSPEND_ENTER et POST_SUSPEND_ENTER. Dans ce cas, le service privilégié est censé appeler complete() sur l'objet CompletablePowerStateChangeFuture fourni une fois la préparation terminée. Notez que la préparation asynchrone n'est pas autorisée pour SHUTDOWN_PREPARE. Avant qu'DEEP_SLEEP_ENTRY ne soit envoyé au VHAL, le CPMS envoie régulièrement des requêtes de report de l'arrêt au VHAL.

Lorsque tous les objets CPM ont terminé la préparation de l'arrêt, le CPMS envoie AP_POWER_STATE_REPORT au VHAL, qui avertit 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. Entrer en mode veille prolongée

Interfaces de programmation fournies par le 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 d'effectuer les opérations suivantes:

• Surveillez les changements d'état de l'alimentation dans l'AP.
• Appliquer des 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 d'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 d'alimentation, créez un thread d'exécution et enregistrez l'écouteur et ce thread sur 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 appelée avec une valeur représentant le nouvel état d'alimentation. L'association entre la valeur réelle et l'état de l'alimentation est définie dans CarPowerManager et est indiquée dans le tableau suivant:

Désenregistrement de CarPowerStateListener

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

powerManager.clearListener();

Intégration du système dans 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 :
  • Propagez le début de la suspension ou de l'arrêt de la voiture vers Android.
  • Envoyez le message de préparation à l'arrêt d'Android à la voiture.
  • Démarrez l'arrêt ou la suspension d'Android via l'interface du kernel Linux.
• Assurez-vous que toutes les sources de réveil sont désactivées lorsque l'appareil est en veille.
• 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 stratégie d'alimentation afin de ne pas bloquer la suspension ni l'hibernation.

Interface du noyau: /sys/power/state

AAOS met un appareil en mode suspension lorsqu'une application ou un service écrit mem pour la suspension dans la RAM ou disk pour la suspension sur disque dans un fichier situé à /sys/power/state. L'intégrateur doit fournir une fonction qui surveille ce fichier et met Linux en mode suspension. Cette fonction peut envoyer un GPIO au VMCU pour l'informer que l'appareil est complètement éteint. L'intégrateur est également chargé de supprimer toute condition de course entre l'envoi du message final par VHAL au VMCU et le passage du système en mode suspension ou arrêt.

Responsabilité de VHAL

Le 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 vers Android.
• Envoie le message de préparation à l'arrêt d'Android à la voiture.
• Lance 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 de préparation à 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 kernel pour suspendre ou arrêter l'appareil. Avant de le faire, le VHAL ou le BSP peut activer/désactiver un GPIO pour indiquer au VMCU qu'il est possible de couper l'alimentation de l'appareil.

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]: durée en millisecondes pour différer, 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, qui sont 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 dans un autre état d'alimentation et 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 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 du VMCU pour réveiller le SoC. Cela suppose que le VMCU peut écouter le modem pour détecter 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 le modem doit être ajoutée.

Applis

Les OEM doivent veiller à écrire des applications de sorte qu'elles puissent être arrêtées rapidement et ne pas retarder le processus indéfiniment.

Annexe

Répertoires de l'arborescence du code source

Diagramme de classe

Ce diagramme de classe affiche les classes et interfaces Java du système de gestion de l'alimentation:

Figure 4. Diagramme des classes d'alimentation.

Relation entre les objets

La figure 5 illustre les objets qui font référence à d'autres objets. Un arc signifie que l'objet source contient une référence à l'objet cible. Par exemple, VehicleHAL contient une référence à un objet PropertyHalService.

Figure 5. Schéma de référence des objets.