Gestione alimentazione

Per supportare la gestione dell'alimentazione specifica per il veicolo, Android fornisce un servizio CarPowerManagementService e un'interfaccia CarPowerManager.

Le transizioni di stato vengono attivate dalla Vehicle Master Control Unit (VMCU). Per comunicare con la VMCU, gli integratori devono implementare diversi componenti. Gli integratori sono responsabili dell'integrazione con il livello di astrazione hardware del veicolo (VHAL) e l'implementazione del kernel. Gli integratori sono anche responsabili della disattivazione delle origini di riattivazione e di garantire che gli spegnimenti non vengano posticipati indefinitamente.

Terminologia

In questo documento vengono utilizzati i seguenti termini:

Progettazione del sistema

Questa sezione descrive come AAOS rappresenta lo stato di alimentazione del processore dell'app e quali moduli implementano il sistema di gestione dell'alimentazione. Questo materiale descrive anche come funzionano questi moduli insieme e come si verificano in genere le transizioni di stato.

Macchina degli stati di alimentazione dell'auto

AAOS utilizza una macchina a stati per rappresentare lo stato di alimentazione dell'AP. La macchina a stati fornisce gli stati illustrati di seguito:

Figura 1. Macchina a stati di alimentazione dell'auto.

Le transizioni più comuni sono evidenziate in blu. Di seguito sono riportati gli stati e le transizioni comuni:

• Sospensione alla RAM.Il veicolo e il SoC sono spenti. Non viene eseguito alcun codice. L'alimentazione viene mantenuta nella RAM del SoC.
• Attendi VHAL.Quando il conducente interagisce con il veicolo, ad esempio aprendo una portiera, la VMCU applica l'alimentazione al SoC. AAOS riprende dallo stato di sospensione alla RAM ed entra nello stato di attesa di VHAL, in cui attende il coordinamento con VHAL.
• On.VHAL indica ad AAOS di entrare nello stato On. In questo stato, AAOS è in esecuzione e interagisce completamente con il conducente.
• Shutdown Prepare.Quando il conducente ha finito di guidare, VHAL comunica ad AAOS di entrare in Shutdown Prepare. In questo stato, il display e l'audio sono disattivati e AAOS non interagisce con il conducente. Il sistema Android è ancora in esecuzione ed è libero di aggiornare le app e il sistema Android. Al termine degli aggiornamenti, se presenti, il sistema Android entra in Wait for VHAL Finish.
• Attendi il completamento di VHAL.A questo punto, AAOS comunica a VHAL che è pronto per lo spegnimento. Il VMCU dovrebbe mettere il SoC in Deep Sleep e rimuovere l'alimentazione dal processore dell'app. AAOS si trova quindi nello stato di sospensione alla RAM, anche se non viene eseguito alcun codice.

Moduli di gestione dell'alimentazione

Il sistema di gestione dell'alimentazione è composto dai seguenti moduli:

La funzionalità di sospensione/ibernazione (sospensione di Android nella RAM/sul disco) è implementata nel kernel. Questa funzionalità è esposta allo spazio utente come file speciale che si trova in /sys/power/state. AAOS viene sospeso scrivendo mem o disk in questo file.

Il CPMS coordina lo stato di alimentazione con altri servizi e HAL. Il CPMS implementa la macchina a stati descritta sopra e invia notifiche a ogni osservatore quando si verifica una transizione dello stato di alimentazione. Questo servizio utilizza anche VHAL per inviare messaggi all'hardware.

Il CPPD è la fonte di verità per le policy di alimentazione. Gestisce le policy di alimentazione durante tutto il ciclo di vita del dispositivo e notifica al CPMS, al VHAL e ad altri listener nativi le modifiche alle policy di alimentazione. Il CPMS delega al CPPD le richieste di modifica delle policy di alimentazione.

Il CPMS comunica con la VMCU leggendo e scrivendo le proprietà VHAL relative allo stato di alimentazione, come AP_POWER_STATE_REQ e AP_POWER_STATE_REPORT. Le app possono utilizzare l'interfaccia definita in CPM per monitorare le modifiche dello stato di alimentazione. Questa interfaccia consente inoltre alle app di registrare i listener dei criteri di alimentazione. Questa API Java è annotata con @SystemApi e @hide, il che la rende disponibile solo per le app con privilegi. La relazione tra questi moduli, app e servizi è illustrata di seguito:

Figura 2. Diagramma di riferimento dei componenti di alimentazione.

Sequenza di messaggi

La sezione precedente descriveva i moduli che compongono il sistema di gestione dell'alimentazione. Questa sezione utilizza gli esempi enter deep sleep e exit deep sleep per spiegare come comunicano i moduli e le app:

Entrare in sonno profondo

Solo la VMCU può avviare la sospensione profonda. Una volta avviata, la VMCU invia una notifica al CPMS tramite VHAL. Il CPMS cambia lo stato in SHUTDOWN PREPARE e trasmette questa transizione di stato a tutti gli osservatori (le app e i servizi che monitorano CPMS) chiamando il metodo onStateChanged() con un nuovo ID stato fornito dal CPM.

Il CPM funge da intermediario tra le app/i servizi e i CPMS. Il metodo onStateChanged() per le app/i servizi viene richiamato in modo sincrono nel metodo onStateChanged() del CPM. La maggior parte delle app e dei servizi deve completare la preparazione prima di tornare da questa chiamata. I servizi privilegiati possono continuare i preparativi in modo asincrono dopo essere tornati per PRE_SHUTDOWN_PREPARE, SUSPEND_ENTER e POST_SUSPEND_ENTER. In questo caso, il servizio privilegiato deve chiamare complete() sull'oggetto CompletablePowerStateChangeFuture fornito al termine della preparazione. Tieni presente che la preparazione asincrona non è consentita per SHUTDOWN_PREPARE. Prima che DEEP_SLEEP_ENTRY venga inviato a VHAL, CPMS invia periodicamente richieste di posticipo dello spegnimento a VHAL.

Quando tutti gli oggetti CPM hanno completato i preparativi per l'arresto, il CPMS invia AP_POWER_STATE_REPORT al VHAL, che a sua volta comunica alla VMCU che l'AP è pronto per la sospensione. Il CPMS chiama anche il metodo di sospensione, che sospende il kernel.

La sequenza descritta sopra è illustrata di seguito:

Figura 3. Entra in sonno profondo.

Interfacce di programmazione fornite da CPM

Questa sezione descrive l'API Java fornita da CPM per app e servizi di sistema. Questa API consente al software di sistema di:

• Monitora le modifiche dello stato di alimentazione nel punto di accesso.
• Applica i criteri di alimentazione.

Segui questi passaggi per chiamare le API fornite dal CPM:

1. Per acquisire l'istanza CPM, chiama l'API Car.
2. Chiama il metodo appropriato sull'oggetto creato nel passaggio 1.

Crea un oggetto CarPowerManager

Per creare un oggetto CPM, chiama il metodo getCarManager() dell'oggetto Car. Questo metodo è un facade utilizzato per creare oggetti CPM. Specifica android.car.Car.POWER_SERVICE come argomento per creare un oggetto CPM.

Car car = Car.createCar(this);
CarPowerManager powerManager =
  (CarPowerManager) car.getCarManager(android.car.Car.POWER_SERVICE);

CarPowerStateListener e registrazione

Le app e i servizi di sistema possono ricevere notifiche di modifica dello stato di alimentazione implementando CarPowerManager.CarPowerStateListener. Questa interfaccia definisce un metodo onStateChanged(), che è una funzione di callback richiamata quando lo stato di alimentazione di CPMS viene modificato. L'esempio seguente definisce una nuova classe anonima che implementa l'interfaccia:

private final CarPowerManager.CarPowerStateListener powerListener =
  new CarPowerManager.CarPowerStateListener () {
    @Override
     public void onStateChanged(int state) {
       Log.i(TAG, "onStateChanged() state = " + state);
     }
};

Per indicare a questo oggetto listener di monitorare una transizione dello stato di alimentazione, crea un nuovo thread di esecuzione e registra il listener e questo thread nell'oggetto CPM:

executor = new ThreadPerTaskExecutor();
powerManager.setListener(powerListener, executor);

Quando lo stato di alimentazione viene modificato, il metodo onStateChanged() dell'oggetto listener viene richiamato con un valore che rappresenta il nuovo stato di alimentazione. L'associazione tra il valore effettivo e lo stato di alimentazione è definita in CarPowerManager e mostrata nella tabella seguente:

CarPowerStateListener unregistration

Per annullare la registrazione di tutti gli oggetti listener registrati in CPM, chiama il metodo clearListener:

powerManager.clearListener();

Integrazione del sistema nell'implementazione Android

Gli integratori sono responsabili dei seguenti elementi:

• Implementazione dell'interfaccia del kernel per sospendere Android.
• Implementare le funzioni VHAL per:
  • Propaga l'avvio della sospensione o dell'arresto dall'auto ad Android.
  • Invia il messaggio di spegnimento pronto da Android all'auto.
  • Avviare l'arresto o la sospensione di Android tramite l'interfaccia del kernel Linux.
• Assicurati che tutte le origini di riattivazione siano disattivate quando il dispositivo è in sospensione.
• Assicurati che le app si chiudano abbastanza rapidamente da non posticipare indefinitamente la procedura di spegnimento.
• Assicurati che il BSP attivi (o disattivi) i componenti del dispositivo in base alla politica di alimentazione in modo da non bloccare la sospensione o l'ibernazione

Interfaccia del kernel: /sys/power/state

AAOS mette un dispositivo in modalità di sospensione quando un'app o un servizio scrive mem per sospensione su RAM o disk per sospensione su disco in un file che si trova in /sys/power/state. L'integratore deve fornire una funzione che monitori questo file e metta Linux in stato di sospensione. Questa funzione potrebbe inviare un GPIO al VMCU per comunicare al VMCU che il dispositivo ha eseguito l'arresto completo. L'integratore è anche responsabile della rimozione di eventuali condizioni di competizione tra l'invio del messaggio finale da parte di VHAL alla VMCU e il passaggio del sistema alla modalità sospensione o spegnimento.

Responsabilità di VHAL

VHAL fornisce un'interfaccia tra la rete del veicolo e Android. VHAL:

• Propaga l'avvio della sospensione o dell'arresto dall'auto ad Android.
• Invia il messaggio di spegnimento pronto da Android all'auto.
• Avvia l'arresto o la sospensione di Android tramite l'interfaccia del kernel Linux.

Quando il CPMS comunica all'HAL del veicolo che è pronto per lo spegnimento, l'HAL del veicolo invia il messaggio di spegnimento pronto alla VMCU. In genere, le periferiche on-chip come UART, SPI e USB trasmettono il messaggio. Una volta inviato il messaggio, il CPMS chiama il comando del kernel per sospendere o spegnere il dispositivo. Prima di farlo, l'HAL del veicolo o il BSP potrebbe attivare/disattivare un GPIO per comunicare alla VMCU che è sicuro rimuovere l'alimentazione dal dispositivo.

L'HAL del veicolo deve supportare le seguenti proprietà, che controllano la gestione dell'alimentazione tramite l'HAL del veicolo:

AP_POWER_STATE_REPORT

Utilizza questa proprietà per segnalare lo stato attuale di gestione dell'alimentazione di Android. Questa proprietà contiene due numeri interi:

• int32Values[0]: Enumerazione VehicleApPowerStateReport dello stato attuale.
• int32Values[1]: tempo in millisecondi per posticipare, mettere in sospensione o spegnere. Il significato di questo valore dipende dal primo valore.

Il primo valore può assumere uno dei seguenti valori. VehicleApPowerStateReport.aidl contiene descrizioni più specifiche, che vengono memorizzate in hardware/interfaces/automotive/vehicle/aidl/android/hardware/automotive/vehicle.

Lo stato può essere impostato autonomamente o in risposta a una richiesta tramite la VMCU.

AP_POWER_STATE_REQ

Questa proprietà viene inviata dalla VMCU per la transizione di Android a uno stato di alimentazione diverso e contiene due numeri interi:

• int32Values[0]: valore enum VehicleApPowerStateReq, che rappresenta il nuovo stato in cui eseguire la transizione.
• int32Values[1]: valore enum VehicleApPowerStateShutdownParam. Questo valore viene inviato solo per un messaggio SHUTDOWN_PREPARE e trasmette ad Android le opzioni che contiene.

Il primo valore intero rappresenta il nuovo stato in cui deve avvenire la transizione di Android. La semantica è definita in VehicleApPowerStateReq.aidl e fornita di seguito:

VehicleApPowerStateShutdownParam è definito in VehicleApPowerStateShutdownParam.aidl. Questo enum ha i seguenti elementi:

Origini di riattivazione

L'integratore deve disattivare le origini di riattivazione appropriate quando il dispositivo è in modalità di sospensione. Le fonti di riattivazione comuni includono battiti cardiaci, modem, Wi-Fi e Bluetooth. L'unica origine di riattivazione valida deve essere un interrupt dalla VMCU per riattivare il SoC. Ciò presuppone che la VMCU possa ascoltare il modem per gli eventi di riattivazione remota (come l'avviamento del motore da remoto). Se questa funzionalità viene inviata all'AP, deve essere aggiunta un'altra origine di riattivazione per gestire il modem.

App

Gli OEM devono prestare attenzione a scrivere app in modo che possano essere chiuse rapidamente e non rimandare indefinitamente la procedura.

Appendice

Directory nell'albero del codice sorgente

Diagramma delle classi

Questo diagramma delle classi mostra le classi e le interfacce Java nel sistema di gestione dell'alimentazione:

Figura 4. Diagramma della classe di potenza.

Relazione tra oggetti

La Figura 5 mostra quali oggetti hanno riferimenti ad altri oggetti. Un arco indica che l'oggetto di origine contiene un riferimento all'oggetto di destinazione. Ad esempio, VehicleHAL ha un riferimento a un oggetto PropertyHalService.

Figura 5. Diagramma di riferimento degli oggetti.