Gestione alimentazione

Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Per supportare la gestione dell'alimentazione specifica del veicolo, Android fornisce un servizioCarPowerManagementService e un'interfacciaCarPowerManager.

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 Vehicle Hardware Abstraction Layer (VHAL) e l'implementazione del kernel. Gli integratori sono inoltre responsabili della disattivazione delle sorgenti di attivazione e dell'assicurazione che gli arresti non vengano posticipati indefinitamente.

Terminologia

I seguenti termini vengono utilizzati in tutto il documento:

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 il funzionamento di questi moduli insieme e come si verificano in genere le transizioni di stato.

Macchina a stati dello stato di alimentazione dell'auto

AAOS utilizza una macchina a stati per rappresentare lo stato di alimentazione dell'AP. La macchina di stato 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 in RAM. Il veicolo e il SoC sono spenti. Nessun codice viene eseguito. L'alimentazione viene mantenuta per la RAM del SoC.
• Attendi VHAL. Quando il conducente interagisce con il veicolo, ad esempio aprendo una portiera, il VMCU applica l'alimentazione al SoC. AAOS riprende da Sospensione in RAM e passa a Attendi VHAL, dove attende il coordinamento con il VHAL.
• On. Il VHAL indica all'AAOS di passare allo stato On. In questo stato, AAOS è completamente in esecuzione e interagisce con il conducente.
• Preparazione allo spegnimento. Quando il conducente ha terminato di guidare, VHAL chiede all'AAOS di entrare in Preparazione allo spegnimento. In questo stato, il display e l'audio sono disattivati e AAOS non interagisce con il conducente. Il sistema Android è ancora in esecuzione ed è possibile aggiornare le app e il sistema Android. Al termine degli eventuali aggiornamenti, il sistema Android entra in stato Attendi completamento VHAL.
• Attendi il completamento del VHAL. A questo punto, AAOS informa VHAL che è pronto per l'arresto. Il VMCU dovrebbe mettere il SoC in modalità Sospensione profonda e rimuovere l'alimentazione dal processore dell'app. L'AAOS è quindi in stato di sospensione in 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 profonda/ibernazione (sospensione di Android in RAM/disco) è implementata nel kernel. Questa funzionalità è esposta allo spazio utente come file speciale situato in /sys/power/state. L'AAOS viene sospesa scrivendo mem o disk in questo file.

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

Il CPPD gestisce il criterio di alimentazione finché il CPMS non prende il controllo. Inoltre, invia notifiche di variazione del criterio di potenza ai listener 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 variazioni dello stato di alimentazione. Questa interfaccia consente inoltre alle app di registrare ascoltatori di criteri di risparmio energetico. Questa API può essere invocata da Java ed è annotata con @hide / @System API, il che significa che è 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 dell'alimentazione.

Sequenza di messaggi

La sezione precedente descrive 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 i moduli e le app comunicano:

Entrare in sonno profondo

Solo la VMCU può avviare il sonno profondo. Una volta avviato il sonno profondo, la VMCU invia una notification al CPMS tramite VHAL. Il CPMS imposta lo stato su SHUTDOWN PREPARE e broadcasting questa transizione di stato a tutti gli osservatori (le app e i servizi che monitorano il 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 invocato 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 con privilegi possono continuare la loro preparazione in modo asincrono dopo il ritorno per PRE_SHUTDOWN_PREPARE,SUSPEND_ENTER, POST_SUSPEND_ENTER. In questo caso, il servizio privilegiato dovrebbe 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 al VHAL, il CPMS invia periodicamente richieste di posticipazione dell'arresto al VHAL.

Quando tutti gli oggetti CPM hanno completato le preparazioni per l'arresto, il CPMS invia AP_POWER_STATE_REPORT al VHAL, che a sua volta comunica alla VMCU che l'AP è pronto per essere sospeso. Il CPMS chiama anche il proprio 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 dal CPM per le app e i servizi di sistema. Questa API consente al software di sistema di:

• Monitora le modifiche dello stato dell'alimentazione nell'AP.
• Applica i criteri di alimentazione.

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 è 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 relative alla modifica dello stato di alimentazione implementando CarPowerManager.CarPowerStateListener. Questa interfaccia definisce un metodoonStateChanged(), che è una funzione di callback invocata 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 indicare a questo oggetto ascoltatore di monitorare una transizione dello stato di alimentazione, crea un nuovo thread di esecuzione e registra l'ascoltatore 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 valore effettivo e stato di alimentazione è definita in CarPowerManager ed è mostrata nella tabella seguente:

CarPowerStateListener unregistration

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

powerManager.clearListener();

Integrazione del sistema nell'implementazione di Android

Gli integratori sono responsabili dei seguenti elementi:

• Implementazione dell'interfaccia del kernel per sospendere Android.
• Implementare le funzioni VHAL per:
  • Propagare l'avvio della sospensione o dello spegnimento dall'auto ad Android.
  • Invia il messaggio di spegnimento da Android all'auto.
  • Avvia l'arresto o la sospensione di Android tramite l'interfaccia del kernel Linux.
• Assicurati che tutte le sorgenti di attivazione siano disattivate quando il dispositivo è in sospensione.
• Assicurati che le app si arrestino abbastanza rapidamente da non posticipare indefinitamente il processo di arresto.
• Assicurati che il BSP accenda (o disattivi) i componenti del dispositivo in base al criterio di alimentazione in modo da non bloccare la sospensione o l'ibernazione

Interfaccia del kernel: /sys/power/state

AAOS mette un dispositivo in modalità sospensione quando un'app o un servizio scrive mem per la sospensione in 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 in stato di sospensione. Questa funzione può inviare un GPIO al VMCU per notificare al VMCU che il dispositivo si è arrestato completamente. L'integratore è inoltre responsabile della rimozione di eventuali condizioni di gara tra l'invio del messaggio finale da parte di VHAL alla VMCU e il passaggio del sistema in modalità di sospensione o arresto.

Responsabilità di VHAL

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 spegnimento pronto 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 chiusura al VMCU. In genere, le periferiche on-chip come UART, SPI e USB trasmettono il messaggio. Una volta inviato il messaggio, CPMS chiama il comando del kernel per sospendere o arrestare il dispositivo. Prima di farlo, il VHAL o il BSP può attivare/disattivare un GPIO per indicare al VMCU che è possibile rimuovere l'alimentazione dal dispositivo.

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

AP_POWER_STATE_REPORT

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

• int32Values[0]: enum VehicleApPowerStateReport dello stato attuale.
• int32Values[1]: tempo in millisecondi per posticipare, mettere in sospensione 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, che vengono memorizzate in hardware/interfaces/automotive/vehicle/aidl/android/hardware/automotive/vehicle.

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

AP_POWER_STATE_REQ

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

• int32Values[0]: valore dell'enum VehicleApPowerStateReq, che rappresenta il nuovo stato in cui eseguire la transizione.
• int32Values[1]: valore dell'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 passare Android. La semantica è definita in VehicleApPowerStateReq.aidl e fornita di seguito:

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

Origini risveglio

L'integratore deve disattivare le sorgenti di attivazione appropriate quando il dispositivo è in modalità di sospensione. Le sorgenti di attivazione più comuni sono i battiti cardiaci, il modem, il Wi-Fi e il Bluetooth. L'unica sorgente di attivazione valida deve essere un'interruzione del VMCU per riattivare il SoC. Ciò presuppone che il VMCU possa ascoltare il modem per gli eventi di attivazione da remoto (ad esempio l'avvio del motore da remoto). Se questa funzionalità viene inviata all'AP, è necessario aggiungere un'altra sorgente di attivazione per la manutenzione del modem.

App

Gli OEM devono scrivere le app in modo che possano essere arrestate rapidamente e non posticipare la procedura a tempo indeterminato.

Appendice

Directory nella struttura ad albero del codice sorgente

Diagramma di classe

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 tra oggetti

La Figura 5 mostra quali oggetti hanno riferimenti ad altri oggetti. Un bordo 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.