I nuovi servizi plug-in OEM per auto in Android 14 consentono di configurare alcuni componenti dell'auto. In particolare, per l'audio, vengono introdotti tre nuovi servizi di plug-in che consentono agli OEM di configurare in modo flessibile la gestione dell'audio sui dispositivi AAOS:
- Controllo dell'audio in primo piano
- Controllo del volume e della disattivazione audio
- Controllo dell'attenuazione automatica audio
Architettura del servizio di plug-in per auto
La figura seguente fornisce una panoramica dei servizi per auto e della loro relazione con il servizio per auto OEM. Come le procedure relative alle app e ai servizi per auto, la procedura di servizio per auto OEM occupa uno spazio di processo dedicato.
Il servizio auto avvia il servizio auto OEM trovando il componente definito in
config_oemCarService. Se la configurazione è vuota, il servizio OEM non esiste
e nessun servizio viene avviato. Il componente deve estendere
OemCarService.
Il servizio audio per auto deve sovrascrivere le API per l'acquisizione del servizio OEM per l'audio per auto:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Come esempio, consulta l'app di test di riferimento definita in packages/services/Car/tests/OemCarServiceTestApp.
Anche se il servizio viene avviato dal servizio auto, non eredita automaticamente le autorizzazioni disponibili per il servizio audio dell'auto. Di conseguenza, qualsiasi autorizzazione richiesta dai servizi OEM deve essere acquisita con il meccanismo appropriato. Ad esempio, consulta
packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml.
Servizio audio per auto con architettura di servizio OEM
In AAOS, il servizio audio per auto gestisce le seguenti azioni:
- Routing dell'audio
- Focus audio
- Attenuazione automatica audio
- Volume e disattivazione audio
Prima di Android 14, questo comportamento era in gran parte statico e poteva essere modificato solo tramite le impostazioni, anche se per un numero molto limitato di casi. Android 14 ha introdotto un meccanismo per il servizio audio dell'auto per comunicare con un componente definito dall'OEM che gestisce:
- Focus audio
- Attenuazione automatica audio
- Volume e disattivazione audio
La figura seguente mostra un'architettura semplificata per il servizio audio per auto e per il servizio OEM dell'auto. Il servizio audio dell'auto definisce diversi hook che possono chiamare il servizio audio dell'OEM dell'auto per gestire il comportamento audio. Quest'ultimo si verifica solo se è definito il componente del servizio audio per auto OEM corrispondente. In caso contrario, il servizio audio per auto utilizza il comportamento predefinito.
Per garantire che il servizio audio dell'auto e il servizio audio dell'OEM dell'auto siano sempre sincronizzati, per ogni chiamata il servizio audio dell'auto passa le parti richieste dello stato corrente della pila audio al servizio audio dell'OEM dell'auto. Ad esempio, quando il servizio audio dell'auto intercetta una richiesta per valutare l'attenzione audio, passa lo stato corrente dello stack al servizio audio dell'OEM dell'auto. Lo stato attuale include il detentore dell'attenzione corrente e gli utenti che non hanno l'attenzione. Le richieste in perdita di attenzione sono richieste in primo piano che fanno ancora parte della serie, ma che hanno temporaneamente perso il primo piano.
Il servizio audio per auto deve gestire tutte le attività audio nell'auto. Se il servizio audio dell'auto non gestisce alcune parti del comportamento audio, le informazioni esposte al servizio audio dell'OEM dell'auto sono incomplete. Ad esempio, se un OEM sovrascrive la gestione dell'attenzione audio nel servizio per auto registrando le proprie norme sull'attenzione audio, il servizio audio dell'auto non può fornire informazioni complete al servizio audio dell'OEM dell'auto. Ciò può influire sulla capacità del servizio audio OEM dell'auto di prendere decisioni, poiché potrebbero mancare informazioni non visibili al servizio audio dell'auto.
Per eseguire azioni, il servizio audio per auto chiama i servizi per auto OEM. Queste chiamate vengono eseguite tra processi, il che richiede la comunicazione tra processi (IPC). L'IPC aggiunge latenza a ogni chiamata. È importante ridurre al minimo la latenza nel servizio OEM.
Poiché le chiamate del servizio audio per auto al servizio OEM sono bloccanti, il servizio OEM non deve chiamare il servizio audio per auto nelle valutazioni dirette dell'API. Il servizio audio per auto fornisce invece le informazioni necessarie in modo che le chiamate tra i due processi debbano essere inviate in una sola direzione.
Definizioni dei servizi audio per auto OEM
Servizio di attivazione audio in auto OEM
Il servizio audio per auto gestisce le richieste di attenzione audio dalle app registrando un ascoltatore di attenzione ai criteri audio. Il servizio audio per auto ha un meccanismo per gestire il comportamento di messa a fuoco in base a una matrice di interazione statica. La matrice definisce tre diversi tipi di interazioni:
Interazione simultanea. I titolari dell'attenzione possono mantenere l'attenzione contemporaneamente.
Interazioni esclusive. La richiesta di messa a fuoco in arrivo acquisisce il fuoco dall'attuale detentore del fuoco.
Rifiutare l'interazione. Richiesta di attenzione in arrivo rifiutata in base all'attuale detentore dell'attenzione.
Sebbene sia sufficiente per alcuni casi d'uso nel settore auto e motori, non soddisfa tutte le esigenze di interazione che possono variare a causa dei requisiti degli OEM. Per questo, abbiamo introdotto OemCarAudioFocusService:
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
L'API evaluateAudioFocusRequest viene chiamata dal servizio audio dell'auto ogni volta che c'è una richiesta di attenzione audio da valutare. Si tratta di un'API bidirezionale che si blocca fino al ritorno dei risultati. La richiesta contiene informazioni sullo stato corrente della pila audio:
Queste informazioni possono essere utilizzate per valutare il newFocusRequest rispetto ai detentori attuali dell'attenzione in focusHolders e ai perdenti attuali dell'attenzione in focusLosers. L'API deve restituire i risultati:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
Contiene le informazioni sui risultati effettivi della valutazione in
audioFocusEvaluationResults, che indica se la richiesta corrente è stata
accettata, ritardata o non è andata a buon fine. Eventuali modifiche all'attuale serie di elementi in primo piano devono essere impostate nelle voci newLosers e newlyBlocked, a seconda della natura della modifica della serie.
Dove newLosers contiene voci che in precedenza erano attive, ma che ora devono perdere lo stato attivo, in modo permanente o temporaneo. I componenti che perdono lo stato attivo permanente
verranno rimossi ulteriormente dalla pila di stato attivo audio e quelli che perdono lo stato attivo transitorio
verranno spostati nella pila di stato attivo corrente finché non recupereranno lo stato attivo o non verranno abbandonati dall'autore della richiesta di stato attivo originale. In ogni caso, l'ascoltatore del focus per le richieste riceverà un corrispondente evento di perdita del focus.
L'elenco newlyBlocked contiene voci che in precedenza erano nell'elenco dei perdenti
in primo piano, ma che ora sono bloccate dalla nuova voce. Il blocco può essere permanente o transitorio. Per il blocco permanente dell'attenzione, la voce verrà rimossa dall'elenco e la perdita dell'attenzione verrà inviata agli ascoltatori dell'attenzione. Per la perdita di attenzione transitoria, la voce rimarrà nello stack dei perdenti di attenzione, ma verrà aggiunto un nuovo blocco di attenzione al relativo elenco di blocchi. Non verrà inviata alcuna perdita di attenzione, come è stato fatto in precedenza quando è stato bloccato per la prima volta. La richiesta verrà infine sbloccata quando tutti i bloccanti attuali verranno rimossi oppure verrà rimossa dallo stack se l'attenzione viene abbandonata.
La seconda API, notifyAudioFocusChange, è unidirezionale e viene chiamata a ogni richiesta o abbandono dell'audio focus. L'API viene utilizzata principalmente per informare il servizio OEM sulle modifiche dell'attenzione, che potrebbero influire sul comportamento del servizio audio per auto OEM.
Linee guida per la valutazione dell'attenzione
In AAOS, l'audio focus viene utilizzato per gestire la riproduzione audio e per determinare quale app deve aderire per offrire un'esperienza ottimale all'utente. Di conseguenza, il servizio del plug-in OEM deve tenere conto di quanto segue durante la gestione di una richiesta di attenzione audio:
In assenza di un'attenzione audio di alta priorità (ad esempio una telefonata, un'emergenza o la sicurezza), le app dovrebbero essere in grado di acquisire l'attenzione audio transitoriamente o definitivamente.
Quando è attivo un'opzione di messa a fuoco multimediale, le app che richiedono:
L'attenzione all'utilizzo delle chiamate deve essere in grado di ricevere l'attenzione contemporaneamente o esclusivamente.
La selezione per l'utilizzo della navigazione deve essere in grado di ricevere la selezione contemporaneamente o esclusivamente.
L'assistente deve essere in grado di ricevere l'attenzione contemporaneamente o esclusivamente.
Quando sono attive app con audio in primo piano con priorità elevata (ad esempio una telefonata, un avviso di emergenza o di sicurezza), qualsiasi richiesta di audio in primo piano in ritardo in arrivo deve essere concessa o ritardata in base alle esigenze.
Sebbene i suggerimenti riportati sopra non siano esaustivi, possono contribuire a garantire che le app che richiedono l'attenzione debbano essere in grado di ottenerla quando non sono attivi suoni di alta priorità. Anche quando sono attivi suoni con priorità elevata, le richieste di messa a fuoco ritardata devono essere rispettate e devono essere in grado di acquisire il focus una volta interrotto il suono con priorità elevata.
Servizio di controllo del volume dell'auto OEM
Il servizio audio dell'auto gestisce gli eventi dei tasti del volume ascoltando le regolazioni del volume dall'impianto audio o ascoltando gli eventi dei tasti del volume direttamente dal servizio di input dell'auto. In ogni caso, il comportamento predefinito del servizio audio dell'auto è determinare quale gruppo di volume modificare in base ai lettori audio attivi e a un elenco di priorità del contesto audio.
Forniamo due elenchi di priorità in base al volume. Il primo elenco prende in considerazione tutti i contesti audio in questo ordine. L'elenco è presentato in ordine decrescente, con la priorità più alta in alto e la priorità più bassa in basso. Ad esempio, se l'audio di navigazione e l'audio della musica sono entrambi attivi contemporaneamente, il volume di navigazione viene modificato durante un evento chiave del volume.
- Navigazione
- Chiama
- Musica
- Annuncio
- Comando vocale
- Suoneria
- Audio sistema
- Sicurezza
- Sveglia
- Notifica
- Stato del veicolo
- Emergenza
Per semplificare la gestione degli eventi chiave del volume, il servizio audio per auto ha un secondo elenco di priorità del contesto audio:
- Chiama
- Contenuti multimediali
- Annuncio
- Comando vocale
Anche questo elenco è presentato in ordine decrescente. Lo scopo di questo secondo elenco è consentire di modificare i suoni più comuni tramite gli eventi chiave. I suoni insoliti, forse di durata più breve, possono essere gestiti solo tramite l'interfaccia utente delle impostazioni audio.
La versione effettiva del volume può essere impostata con la configurazioneaudioVolumeAdjustmentContextsVersion. La configurazione può essere impostata su 1 o 2 (2 è il valore predefinito).
Per offrire maggiore flessibilità alla gestione del volume,
OemCarAudioVolumeService viene introdotto in Android 14:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
Il servizio di regolazione del volume dell'impianto audio dell'auto OEM ha un unico metodo che accetta un volumeAdjustment e un OemCarAudioVolumeRequest:
class OemCarAudioVolumeRequest {
int audioZoneId;
int callState;
List<AudioAttributes> activePlaybackAttributes;
List<AudioAttributes> duckedAttributes;
List<CarVolumeGroupInfo> volumeGroupState;
}
activePlaybackAttributes della richiesta contiene gli attributi audio attivi. Gli attributi
duckedAttributes sono tutti gli attributi audio attualmente attenuati. volumeGroupState contiene lo stato attuale del gruppo di volumi. La richiesta rappresenta lo stato corrente della pila audio e può essere utilizzata per determinare quale gruppo di volume deve essere modificato. I risultati dovrebbero essere restituiti in
OemCarVolumeChangeInfo:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
Il valore booleano change indica se è stato modificato un volume, true indica che c'è una modifica e che il gruppo di volumi deve essere aggiornato. volumeGroupChanged è il gruppo di volume effettivo che deve essere modificato. Questo
gruppo deve essere modificato in base al parametro volumeAdjustment originale
trasmesso all'API. Ad esempio, se i risultati indicano che il gruppo di volume di navigazione deve essere disattivato, il valore booleano sarà true e il gruppo di volume restituito deve essere quello per la navigazione.
Servizio di attenuazione audio per auto OEM
Il servizio audio per auto gestisce il ducking audio monitorando le modifiche dell'attenzione audio e inviando un segnale all'HAL AudioControl sui dispositivi audio da attenuare.
Quando lo stato attivo cambia, tutti i relativi detentori vengono valutati per determinare quale deve essere nascosto in base a questo insieme di regole di ducking statico:
- I suoni di emergenza riducono il volume di tutti i suoni tranne quelli delle chiamate
- La modalità Sicurezza disattiva tutto tranne i suoni di emergenza
- La navigazione riduce tutto tranne i suoni di sicurezza ed emergenza
- La funzionalità Anatra per le chiamate disattiva tutti i suoni tranne quelli di sicurezza, emergenza e navigazione
- Voce anatra suoni di suoneria delle chiamate
- La musica e gli annunci devono essere attenuati da tutto
Queste regole non sono esaustive e gli OEM rimangono responsabili di determinare come devono essere attenuati i suoni in base a queste linee guida. Gli OEM possono controllare questi consigli in modo più attivo in base ai requisiti disponibili. OemCarDuckingService è stato introdotto in Android 14:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
Questa API viene chiamata dal servizio audio dell'auto in caso di modifiche dell'attenzione audio. Riutilizza
OemCarAudioVolumeRequest introdotto nel
servizio di volume delle auto OEM e contiene le informazioni pertinenti per decidere quali attributi ignorare. L'elenco degli attributi audio da attenuare dall'API viene confrontato con lo stato audio corrente:
Attributo audio attualmente attenuato:
- Nell'elenco, continua a essere ignorato
- Non presente nell'elenco, riduzione del volume disattivata
Attributo audio non attualmente attenuato:
- Nell'elenco, abbassato
- Non presente nell'elenco, riduzione del volume disattivata
Il servizio audio per auto determina quindi a quali dispositivi di output audio appartengono gli attributi audio e li aggiunge rispettivamente all'elenco dei dispositivi di output audio con audio attenuato o all'elenco dei dispositivi audio con audio non attenuato. che viene inviata all'AudioControl HAL per eseguire il ducking richiesto a livello hardware.
La figura seguente mostra un diagramma di sequenza semplificato del controllo della riduzione audio per una richiesta di messa a fuoco quando viene utilizzato il servizio di riduzione audio OEM:
La sequenza inizia quando un'app richiede
Gestisci l'attenzione audio
tramite le API di gestione audio pubbliche. La richiesta viene inoltrata al servizio audio dell'auto per determinare i risultati. Una volta deciso il punto di attenzione audio, l'attenuazione audio viene valutata dal servizio audio dell'auto che chiama OemCarAudioDuckingService per valutare quali attributi audio devono essere attenuati. Una volta restituiti i risultati dall'API evaluateAttributesToDuck, vengono calcolati i dispositivi audio da attenuare e infine le informazioni vengono inviate a AudioControl per applicare l'attenuazione all'hardware audio.
Implementazione di riferimento del servizio audio per auto OEM
AAOS fornisce un'implementazione di riferimento del servizio auto OEM in
packages/services/Car/tests/OemCarServiceTestApp, che implementa il
OemCarService, insieme a OemCarAudioFocusService,
OemCarAudioDuckingService e OemCarAudioVolumeService. Per quest'ultimo, ogni servizio utilizza un file XML per caricare un comportamento statico. Ad esempio,
OemCarAudioFocusServiceImp carica oem_focus_config.xml, che
contiene una matrice di interazione. La matrice viene utilizzata per valutare la richiesta di messa a fuoco
quando viene chiamata evaluateAudioFocusRequest.
Riferimento al debug dell'app di test
L'app di test del servizio auto OEM fa parte del codice sorgente AOSP. Gli OEM possono apportare modifiche in base alle proprie esigenze. Per il debug, utilizza la configurazione config_oemCarService
per attivare l'app di test.
<!-- This is the component name for the OEM customization service. OEM can choose to implement
this service to customize car service behavior for different policies. If OEMs choose to
implement it, they have to implement a service extending OemCarService exposed by car-lib,
and implement the required component services.
If the component name is invalid, CarService would not connect to any OEM service.
Component name can not be a third party package. It should be pre-installed -->
<string name="config_oemCarService" translatable="false">
com.android.car.oemcarservice.testapp/.OemCarServiceImpl
</string>
Per verificare che il servizio auto OEM utilizzi il comando dump del servizio auto per il servizio OEM:
adb shell dumpsys car_service --oem-service
I risultati potrebbero essere simili all'output riportato di seguito:
***CarOemProxyService dump***
mIsFeatureEnabled: true
mIsOemServiceBound: true
mIsOemServiceReady: true
mIsOemServiceConnected: true
mInitComplete: true
OEM_CAR_SERVICE_CONNECTED_TIMEOUT_MS: 5000
OEM_CAR_SERVICE_READY_TIMEOUT_MS: 5000
mComponentName: com.android.car.oemcarservice.testapp/.OemCarServiceImpl
Ogni valore booleano in ogni batch di informazioni dump determina lo stato della funzionalità
e del servizio. Ad esempio, le informazioni del dump mIsOemServiceReady specificano se il servizio è pronto per essere utilizzato, dove true indica che è pronto e false indica che non è pronto.