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 dell'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 policy 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 per le 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 messa a fuoco dell'audio dalle app registrando un listener di messa a fuoco 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 del focus possono mantenere la concentrazione contemporaneamente.
Interazioni esclusive. La richiesta di messa a fuoco in arrivo sottrae la messa a fuoco al titolare attuale.
Rifiutare l'interazione. Richiesta di messa a fuoco in arrivo rifiutata in base all'attuale proprietario 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 dell'attenzione attuali in focusHolders e ai perdenti dell'attenzione attuali 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 permanenti del focus
verranno rimossi ulteriormente dallo stack del focus audio, mentre i perdenti temporanei del focus
verranno spostati nello stack dei perdenti attuali del focus finché non riacquistano il focus o non vengono
abbandonati dal richiedente originale del focus. 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 di 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 una volta quando è stata bloccata per la prima volta. La richiesta verrà finalmente sbloccata 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 a quale app deve essere assegnata la priorità 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 priorità elevata permanente per l'audio (ad esempio una chiamata, un'emergenza o la sicurezza), le app devono essere in grado di ottenere l'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 in modo concorrente o esclusivo.
L'utilizzo dell'assistente deve essere in grado di ricevere lo stato attivo in modo simultaneo 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 in primo piano 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 devono poter essere messe a fuoco 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 entrambi attivi contemporaneamente, allora il volume di 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 dell'auto ha un secondo elenco di priorità del contesto audio:
- Chiama
- Contenuti multimediali
- 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 è l'impostazione predefinita).
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'autoradio 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. 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. 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 deve essere 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 di
occultamento statico:
- I suoni di emergenza abbassano il volume di tutto tranne i suoni delle chiamate
- Safety ducks everything except emergency sounds
- La navigazione disattiva tutto tranne i suoni di sicurezza e di emergenza
- L'anatra chiama tutto tranne i suoni di sicurezza, emergenza e navigazione
- Voice abbassa il volume della suoneria
- La musica e gli annunci devono essere abbassati da tutto
Queste regole non sono esaustive e gli OEM rimangono responsabili di determinare
come i suoni devono essere attenuati in base a queste linee guida. Gli OEM possono controllare questi
consigli in modo più attivo in base ai requisiti disponibili. Il
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 alla messa a fuoco audio. Riutilizza
OemCarAudioVolumeRequest introdotto in
OEM car volume service 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 lista, continua a essere oscurato
- 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 rispettivamente all'elenco dei dispositivi di output audio con priorità ridotta o all'elenco dei dispositivi audio senza priorità ridotta. 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 audio ducking per una richiesta di messa a fuoco quando viene utilizzato il servizio ducking OEM:
La sequenza inizia quando un'app richiede
Gestisci messa a fuoco audio
tramite le API Audio Manager pubbliche. La richiesta viene inoltrata al servizio
audio dell'auto per determinare i risultati. Quando viene deciso l'audio focus, l'abbassamento dell'audio
viene valutato dal servizio audio dell'auto che chiama OemCarAudioDuckingService per
valutare quali attributi audio devono essere abbassati. 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.
Esecuzione del 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.