I nuovi servizi di plug-in OEM per auto in Android 14 consentono di configurare alcuni componenti dell'auto. Per l'audio in particolare, 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 del focus audio
- Controllo del volume e della disattivazione audio
- Controllo attenuazione automatica audio
Architettura del servizio di plug-in per auto
La figura seguente fornisce una panoramica dei servizi per auto e del loro rapporto con il servizio per auto OEM. Analogamente ai processi delle app e del servizio auto, il processo del servizio auto OEM occupa il proprio spazio di processo.
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 non viene avviato alcun servizio. Il componente deve estendere
OemCarService.
Il servizio audio dell'auto deve sovrascrivere le API per l'acquisizione del servizio OEM audio dell'auto:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Per
esempio, vedi
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. Pertanto, qualsiasi
autorizzazione richiesta dai servizi OEM deve essere acquisita con il meccanismo
appropriato. Ad esempio, vedi
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 dell'auto gestisce queste 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 insieme 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 dell'auto e il servizio OEM dell'auto. Il servizio audio dell'auto definisce diversi hook che possono chiamare il servizio audio 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 dell'auto utilizza il comportamento predefinito.
Per garantire che il servizio audio dell'auto e il servizio audio OEM dell'auto siano sempre sincronizzati, per ogni chiamata il servizio audio dell'auto passa le parti richieste dello stato attuale dello stack audio al servizio audio OEM dell'auto. Ad esempio, quando il servizio audio dell'auto intercetta una richiesta di valutazione della messa a fuoco dell'audio, passa lo stato attuale dello stack al servizio audio OEM dell'auto. Lo stato attuale include il titolare dello stato attivo corrente e i perdenti dello stato attivo corrente. I perdenti di messa a fuoco sono richieste di messa a fuoco che fanno ancora parte dello stack ma che hanno perso temporaneamente la messa a fuoco.
Il servizio audio per auto deve gestire tutta l'attività audio nell'auto. Se il servizio audio dell'auto non gestisce alcune parti del comportamento audio, le informazioni esposte al servizio audio OEM dell'auto sono incomplete. Ad esempio, se un OEM sovrascrive la gestione della messa a fuoco audio nel servizio auto registrando la propria norma di messa a fuoco audio, il servizio audio dell'auto non può fornire informazioni complete al servizio audio OEM dell'auto. Ciò può influire sulla capacità del servizio audio OEM dell'auto di prendere decisioni, poiché potrebbe non disporre di informazioni non visibili al servizio audio dell'auto.
Per eseguire azioni, il servizio audio dell'auto chiama i servizi auto OEM. Queste chiamate vengono effettuate tra processi, il che richiede la comunicazione tra processi (IPC). IPC aggiunge latenza a ogni chiamata. È importante ridurre al minimo la latenza nel servizio OEM.
Poiché le chiamate al servizio audio dell'auto al servizio OEM sono bloccanti, il servizio OEM non deve chiamare il servizio audio dell'auto nelle valutazioni dirette delle API. Il servizio audio dell'auto fornisce invece le informazioni necessarie in modo che le chiamate tra i due processi debbano viaggiare solo in una direzione.
Definizioni del servizio audio per auto OEM
Servizio di focus audio per autoradio OEM
Il servizio audio per auto gestisce le richieste di focus audio dalle app registrando un listener di focus della policy audio. Il servizio audio per auto ha un meccanismo per gestire il comportamento della messa a fuoco in base a una matrice di interazione statica. La matrice definisce tre diversi tipi di interazioni:
Interazione simultanea. I titolari della messa a fuoco possono mantenere la messa a fuoco contemporaneamente.
Interazioni esclusive. La richiesta di messa a fuoco in arrivo sposta la messa a fuoco dal titolare della messa a fuoco corrente.
Rifiutare l'interazione. Richiesta di messa a fuoco in arrivo rifiutata in base all'attuale titolare della messa a fuoco.
Sebbene sia sufficiente per alcuni casi d'uso automobilistici, non soddisfa tutte le
esigenze di interazione che possono variare a causa dei requisiti OEM. Per questo
introduciamo 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 viene richiesta la messa a fuoco audio che deve essere valutata. Si tratta di un'API bidirezionale che blocca la restituzione dei risultati. La richiesta contiene informazioni
sullo stato attuale dello stack audio:
Queste informazioni possono essere utilizzate per valutare newFocusRequest rispetto ai
titolari attuali del focus in focusHolders e ai perdenti attuali del focus in
focusLosers. L'API dovrebbe 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
concessa, ritardata o non è andata a buon fine. Eventuali modifiche allo stack di messa a fuoco corrente
devono essere impostate nelle voci newLosers e newlyBlocked, a seconda della natura
della modifica dello stack.
Dove newLosers contiene voci che in precedenza avevano lo stato attivo, ma
ora devono perderlo, in modo permanente o temporaneo. I perdenti di focus permanenti
verranno rimossi ulteriormente dallo stack di focus audio, mentre i perdenti di focus temporanei
verranno spostati nello stack dei perdenti di focus attuali finché non riacquistano il focus o non vengono
abbandonati dal richiedente del focus originale. In ogni caso, il listener di messa a fuoco per
le richieste riceverà una perdita di messa a fuoco corrispondente.
L'elenco newlyBlocked contiene voci che in precedenza si trovavano nell'elenco
di perdita del focus, ma ora sono bloccate dalla nuova voce. Il blocco può essere permanente o
temporaneo. Per la messa a fuoco permanente bloccata, la voce verrà rimossa dallo stack
e la perdita della messa a fuoco verrà inviata ai listener della messa a fuoco. Per la perdita temporanea della messa a fuoco,
la voce rimarrà nello stack dei perdenti della messa a fuoco, ma verrà aggiunto un nuovo blocco della messa a fuoco
al suo elenco di blocchi. Non verrà inviata alcuna perdita della messa a fuoco, in quanto è già stata inviata
quando è stata bloccata per la prima volta. La richiesta verrà sbloccata definitivamente quando tutti
i blocchi 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 della messa a fuoco audio. L'API viene utilizzata principalmente per informare il servizio OEM
in merito alle modifiche della messa a fuoco, che potrebbero influire sul comportamento del servizio audio per auto OEM.
Linee guida per la valutazione della messa a fuoco
In AAOS, la messa a fuoco dell'audio viene utilizzata per gestire la riproduzione audio e per determinare quale app deve rispettare per offrire un'esperienza ottimale all'utente. Pertanto, il servizio di plug-in OEM deve tenere conto di quanto segue quando gestisce una richiesta di focus audio:
Senza alcuna app con focus audio ad alta priorità (come una chiamata, un'emergenza o la sicurezza), le app dovrebbero essere in grado di ottenere il focus audio in modo temporaneo o permanente.
Mentre è attivo un focus sui contenuti multimediali, le app che richiedono:
L'utilizzo delle chiamate deve essere in grado di ricevere lo stato attivo contemporaneamente o esclusivamente.
La selezione della navigazione deve essere in grado di ricevere la selezione contemporaneamente o in esclusiva.
L'utilizzo dell'assistente deve essere in primo piano e deve essere possibile metterlo in primo piano in modo concorrente o esclusivo.
Mentre le app con priorità audio elevata (come una chiamata, un avviso di emergenza o un avviso di sicurezza) sono attive, qualsiasi richiesta di priorità audio in arrivo deve essere concessa o ritardata in base alle necessità.
Sebbene i suggerimenti riportati sopra non siano esaustivi, possono contribuire a garantire che le app che richiedono la messa a fuoco possano ottenerla quando non sono presenti suoni attivi ad alta priorità. Anche quando i suoni ad alta priorità sono attivi, le richieste di messa a fuoco ritardata devono comunque essere rispettate e la messa a fuoco deve essere possibile una volta che il suono ad alta priorità si interrompe.
Servizio di volume dell'auto OEM
Il servizio audio dell'auto gestisce gli eventi dei tasti del volume ascoltando le regolazioni del volume dal sistema 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 è quello di 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à del volume. Il primo elenco considera tutti i contesti audio in questo ordine. L'elenco è presentato in ordine decrescente, con la priorità più alta in alto e quella più bassa in basso. Ad esempio, se l'audio di navigazione e l'audio della musica sono attivi contemporaneamente, allora il volume della navigazione viene modificato durante un evento tasto 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 dispone di un elenco di priorità secondarie del contesto audio:
- Chiama
- Media
- Annuncio
- Comando vocale
Questo elenco è presentato anche in ordine decrescente. Lo scopo di questo secondo elenco è consentire la modifica dei suoni più comuni tramite gli eventi chiave. I suoni meno comuni, magari 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 configurazione
audioVolumeAdjustmentContextsVersion. La configurazione può essere
impostata su 1 o 2 (2 è il valore predefinito).
Per offrire una maggiore flessibilità nella gestione del volume,
OemCarAudioVolumeService è stato introdotto in Android 14:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
Il servizio di controllo del volume dell'impianto audio dell'OEM ha un solo 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. duckedAttributes sono tutti attributi audio attualmente ridotti. Il
volumeGroupState contiene lo stato attuale del gruppo di volumi. La richiesta
rappresenta lo stato attuale dello stack audio e può essere utilizzata per determinare
quale gruppo di volumi deve essere modificato. I risultati devono essere restituiti in
OemCarVolumeChangeInfo:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
Il valore booleano change indica se è stato modificato un volume, true indica che
è presente una modifica e il gruppo di volumi deve essere aggiornato. Il
volumeGroupChanged è il gruppo di volumi effettivo da modificare. Questo
gruppo deve essere modificato in base al parametro volumeAdjustment originale
trasmesso all'API. Ad esempio, se i risultati indicano che il gruppo di volumi di navigazione deve essere disattivato, il valore booleano sarà true e il gruppo di volumi restituito sarà quello della navigazione.
Servizio di attenuazione audio per auto OEM
Il servizio audio per auto gestisce l'abbassamento del volume monitorando le modifiche alla messa a fuoco dell'audio e
inviando un segnale all'HAL AudioControl in merito ai dispositivi audio da abbassare.
Quando il focus cambia, tutti i titolari del focus attivi vengono valutati per determinare
quale deve essere nascosto in base a questo insieme di regole
statiche di ducking:
- I suoni di emergenza abbassano il volume di tutto tranne i suoni delle chiamate
- Safety ducks everything except emergency sounds
- La navigazione abbassa il volume di tutto tranne i suoni di sicurezza e di emergenza
- L'anatra chiama tutto tranne i suoni di sicurezza, emergenza e navigazione
- Voice ducks call ring sounds
- La musica e gli annunci devono essere abbassati da tutto
Queste regole non sono esaustive e i produttori di apparecchiature originali rimangono responsabili di determinare
come i suoni devono essere abbassati in base a queste linee guida. Gli OEM possono controllare questi
consigli in modo più attivo in base ai requisiti disponibili. OemCarDuckingService viene introdotto in Android 14:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
Questa API viene chiamata dal servizio audio dell'auto in caso di modifiche alla messa a fuoco audio. Riutilizza
OemCarAudioVolumeRequest introdotto nel
servizio di volume dell'auto OEM e contiene le informazioni
pertinenti per decidere quali attributi nascondere. L'elenco degli
attributi audio da abbassare dall'API viene confrontato con lo stato audio attuale:
Attributo audio attualmente abbassato:
- In elenco, continua a essere nascosto
- Non presente nell'elenco, ducking disattivato
Attributo audio attualmente non abbassato:
- Nella lista, abbassato
- Non presente nell'elenco, ducking disattivato
Il servizio audio per auto determina quindi a quali dispositivi di output audio appartengono gli attributi audio e li aggiunge all'elenco dei dispositivi di output audio con priorità o all'elenco dei dispositivi audio senza priorità, rispettivamente. che viene infine inviato all'HAL AudioControl per eseguire la riduzione del volume richiesta a livello hardware.
La figura seguente mostra un diagramma di sequenza semplificato del controllo di attenuazione automatica audio per una richiesta di selezione quando viene utilizzato il servizio di attenuazione automatica audio OEM:
La sequenza inizia quando un'app richiede
Gestisci messa a fuoco audio
tramite le API di gestione audio pubbliche. La richiesta viene inoltrata al servizio
audio dell'auto per determinare i risultati. Quando viene deciso il focus audio, l'attenuazione automatica 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 abbassare
e infine le informazioni vengono inviate a AudioControl per applicare l'abbassamento
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
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 chiamato evaluateAudioFocusRequest.
Eseguire il debug dell'app di test di riferimento
L'app di test del servizio auto OEM fa parte del codice sorgente AOSP. Gli OEM possono apportare
modifiche in base alle loro 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 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 sul dump mIsOemServiceReady specificano se il
servizio è pronto per essere utilizzato, dove true indica che è pronto e false
indica che non è pronto.