Servizio plug-in per audio dell'auto

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.

immagine

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.

immagine

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.

  1. Navigazione
  2. Chiama
  3. Musica
  4. Annuncio
  5. Comando vocale
  6. Suoneria
  7. Audio sistema
  8. Sicurezza
  9. Sveglia
  10. Notifica
  11. Stato del veicolo
  12. 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:

  1. Chiama
  2. Contenuti multimediali
  3. Annuncio
  4. 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:

immagine

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.