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 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. Analogamente ai processi dell'app e del servizio per auto, il processo del servizio per auto OEM occupa il proprio spazio di processo.
Il servizio per auto avvia il servizio per 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 audio per auto OEM:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Ad
esempio, consulta
l'app di test di riferimento definita in
packages/services/Car/tests/OemCarServiceTestApp.
Anche se il servizio viene avviato dal servizio per auto, non eredita automaticamente le autorizzazioni disponibili per il servizio audio per auto. Pertanto, 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.
Architettura del servizio audio per auto con servizio OEM
In AAOS, il servizio audio per 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 per 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 il servizio OEM per auto. Il servizio audio per auto definisce diversi hook che possono chiamare il servizio audio OEM per 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 per auto e il servizio audio OEM per auto siano sempre sincronizzati, per ogni chiamata il servizio audio per auto passa le parti richieste dello stato attuale dello stack audio al servizio audio OEM per auto. Ad esempio, quando il servizio audio per auto intercetta una richiesta di valutazione del focus audio, passa lo stato attuale dello stack al servizio audio OEM per auto. Lo stato attuale include il titolare del focus attuale e i perdenti del focus attuali. I perdenti del focus sono richieste di focus che fanno ancora parte dello stack, ma che hanno perso temporaneamente il focus.
Il servizio audio per auto deve gestire tutte le attività audio nell'auto. Se il servizio audio per auto non gestisce alcune parti del comportamento audio, le informazioni esposte al servizio audio OEM per auto sono incomplete. Ad esempio, se un OEM sovrascrive la gestione del focus audio nel servizio per auto registrando la propria policy del focus audio, il servizio audio per auto non può fornire informazioni complete al servizio audio OEM per auto. Ciò può influire sulla capacità del servizio audio OEM per auto di prendere decisioni, in quanto potrebbe mancare di informazioni non visibili al servizio audio per auto.
Per eseguire azioni, il servizio audio per auto chiama i servizi per auto OEM. Queste chiamate vengono effettuate tra i 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 per le valutazioni dirette delle API. Il servizio audio per 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 auto OEM
Il servizio audio per auto gestisce le richieste di focus audio dalle app registrando un listener del focus della policy audio. Il servizio audio per auto dispone di un meccanismo per gestire il comportamento del focus in base a una matrice di interazione statica . La matrice definisce tre tipi diversi di interazioni:
Interazione simultanea. I titolari del focus possono mantenere il focus contemporaneamente.
Interazioni esclusive. La richiesta di focus in entrata prende il focus dal titolare del focus attuale.
Rifiuta l'interazione. La richiesta di focus in entrata viene rifiutata in base al titolare del focus attuale.
Sebbene ciò 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 motivo, 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 per auto ogni volta che è presente 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 attuale dello stack audio:
Queste informazioni possono essere utilizzate per valutare la newFocusRequest rispetto ai titolari del focus attuali in focusHolders e ai perdenti del focus attuali in focusLosers. L'API deve restituire i risultati:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
Queste informazioni contengono i risultati della valutazione effettivi in audioFocusEvaluationResults, che indica se la richiesta attuale è stata concessa, ritardata o non è riuscita. Eventuali modifiche allo stack del focus attuale devono essere impostate nelle voci newLosers e newlyBlocked, a seconda della natura della modifica dello stack.
Dove newLosers contiene le voci che in precedenza avevano il focus, ma ora dovrebbero perderlo, in modo permanente o temporaneo. I perdenti del focus permanenti verranno rimossi ulteriormente dallo stack del focus audio, mentre i perdenti del focus temporanei verranno spostati nello stack dei perdenti del focus attuali finché non riacquistano il focus o non vengono abbandonati dal richiedente del focus originale. In ogni caso, il listener del focus per le richieste riceverà una perdita di focus corrispondente.
L'elenco newlyBlocked contiene le voci che in precedenza erano nell'elenco dei perdenti del focus, ma ora sono bloccate dalla nuova voce. Il blocco può essere permanente o temporaneo. Per il focus permanente bloccato, la voce verrà rimossa dallo stack e la perdita di focus verrà inviata ai listener del focus. Per la perdita di focus temporanea, la voce rimarrà nello stack dei perdenti del focus, ma verrà aggiunto un nuovo blocco del focus all'elenco dei blocchi. Non verrà inviata alcuna perdita di focus perché ne è stata inviata una in precedenza quando è stata bloccata per la prima volta. La richiesta verrà infine sbloccata quando tutti i blocchi attuali verranno rimossi oppure verrà rimossa dallo stack se il focus viene abbandonato.
La seconda API, notifyAudioFocusChange, è unidirezionale e viene chiamata per ogni richiesta di focus audio o abbandono. L'API viene utilizzata principalmente per informare il servizio OEM delle modifiche del focus, che potrebbero influire sul comportamento del servizio audio per auto OEM.
Linee guida per la valutazione del focus
In AAOS, il focus audio viene utilizzato per gestire la riproduzione audio e per determinare a quale app deve essere conforme per fornire 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 alcun focus audio con priorità elevata (ad esempio 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:
Il focus sull'utilizzo delle chiamate dovrebbe essere in grado di ricevere il focus in modo simultaneo o esclusivo.
Il focus sull'utilizzo della navigazione dovrebbe essere in grado di ricevere il focus in modo simultaneo o esclusivo.
Il focus sull'utilizzo dell'assistente dovrebbe essere in grado di ricevere il focus in modo simultaneo o esclusivo.
Mentre le app con focus audio con priorità elevata (ad esempio una chiamata, un avviso di emergenza o un avviso di sicurezza) sono attive, qualsiasi richiesta di focus audio ritardata in entrata 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 il focus possano ottenerlo quando non sono presenti suoni con priorità elevata attivi. Anche quando i suoni con priorità elevata sono attivi, le richieste di focus ritardate devono comunque essere rispettate e devono essere in grado di ottenere il focus una volta che il suono con priorità elevata si interrompe.
Servizio volume per auto OEM
Il servizio audio per 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 per auto. In ogni caso, il comportamento predefinito del servizio audio per auto consiste nel determinare quale gruppo di volumi modificare in base ai player 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 la priorità più bassa in basso. Ad esempio, se l'audio di navigazione e l'audio musicale sono entrambi attivi contemporaneamente, il volume di navigazione viene modificato durante un evento dei tasti del volume.
- Navigazione
- Chiama
- Musica
- Annuncio
- Comando vocale
- Suoneria
- Audio sistema
- Sicurezza
- Sveglia
- Notifica
- Stato del veicolo
- Emergenza
Per semplificare la gestione degli eventi dei tasti del volume, il servizio audio per auto dispone di un secondo elenco di priorità del contesto audio:
- Chiama
- Media
- Annuncio
- Comando vocale
Anche questo elenco è presentato in ordine decrescente. Lo scopo di questo secondo elenco è consentire la modifica dei suoni più comuni tramite gli eventi dei tasti. I suoni non comuni, magari di durata inferiore, possono essere gestiti solo tramite l'UI 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 maggiore flessibilità alla gestione del volume, in Android 14 viene introdotto OemCarAudioVolumeService:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
Il servizio volume audio per auto OEM ha un singolo metodo, che accetta una volumeAdjustment e una 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 gli attributi audio attualmente attenuati. 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 il volume. true indica che è stata apportata una modifica e che il gruppo di volumi deve essere aggiornato. volumeGroupChanged è il gruppo di volumi effettivo che deve 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 dovrà essere quello per la navigazione.
Servizio di attenuazione automatica audio per auto OEM
Il servizio audio per auto gestisce l'attenuazione automatica audio monitorando le modifiche del focus audio e inviando un segnale all'HAL AudioControl in merito ai dispositivi audio da attenuare.
Quando il focus cambia, tutti i titolari del focus attivi vengono valutati per determinare
quali devono essere attenuati in base a questo insieme di regole di attenuazione automatica statiche
rules:
- I suoni di emergenza attenuano tutto tranne i suoni delle chiamate
- La sicurezza attenua tutto tranne i suoni di emergenza
- La navigazione attenua tutto tranne i suoni di sicurezza e di emergenza
- Le chiamate attenuano tutto tranne i suoni di sicurezza, di emergenza e di navigazione
- La voce attenua i suoni della suoneria
- La musica e gli annunci devono essere attenuati da tutto
Queste regole non sono esaustive e gli OEM rimangono responsabili della determinazione della modalità di attenuazione dei suoni in base a queste linee guida. Gli OEM possono controllare queste raccomandazioni in modo più attivo in base ai requisiti disponibili. In Android 14 viene introdotto OemCarDuckingService:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
Questa API viene chiamata dal servizio audio per auto in caso di modifiche del focus audio. Riutilizza
il OemCarAudioVolumeRequest introdotto nel
servizio volume audio per auto OEM e contiene le informazioni pertinenti
per decidere quali attributi attenuare. L'elenco degli attributi audio da attenuare dall'API viene confrontato con lo stato audio attuale:
Attributo audio attualmente attenuato:
- Nell'elenco, continua a essere attenuato
- Non presente nell'elenco, attenuazione automatica disattivata
Attributo audio non attualmente attenuato:
- Nell'elenco, attenuato
- Non presente nell'elenco, attenuazione automatica 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 attenuati o all'elenco dei dispositivi audio non attenuati. Queste informazioni vengono infine inviate all' HAL AudioControl per eseguire l' attenuazione automatica richiesta a livello hardware.
La figura seguente mostra un diagramma di sequenza semplificato del controllo dell'attenuazione automatica audio per una richiesta di focus quando viene utilizzato il servizio di attenuazione automatica OEM:
La sequenza inizia quando un'app richiede
la gestione del focus audio
tramite le API del gestore audio pubblico. La richiesta viene inoltrata al servizio audio per auto per determinare i risultati. Quando viene deciso il focus audio, l'attenuazione automatica audio viene valutata dal servizio audio per 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 automatica all'hardware audio.
Implementazione di riferimento del servizio audio per auto OEM
AAOS fornisce un'implementazione di riferimento del servizio per auto OEM in
packages/services/Car/tests/OemCarServiceTestApp, che implementa il
OemCarService, insieme a OemCarAudioFocusService,
OemCarAudioDuckingService, e il 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 focus quando viene chiamata evaluateAudioFocusRequest.
Debug dell'app di test di riferimento
L'app di test del servizio per 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 per auto OEM utilizzi il comando dump del servizio per 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 di dump mIsOemServiceReady specificano se il servizio è pronto per l'uso, dove true indica che è pronto e false indica che non è pronto.