Gestione alimentazione

Per supportare la gestione energetica specifica del veicolo, Android fornisce un servizio CarPowerManagementService e un'interfaccia CarPowerManager .

Le transizioni di stato vengono attivate dall'unità di controllo principale del veicolo (VMCU). Per comunicare con la VMCU, gli integratori devono implementare diversi componenti. Gli integratori sono responsabili dell'integrazione con il livello di astrazione dell'hardware del veicolo (VHAL) e l'implementazione del kernel. Gli integratori sono inoltre responsabili della disabilitazione delle sorgenti di riattivazione e della garanzia che gli arresti non vengano posticipati indefinitamente.

Terminologia

Questi termini vengono utilizzati in tutto questo documento:

Sistema di design

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 inoltre come questi moduli interagiscono e come avvengono in genere le transizioni di stato.

Macchina dello stato di potenza 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 dello stato di potenza dell’auto.

Le transizioni più comuni sono evidenziate in blu. Questi sono gli stati e le transizioni comuni:

• Sospensione su RAM. Il veicolo e il SoC sono spenti. Nessun codice viene eseguito. L'alimentazione viene mantenuta alla RAM del SoC.
• Aspetta VHAL. Quando il conducente interagisce con il veicolo, ad esempio aprendo una porta, la VMCU alimenta il SoC. AAOS riprende da Suspend-to-RAM ed entra in Wait for VHAL, dove attende il coordinamento con il VHAL.
• SU. Il VHAL dice ad AAOS di entrare nello stato On. In questo stato, AAOS è completamente in esecuzione e interagisce con il conducente.
• Preparazione allo spegnimento. Quando il conducente ha finito di guidare, il VHAL dice ad AAOS di entrare in Shutdown Prepare. In questo stato, il display e l'audio sono spenti e AAOS non interagisce con il conducente. Il sistema Android è ancora in esecuzione ed è possibile aggiornare gratuitamente le app e il sistema Android. Una volta completati gli eventuali aggiornamenti, il sistema Android entra in Attendi la fine VHAL.
• Attendi la fine di VHAL. A questo punto, AAOS informa il VHAL che è pronto per lo spegnimento. Si prevede che la VMCU metterà il SoC in Deep Sleep e rimuoverà l'alimentazione dal processore dell'app. AAOS si trova quindi nello stato Suspend-to-RAM, sebbene non venga eseguito alcun codice.

Moduli di gestione dell'energia

Il sistema di gestione dell'energia è composto da questi moduli:

La funzionalità di sospensione/ibernazione profonda (sospensione di Android su RAM/disco) è implementata nel kernel. Questa funzionalità è esposta nello spazio utente come un file speciale situato in /sys/power/state . AAOS viene sospeso scrivendo mem o disk su questo file.

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

Il CPPD gestisce la politica energetica finché il CPMS non assume il controllo. Invia inoltre notifiche di modifica della politica di alimentazione agli ascoltatori nativi.

Alcune proprietà sono definite nel VHAL. Per comunicare con la VMCU, il CPMS legge e scrive queste proprietà. le app possono utilizzare l'interfaccia definita nel 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 può essere richiamata da Java ed è annotata con l'API @hide/@System, il che significa che è disponibile solo per le app privilegiate. La relazione tra questi moduli, app e servizi è illustrata di seguito:

Figura 2. Diagramma di riferimento dei componenti di potenza.

Sequenza dei messaggi

La sezione precedente descriveva i moduli che compongono il sistema di gestione dell'energia. Questa sezione utilizza gli esempi di entrata e uscita dalla modalità deep sleep per spiegare come comunicano i moduli e le app:

Entra nel sonno profondo

Solo la VMCU può avviare il sonno profondo. Una volta avviato il sonno profondo, la VMCU invia una notifica al CPMS tramite il VHAL. Il CPMS modifica 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 di stato fornito dal CPM.

Il CPM media tra le app/i servizi e il CPMS. Il metodo onStateChanged() per le app/i servizi viene richiamato in modo sincrono nel metodo onStateChanged() del CPM. Per la maggior parte delle app e dei servizi è necessario completare la preparazione prima di tornare da questa chiamata. Ai servizi privilegiati è consentito continuare la preparazione in modo asincrono dopo la restituzione di PRE_SHUTDOWN_PREPARE , SUSPEND_ENTER , POST_SUSPEND_ENTER . In questo caso, il servizio privilegiato dovrebbe chiamare complete() sull'oggetto CompletablePowerStateChangeFuture fornito quando termina la preparazione. Tieni presente che la preparazione asincrona non è consentita per SHUTDOWN_PREPARE . Prima che DEEP_SLEEP_ENTRY venga inviato al VHAL, il CPMS invia periodicamente richieste di rinvio dell'arresto al VHAL.

Quando tutti gli oggetti CPM hanno completato i preparativi per l'arresto, il CPMS invia AP_POWER_STATE_REPORT al VHAL, che poi notifica alla VMCU che l'AP è pronto per la sospensione. Il CPMS chiama anche il suo metodo suspend, che sospende il kernel.

La sequenza sopra descritta è di seguito illustrata:

Figura 3. Entra nel 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:

• Monitorare i cambiamenti dello stato di alimentazione nell'AP.
• Applicare politiche energetiche.

Utilizza 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, chiamare il metodo getCarManager() dell'oggetto Car. Questo metodo è una facciata utilizzata 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 viene modificato lo stato di alimentazione del CPMS. 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 istruire questo oggetto listener a monitorare una transizione dello stato di alimentazione, crea un nuovo thread di esecuzione e registra il listener e questo thread sull'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 per rappresentare il nuovo stato di alimentazione. L'associazione tra valore effettivo e stato di potenza è definita in CarPowerManager ed è mostrata nella tabella seguente:

Annullamento della registrazione di CarPowerStateListener

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

powerManager.clearListener();

Integrazione del sistema sulla tua 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 dello spegnimento dall'auto ad Android.
  • Invia il messaggio di pronto spegnimento da Android all'auto.
  • Avvia l'arresto o la sospensione di Android tramite l'interfaccia del kernel Linux.
• Assicurarsi che tutte le sorgenti di attivazione siano disabilitate quando il dispositivo è in sospensione.
• Assicurati che le app si spengano abbastanza velocemente da non posticipare indefinitamente il processo di spegnimento.
• Assicurarsi che il BSP accenda (o spenga) 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 la sospensione su RAM o disk per la sospensione su disco in un file situato in /sys/power/state . L'integratore deve fornire una funzione che monitori questo file e metta Linux nello stato di sospensione dell'alimentazione. Questa funzione può inviare un GPIO alla VMCU per notificare alla VMCU che il dispositivo si è spento completamente. L'integratore è inoltre responsabile della rimozione di eventuali condizioni di competizione tra l'invio del messaggio finale da parte di VHAL alla VMCU e l'entrata del sistema in modalità di sospensione o spegnimento.

Responsabilità VHAL

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

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

Quando il CPMS informa il VHAL che è pronto per l'arresto, il VHAL invia il messaggio di pronto per l'arresto alla VMCU. In genere, le periferiche su chip come UART, SPI e USB trasmettono il messaggio. Una volta inviato il messaggio, il CPMS richiama il comando del kernel per sospendere o spegnere il dispositivo. Prima di farlo, il VHAL o il BSP possono attivare un GPIO per istruire la VMCU che è sicuro rimuovere l'alimentazione dal dispositivo.

Il VHAL deve supportare le seguenti proprietà, che controllano la gestione dell'energia tramite il VHAL:

AP_POWER_STATE_REPORT

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

• int32Values[0] : enumerazione VehicleApPowerStateReport dello stato corrente.
• int32Values[1] : tempo in millisecondi per posticipare, sospendere o arrestare. Il significato di questo valore dipende dal primo valore.

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

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

AP_POWER_STATE_REQ

Questa proprietà viene inviata dalla VMCU per far passare Android in uno stato di alimentazione diverso e contiene due numeri interi:

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

Il primo valore intero rappresenta il nuovo stato in cui transiterà Android. La semantica è definita in VehicleApPowerStateReq.aidl e fornita di seguito:

VehicleApPowerStateShutdownParam è definito in VehicleApPowerStateShutdownParam.aidl . Questa enum ha questi elementi:

Sorgenti di scia

L'integratore deve disabilitare le sorgenti 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 fonte di riattivazione valida deve essere un'interruzione dalla VMCU per riattivare il SoC. Ciò presuppone che la VMCU possa ascoltare il modem per eventi di riattivazione remota (come l'avvio remoto del motore). Se questa funzionalità viene inviata all'AP, è necessario aggiungere un'altra fonte di riattivazione per servire il modem.

App

Gli OEM devono fare attenzione a scrivere app in modo che possano essere chiuse rapidamente e non rinviare il processo indefinitamente.

Appendice

Directory nell'albero del codice sorgente

Diagramma delle classi

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

Figura 4. Diagramma della classe di potenza.

Relazione oggettuale

La Figura 5 illustra quali oggetti hanno riferimenti ad altri oggetti. Un bordo significa che l'oggetto sorgente contiene un riferimento all'oggetto di destinazione. Ad esempio, VehicleHAL ha un riferimento a un oggetto PropertyHalService.

Figura 5. Diagramma di riferimento dell'oggetto.