I nuovi servizi plug-in OEM per auto in Android 14 consentono la configurazione di alcuni componenti dell'auto. Per l'audio in particolare, vengono introdotti tre nuovi servizi plug-in, che consentono agli OEM di configurare in modo flessibile la gestione dell'audio sui dispositivi AAOS:
- Controllo della messa a fuoco dell'audio
- Controllo del volume audio e del muto
- Controllo dell'audio ducking
Architettura del servizio plug-in per auto
La figura seguente fornisce una panoramica dei servizi per auto e la loro relazione con il servizio per auto OEM. Analogamente ai processi dell'app e al processo di servizio auto, il processo di 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 per auto deve sovrascrivere le API per acquisire il servizio OEM audio per auto:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Ad esempio , vedere 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 auto. Pertanto, qualsiasi autorizzazione richiesta dai servizi OEM deve essere acquisita con il meccanismo appropriato. Ad esempio, vedere 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:
- Instradamento dell'audio
- Messa a fuoco audio
- Ducking dell'audio
- Volume e muto
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 che consente al servizio audio dell'auto di comunicare con un componente definito dall'OEM che gestisce:
- Messa a fuoco audio
- Ducking dell'audio
- Volume e muto
La figura seguente mostra un'architettura semplificata per il servizio audio per auto e il servizio OEM per auto. Il servizio audio dell'auto definisce diversi hook che possono richiamare il servizio audio OEM dell'auto per gestire il comportamento audio. Quest'ultimo si verifica solo se è definito il corrispondente componente del servizio audio per auto OEM. Altrimenti, il servizio audio dell'auto utilizzerà 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 trasmette le parti richieste dello stato corrente dello stack audio al servizio audio OEM dell'auto. Ad esempio, quando il servizio audio dell'auto intercetta una richiesta per valutare il focus audio, passa lo stato corrente dello stack al servizio audio OEM dell'auto. Lo stato attuale include l'attuale detentore del focus e gli attuali perdenti del focus. I perdenti del focus sono richieste di focus che fanno ancora parte dello stack ma che hanno temporaneamente perso il focus.
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 saranno incomplete. Ad esempio, se un OEM sovrascrive la gestione del focus audio nel servizio automobilistico registrando la propria policy di focus audio, il servizio audio dell'auto non sarà in grado di fornire informazioni complete al servizio audio 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 intraprendere azioni, il servizio audio dell'auto chiama i servizi dell'auto OEM. Queste chiamate vengono effettuate tra processi, il che richiede la comunicazione tra processi (IPC). L'IPC aggiunge latenza a ciascuna 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 dovrebbe chiamare il servizio audio per auto in base alle valutazioni API dirette. Il servizio car audio fornisce invece le informazioni necessarie affinché le chiamate tra i due processi debbano viaggiare solo in una direzione.
Definizioni del servizio audio per auto OEM
Servizio di messa a fuoco audio per auto OEM
Il servizio audio per auto gestisce le richieste di focus audio dalle app registrando un listener di focus sui criteri audio. Il servizio car audio dispone di un meccanismo per gestire il comportamento di messa a fuoco basato su una matrice di interazione statica. La matrice definisce tre diversi tipi di interazioni:
Interazione simultanea. I detentori del focus possono mantenere la concentrazione allo stesso tempo.
Interazioni esclusive. La richiesta di focus in entrata prende il focus dal detentore del focus attuale.
Rifiuta l'interazione. Richiesta di focus in entrata respinta in base all'attuale detentore del focus.
Sebbene ciò sia sufficiente per alcuni casi di utilizzo automobilistico, non soddisfa tutte le esigenze di interazione che potrebbero differire a causa dei requisiti OEM. Per questo presentiamo OemCarAudioFocusService :
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
L'API evaluateAudioFocusRequest viene richiamata dal servizio audio dell'auto ogni volta che c'è una richiesta di focus audio che deve essere valutata. Si tratta di un'API bidirezionale che blocca la restituzione dei risultati. La richiesta contiene informazioni sullo stato corrente dello stack audio:
Queste informazioni possono essere utilizzate per valutare newFocusRequest rispetto agli attuali detentori del focus in focusHolders e agli attuali perdenti 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 è riuscita. Qualsiasi modifica allo stack di focus corrente dovrebbe essere impostata nelle voci newLosers e newlyBlocked , a seconda della natura della modifica dello stack.
Dove newLosers contiene voci che in precedenza erano attive ma che ora dovrebbero perderlo, in modo permanente o temporaneo. Le persone perdenti con focus permanente verranno ulteriormente rimosse dallo stack di focus audio, mentre le persone perdenti con focus temporaneo verranno spostate nell'attuale stack di focus perdenti fino a quando non riacquisteranno il focus o verranno abbandonate dal richiedente del focus originale. Indipendentemente da ciò, l'ascoltatore del focus per le richieste riceverà un focus perso corrispondente.
L'elenco newlyBlocked contiene voci che in precedenza erano nell'elenco dei perdenti del focus ma che ora sono bloccate dalla nuova voce. Il blocco può essere permanente o transitorio, per il focus permanente bloccato la voce verrà rimossa dallo stack e la perdita del focus verrà inviata agli ascoltatori con focus. Per la perdita temporanea del focus, la voce rimarrà nello stack dei focus perdenti ma un nuovo blocco del focus verrà aggiunto al suo elenco di bloccanti, nessuna perdita del focus verrà inviata poiché ne era stata inviata una in precedenza quando è stata bloccata per la prima volta. La richiesta verrà finalmente sbloccata quando tutti gli attuali bloccanti verranno rimossi, oppure verrà rimossa dallo stack se il focus viene abbandonato.
La seconda API, notifyAudioFocusChange , è unidirezionale che viene richiamata a ogni richiesta o abbandono del focus audio. L'API viene utilizzata principalmente per informare il servizio OEM sui cambiamenti di focus, che potrebbero influenzare il comportamento del servizio audio per auto OEM.
Linee guida per la valutazione del focus
In AAOS, la messa a fuoco audio viene utilizzata per gestire la riproduzione audio e determinare quale app deve aderire per fornire un'esperienza ottimale all'utente. Pertanto, il servizio plug-in OEM dovrebbe tenere conto di quanto segue durante la gestione di una richiesta di focus audio:
Senza alcuna messa a fuoco audio ad alta priorità (come una telefonata, un'emergenza o una sicurezza), le app dovrebbero essere in grado di ottenere la messa a fuoco audio in modo transitorio o permanente.
Mentre è attivo un focus multimediale, le app che richiedono:
Il focus sull'utilizzo delle chiamate dovrebbe essere in grado di ricevere il focus contemporaneamente o esclusivamente.
Il focus sull'utilizzo della navigazione dovrebbe essere in grado di ricevere il focus contemporaneamente o esclusivamente.
Il focus sull'utilizzo dell'assistente dovrebbe essere in grado di ricevere il focus contemporaneamente o esclusivamente.
Mentre sono attive le app di focus audio ad alta priorità (ad esempio una telefonata, un avviso di emergenza o un avviso di sicurezza), qualsiasi richiesta di focus audio ritardato in arrivo deve essere concessa o ritardata secondo necessità.
Anche se i suggerimenti sopra riportati non sono esaustivi, possono contribuire a garantire che le app che richiedono il focus siano in grado di ottenerlo quando non sono presenti suoni attivi ad alta priorità. Anche quando i suoni ad alta priorità sono attivi, le richieste di focalizzazione ritardata dovrebbero comunque essere rispettate e dovrebbero essere in grado di ottenere la messa a fuoco una volta che il suono ad alta priorità cessa.
Servizio volume 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 consiste nel 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à dei volumi. 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 con priorità più bassa in basso. Ad esempio, se l'audio della navigazione e l'audio della musica sono attivi contemporaneamente, il volume della navigazione verrà modificato durante un evento relativo ai tasti del volume.
- Navigazione
- Chiamata
- Musica
- Annuncio
- Comando vocale
- Squillo di chiamata
- Suono del sistema
- Sicurezza
- Allarme
- Notifica
- Stato del veicolo
- Emergenza
Per rendere meno complessa la gestione degli eventi relativi ai tasti volume, il servizio car audio prevede una seconda lista di priorità di contesto audio:
- Chiamata
- Media
- Annuncio
- Comando vocale
Anche questo elenco è presentato in ordine decrescente. Lo scopo di questo secondo elenco è quello di consentire la modifica dei suoni più comuni tramite eventi chiave. I suoni non comuni, 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 configurazione audioVolumeAdjustmentContextsVersion . La configurazione può essere impostata su 1 o 2 ( 2 è l'impostazione predefinita).
Per fornire maggiore flessibilità alla gestione del volume, OemCarAudioVolumeService viene introdotto in Android 14:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
Il servizio volume audio per auto OEM ha un unico metodo, che comprende un volumeAdjustment e un OemCarAudioVolumeRequest :
class OemCarAudioVolumeRequest {
int audioZoneId;
int callState;
List<AudioAttributes> activePlaybackAttributes;
List<AudioAttributes> duckedAttributes;
List<CarVolumeGroupInfo> volumeGroupState;
}
Il activePlaybackAttributes della richiesta ha gli attributi audio attivi. Gli duckedAttributes sono tutti gli attributi audio attualmente ducked. volumeGroupState ha lo stato corrente del gruppo di volumi. La richiesta rappresenta lo stato corrente dello stack audio e può essere utilizzata per determinare quale gruppo di volumi deve essere modificato. I risultati dovrebbero essere restituiti in OemCarVolumeChangeInfo :
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
Il valore booleano change indica se qualche volume è cambiato, true indica che c'è una modifica e il gruppo di volumi deve essere aggiornato. volumeGroupChanged è il gruppo di volumi effettivo che dovrebbe essere modificato. Questo gruppo deve essere modificato in base al parametro volumeAdjustment originale passato 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 dovrebbe essere quello per la navigazione.
Servizio di ducking per auto OEM
Il servizio audio per auto gestisce il ducking dell'audio monitorando le modifiche del focus audio e inviando un segnale all'HAL AudioControl su quali dispositivi audio eseguire il ducking. Quando il focus cambia, tutti i detentori del focus attivo vengono valutati per determinare chi dovrebbe essere abbassato in base a questo insieme di regole di ducking statiche:
- I suoni di emergenza attenuano tutto tranne i suoni delle chiamate
- La sicurezza evita tutto tranne i suoni di emergenza
- La navigazione evita tutto tranne la sicurezza e i suoni di emergenza
- Call Duck elimina tutto tranne i suoni di sicurezza, emergenza e navigazione
- Le anatre vocali chiamano i suoni della suoneria
- La musica e gli annunci dovrebbero essere evitati da tutto
Queste regole non sono esaustive e gli OEM rimangono responsabili di determinare come ridurre i suoni in base a queste linee guida. Gli OEM possono controllare queste raccomandazioni in modo più attivo in base ai requisiti disponibili. L' OemCarDuckingService viene introdotto in Android 14:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
Questa API viene richiamata dal servizio audio dell'auto in caso di modifiche al focus audio. Riutilizza l' OemCarAudioVolumeRequest introdotto nel servizio di volume dell'auto OEM e contiene le informazioni rilevanti per prendere una decisione su quali attributi eliminare. L'elenco degli attributi audio da sottrarre all'API viene confrontato con lo stato audio corrente:
Attributo audio attualmente abbassato:
- Nell'elenco, continua a essere schivato
- Non nell'elenco, ducking disattivato
Attributo audio attualmente non abbassato:
- Sulla lista, abbassato
- Non nell'elenco, ducking disattivato
Il servizio audio dell'auto determina quindi a quali dispositivi di uscita audio appartengono gli attributi audio e li aggiunge rispettivamente all'elenco dei dispositivi di uscita audio attenuati o all'elenco dei dispositivi audio non attenuati. Questo viene infine inviato all'HAL AudioControl per eseguire il ducking richiesto a livello hardware.
La figura seguente mostra un diagramma di sequenza semplificato del controllo del ducking audio per una richiesta di focus quando viene utilizzato il servizio ducking OEM:
La sequenza inizia quando un'app richiede Gestisci focus audio tramite API di gestione audio pubbliche. La richiesta viene inoltrata al servizio audio dell'auto per determinare i risultati. Una volta decisa la messa a fuoco dell'audio, il ducking dell'audio viene valutato dal servizio audio dell'auto che chiama OemCarAudioDuckingService per valutare quali attributi audio dovrebbero essere attenuati. Una volta restituiti i risultati evaluateAttributesToDuck , vengono calcolati i dispositivi audio da ducking e infine le informazioni vengono inviate ad AudioControl per applicare il ducking 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, ciascun 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 focus quando viene richiamato il evaluateAudioFocusRequest .
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, utilizzare la configurazione config_oemCarService per abilitare 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 seguente:
***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.