Attivazione dei nuovi servizi di plug-in OEM per auto in Android 14 alcuni componenti dell'auto da configurare. Per l'audio in particolare, tre nuovi Vengono introdotti servizi plug-in, che consentono agli OEM di configurare la gestione dell'audio sui dispositivi AAOS:
- Controllo messa a fuoco audio
- Controllo del volume e della disattivazione audio dell'audio
- Controllo Attenuazione automatica audio
Architettura del servizio plug-in per auto
La figura seguente fornisce una panoramica dei servizi auto e della loro relazione all'autofficina OEM. Analogamente ai processi delle app e ai servizi di assistenza, auto e motori, i processi di assistenza auto di OEM occupano uno spazio di processo dedicato.
Il servizio auto avvia il servizio auto OEM individuando il componente definito in
config_oemCarService. Se la configurazione è vuota, significa che il servizio OEM non esiste.
e non viene avviato alcun servizio. Il componente deve estendere
OemCarService.
Il servizio car audio deve sovrascrivere le API per acquisire l'OEM del car audio
servizio:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Per
esempio, consulta
l'app di test di riferimento definita
packages/services/Car/tests/OemCarServiceTestApp.
Anche se il servizio viene avviato tramite un'auto, non
ereditare le autorizzazioni disponibili per il servizio audio dell'auto. Pertanto, qualsiasi
l'autorizzazione richiesta dai servizi OEM deve essere acquisita con
meccanismo di attenzione. Ad esempio, vedi
packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml.
Servizio audio per auto con architettura del servizio OEM
In AAOS, il servizio audio 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 potevano essere modificate solo tramite le impostazioni, anche se per un insieme molto limitato di casi. Android 14 ha introdotto un meccanismo per l'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 assistenza OEM auto. Il servizio audio dell'auto definisce ganci diversi che possono chiamare il servizio audio dell'OEM dell'auto per gestire il comportamento dell'audio. Il secondo si verifica solo se è stato definito il componente del servizio audio auto OEM corrispondente. In caso contrario, servizio car audio utilizza il comportamento predefinito.
Per assicurarsi che il servizio audio dell'auto e il servizio audio dell'OEM dell'auto siano sempre attivi di sincronizzazione, per ogni chiamata il servizio audio dell'auto trasmette le parti richieste della stato attuale dello stack audio al servizio audio OEM per auto. Ad esempio, quando il servizio audio per auto intercetta una richiesta per valutare il focus audio, passa lo stato attuale dello stack al servizio audio OEM per auto. Lo stato attuale include il titolare attuale dello stato attivo e gli attuali perdenti. I perdenti sono attiva le richieste che fanno ancora parte dello stack, ma che sono state temporaneamente perse il focus.
Il servizio audio dell'auto deve gestire tutte le attività audio dell'auto. Se l'auto servizio audio non gestisce alcune parti del comportamento dell'audio, il servizio le informazioni esposte al servizio audio dell'OEM dell'auto sono incomplete. Ad esempio, se un OEM sovrascrive la gestione del focus audio nel servizio auto registrando il proprio criterio di messa a fuoco audio, il servizio audio dell'auto non può fornire le informazioni al servizio audio dell'OEM dell'auto. Questo può influire sulla capacità dell'auto Servizio audio OEM per prendere decisioni perché potrebbe mancare di informazioni non visibili al servizio audio dell'auto.
Per eseguire azioni, il servizio di audio auto chiama i servizi per auto OEM. Queste chiamate vengono effettuati nei vari processi, il che richiede la comunicazione tra processi (IPC, Inter-Process Communication). IPC aggiunge latenza a ogni chiamata. È importante ridurre al minimo la latenza Assistenza OEM.
Poiché le chiamate del servizio audio auto al servizio OEM vengono bloccate, il servizio OEM non deve chiamare il servizio audio dell'auto nelle valutazioni dirette delle API. Invece, car audio fornisce le informazioni necessarie per fare in modo che le chiamate tra due processi devono spostarsi in una sola direzione.
Definizioni dei servizi audio per auto OEM
Servizio di messa a fuoco audio auto OEM
Il servizio audio dell'auto gestisce le richieste di messa a fuoco audio delle app registrando un listener dei criteri audio. Il servizio audio dell'auto ha un meccanismo per gestire focus sul comportamento statico Matrice di interazione. La matrice definisce tre diversi tipi di interazioni:
Interazione simultanea. Gli elementi in evidenza possono mantenere al contempo nel tempo.
Interazioni esclusive. La richiesta di impostazione dello stato attivo in arrivo contenitore attivo.
Rifiutare l'interazione. Richiesta di impostazione dello stato attivo in entrata rifiutata in base a attuale elemento attivo.
Sebbene sia sufficiente per alcuni casi d'uso nel settore auto e motori, non soddisfa tutte le
Esigenze di interazione che potrebbero variare a causa dei requisiti dell'OEM. Per questo
presenta 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 in qualsiasi momento
una richiesta di attenzione all'audio deve essere valutata,
API 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 a
focus attuali in focusHolders e utenti perdenti attuali in
focusLosers. L'API dovrebbe restituire i risultati:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
Contiene informazioni sui risultati effettivi delle valutazioni in
audioFocusEvaluationResults, che indica se la richiesta corrente ha
è stato concesso, è stato ritardato o non è andato a buon fine. Eventuali modifiche all'attuale stack attivo
deve essere impostato nelle voci newLosers e newlyBlocked, a seconda della natura
della modifica dello stack.
Dove newLosers contiene voci che in precedenza contenevano lo stato attivo, ma
ora dovrebbero perdere lo stato attivo, in modo permanente o temporaneo. Perdenti del focus permanente
verranno ulteriormente rimossi dallo stack di elementi di messa a fuoco audio
verranno spostati nell'attuale stack di perdenti dello stato attivo finché non riprendono lo stato attivo o
abbandonando il richiedente originale. In ogni caso, chi ascolta
le richieste riceveranno lo stato attivo corrispondente perso.
L'elenco newlyBlocked contiene voci che in precedenza erano nella perdita di stato attivo
ma ora sono bloccati dalla nuova voce. Il blocco può essere permanente
temporaneo. In caso di blocco dell'elemento attivo permanente, la voce verrà rimossa dallo stack
e la perdita di focus verrà inviata
a chi ascolta il focus. Per una perdita di messa a fuoco temporanea,
la voce rimarrà nello stack dei perdenti, ma verrà applicato un nuovo blocco dello stato attivo
aggiunto all'elenco di blocchi, non verrà inviata alcuna perdita di messa a fuoco come in precedenza
inviato quando è stato bloccato per la prima volta. La richiesta verrà finalmente sbloccata quando
i blocchi attuali vengono rimossi o saranno rimossi dalla pila se lo stato attivo è impostato
abbandonata.
La seconda API, notifyAudioFocusChange, è un modo che viene chiamato ogni
richiesta di messa a fuoco audio o abbandono. L'API viene utilizzata principalmente per informare il servizio OEM
sulle modifiche dell'elemento attivo, che potrebbero influire sul comportamento del servizio audio auto OEM.
Linee guida per la valutazione degli obiettivi
In AAOS, il focus audio viene utilizzato per gestire la riproduzione audio e determinare quali devono rispettare le norme per offrire all'utente un'esperienza ottimale. Di conseguenza, il servizio di plug-in dell'OEM deve tenere conto di quanto segue quando gestisce un richiesta di messa a fuoco audio:
Senza alcun focus audio permanente (ad esempio una telefonata, emergenza o sicurezza), le app devono essere in grado di in modo temporaneo o permanente.
Quando è attivo un elemento multimediale, le app che richiedono:
Focus sull'utilizzo delle chiamate, deve essere in grado di riceverlo contemporaneamente o in modo esclusivo.
Stato attivo sull'utilizzo della navigazione, deve essere in grado di ricevere lo stato attivo contemporaneamente o in modo esclusivo.
L'uso dell'assistente deve essere incentrato su contemporaneamente o in modo esclusivo.
Mentre sei in piedi con audio focus ad alta priorità (ad esempio una telefonata, avviso di sicurezza o avviso di sicurezza) siano attive, qualsiasi focus audio ritardato in entrata deve essere accolta o ritardata in base alle esigenze.
Sebbene i suggerimenti sopra riportati non siano esaustivi, possono contribuire a garantire che le app che richiedono lo stato attivo dovrebbero essere in grado di acquisire lo stato attivo quando non sono attive suoni con priorità elevata. Anche quando i suoni ad alta priorità sono attivi, focus ritardato richieste dovrebbero essere comunque rispettate e potersi concentrare una volta l'audio ad alta priorità si interrompe.
Servizio volume auto OEM
Il servizio audio dell'auto gestisce gli eventi della chiave del volume ascoltando il volume regolazioni dal sistema audio o ascoltando direttamente gli eventi dei tasti del volume dal servizio di input dell'auto. In ogni caso, il comportamento predefinito dell'auto il servizio audio determina quale gruppo di volume modificare in base al volume attivo lettori audio e un elenco di priorità in contesto audio.
Forniamo due elenchi di priorità del volume. Il primo elenco considera tutto l'audio contesti in quest'ordine. L'elenco viene presentato in ordine decrescente, dalla parte più alta la priorità più alta e quella più bassa in basso. Ad esempio, se l'audio del navigatore e l'audio della musica sono attivi contemporaneamente, quindi 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 rendere meno complessa la gestione degli eventi chiave del volume, il servizio audio per auto dispone di una secondo elenco di priorità per il contesto audio:
- Chiama
- Contenuti multimediali
- Annuncio
- Comando vocale
Questo elenco viene presentato anche in ordine decrescente. Lo scopo di questo secondo elenco è quella di consentire la modifica dei suoni più comuni attraverso eventi chiave. Insolito, forse suoni di durata inferiore, possono essere gestiti tramite le impostazioni audio solo nell'interfaccia utente.
La versione effettiva del volume può essere impostata con
Configurazione di audioVolumeAdjustmentContextsVersion. La configurazione può essere
impostato su 1 o 2 (2 è il valore predefinito).
Per offrire maggiore flessibilità
nella gestione dei volumi,
In Android 14 viene introdotto OemCarAudioVolumeService:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
Il servizio di volume dell'audio dell'auto OEM ha un unico metodo, che prevede un
volumeAdjustment e OemCarAudioVolumeRequest:
class OemCarAudioVolumeRequest {
int audioZoneId;
int callState;
List<AudioAttributes> activePlaybackAttributes;
List<AudioAttributes> duckedAttributes;
List<CarVolumeGroupInfo> volumeGroupState;
}
L'elemento activePlaybackAttributes della richiesta ha gli attributi audio attivi. La
duckedAttributes sono tutti attributi audio attualmente oscurati. La
volumeGroupState è lo stato attuale del gruppo di volumi. La richiesta
rappresenta lo stato corrente dello stack audio e può essere utilizzato per determinare
il gruppo di volumi da modificare. I risultati devono essere restituiti in
OemCarVolumeChangeInfo:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
Il valore booleano change indica se un volume è cambiato, true indica che
è stata apportata una modifica e il gruppo di volume dovrebbe essere aggiornato. La
volumeGroupChanged è il gruppo di volume effettivo che deve essere modificato. Questo
gruppo deve essere modificato in base al parametro volumeAdjustment originale
passate all'API. Ad esempio, se i risultati indicano che la navigazione
il gruppo di volumi deve essere disattivato, il valore booleano sarebbe true e il valore
per la navigazione.
Servizio di oscuramento automatico delle auto OEM
Il servizio audio dell'auto gestisce l'attenuazione automatica audio monitorando le modifiche di messa a fuoco audio e
invio di un segnale all'HAL AudioControl per informazioni su quali dispositivi audio ridurre.
Quando l'elemento attivo cambia, tutti i relativi titolari vengono valutati per determinare
che dovrebbe essere adattato in base a questo insieme di attenuazioni automatiche
regole:
- I suoni di emergenza eliminano tutto tranne i suoni di chiamata
- La sicurezza nasconde tutto tranne i suoni di emergenza
- La navigazione oscura tutto tranne i suoni di sicurezza e di emergenza
- La chiamata viene attenuata, tranne i suoni di sicurezza, emergenza e navigazione
- Suono della suoneria di chiamata anatre
- La musica e gli annunci dovrebbero essere occulti da tutto
Queste regole non sono esaustive e gli OEM restano responsabili della determinazione
come applicare i suoni
in base a queste linee guida. Gli OEM possono controllare
di fornire consigli più attivamente in base ai requisiti disponibili. La
In Android 14 viene introdotto OemCarDuckingService:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
Questa API viene chiamata dal servizio car audio per i cambiamenti dello stato attivo dell'audio. Riutilizza
lo OemCarAudioVolumeRequest introdotto in
Servizio volume auto OEM e contiene i dati pertinenti
informazioni per decidere quali attributi anatra. L'elenco di
attributi audio a duck dall'API vengono confrontati con lo stato audio corrente:
Attributo audio attualmente oscurato:
- Nell'elenco, continua a essere nascosto
- Non in elenco, attenuazione automatica disattivata
Attributo audio attualmente non oscurato:
- In elenco, nascosto
- Non in elenco, attenuazione automatica disattivata
Il servizio audio dell'auto determina quindi su quali dispositivi di uscita audio l'audio gli attributi a cui appartengono e li aggiunge all'elenco dei dispositivi di output audio disattivato o alla dei dispositivi audio non connessi. Alla fine, questo viene inviato AudioControl HAL per eseguire è stato richiesto l'attenuazione automatica a livello di hardware.
La figura seguente mostra un diagramma sequenziale semplificato dell'attenuazione automatica audio per una richiesta di impostazione dello stato attivo quando viene utilizzato il servizio di attenuazione automatica dell'OEM:
La sequenza inizia quando un'app richiede
Gestire il focus audio
tramite le API pubbliche di
Gestione audio. La richiesta viene inoltrata all'audio dell'auto
per determinare i risultati. Quando viene deciso il focus dell'audio, la funzionalità Attenuazione automatica audio
viene valutato dal servizio audio dell'auto chiamando il OemCarAudioDuckingService a
per valutare quali attributi audio devono essere oscurati. Una volta restituiti i risultati
dall'API evaluateAttributesToDuck, vengono calcolati i dispositivi audio a duck,
Infine, le informazioni vengono inviate al AudioControl per applicare l'attenuazione automatica
all'hardware audio.
Implementazione del 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 parametro
OemCarService, insieme a OemCarAudioFocusService,
OemCarAudioDuckingService e OemCarAudioVolumeService. 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.
Debug di app di test di riferimento
L'app di test dei servizi auto OEM fa parte del codice sorgente AOSP. Gli OEM possono
cambia in base alle sue esigenze. Per il debug, utilizza l'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 la
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 caratteristica
e servizio. Ad esempio, le informazioni di dump mIsOemServiceReady specificano se
servizio è pronto per essere utilizzato, dove true indica che è pronto e false
indica che non è pronto.