Auto-Audio-Plug-in-Dienst

Aktivierung neuer Plug-in-Dienste für OEMs unter Android 14 Autokomponenten konfiguriert werden. Für Audioanzeigen gibt es drei neue werden Plug-in-Dienste eingeführt, die es OEMs ermöglichen, Audioverwaltung auf AAOS-Geräten:

  • Audiofokus-Steuerung
  • Steuerung der Audiolautstärke und Stummschaltung
  • Audio-Ducking-Steuerung

Architektur von Auto-Plug-ins

Die folgende Abbildung bietet einen Überblick über die Autodienste und deren Beziehung zueinander. OEM-Autoservice. Ähnlich wie bei den App- und Autoserviceprozessen nimmt der OEM-Autoservice seinen eigenen Prozessbereich ein.

Bild

Der Autoservice startet den Autoservice eines Erstausrüsters, indem er nach der Komponente sucht, config_oemCarService Wenn die Konfiguration leer ist, ist der OEM-Dienst nicht vorhanden und es wird kein Dienst gestartet. Die Komponente muss OemCarService verfügbar. Der Audiodienst des Autos muss die APIs für die Übernahme des Audio-OEMs des Autos überschreiben Dienst:

public final class OemCarServiceImp extends OemCarService {
    @Override
    public OemCarAudioFocusService getOemAudioFocusService();

    @Override
    public OemCarAudioDuckingService getOemAudioDuckingService();

    @Override
    public OemCarAudioVolumeService getOemAudioVolumeService();
}

Für Beispiel: Siehe Referenz-Test-App, die in packages/services/Car/tests/OemCarServiceTestApp

Auch wenn der Dienst vom Autoservice gestartet wird, wird er nicht automatisch gestartet. die für den Audiodienst des Autos verfügbaren Berechtigungen übernehmen. Daher werden alle von den OEM-Diensten geforderte Genehmigung Mechanismus zur Verfügung. Siehe zum Beispiel packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml

Audiodienst für Autos mit OEM-Servicearchitektur

In AAOS verwaltet der Auto-Audiodienst diese Aktionen:

  • Audio routing
  • Audiofokus
  • Audio-Ducking
  • Lautstärke und Stummschaltung

Vor Android 14 war dieses Verhalten weitgehend statisch und können nur in den Einstellungen geändert werden, wenn auch nur in sehr wenigen Fällen. Mit Android 14 wurde ein Mechanismus für Audio im Auto eingeführt -Service zur Kommunikation mit einer vom OEM definierten Komponente, die Folgendes verwaltet:

  • Audiofokus
  • Audio-Ducking
  • Lautstärke und Stummschaltung

Die folgende Abbildung zeigt eine vereinfachte Architektur für den Audiodienst des Autos und OEM-Service für Autos. Der Audiodienst des Autos legt verschiedene Hooks fest, die Anrufe an den Audiodienst des OEMs zur Verwaltung des Audioverhaltens. Letzteres tritt nur auf, Die entsprechende Komponente für den Audiodienst des OEMs ist definiert. Andernfalls wird das Feld Auto-Audiodienst verwendet das Standardverhalten.

Bild

Um sicherzustellen, dass der Audiodienst des Autos und der OEM-Audiodienst immer verfügbar sind Übergibt der Auto-Audiodienst bei jedem Anruf die erforderlichen aktuellen Status des Audio-Stacks an den OEM-Audiodienst des Fahrzeugs. Wenn beispielsweise fängt der Auto-Audiodienst eine Anfrage zur Bewertung des Audiofokus ab, übergibt sie den aktuellen Status des Stacks an den OEM-Audiodienst des Autos. Der aktuelle Status umfasst den aktuellen Fokusinhaber und die aktuellen Fokusverlierer. Fokusverlierer sind Fokusanfragen, die noch Teil des Stacks sind, aber vorübergehend verloren gegangen sind fokussiert.

Der Audiodienst des Autos muss alle Audioaktivitäten im Auto verwalten. Wenn das Auto der Audiodienst einige Teile des Audioverhaltens nicht verwaltet, Die dem Audiodienst des Fahrzeugherstellers offengelegten Informationen sind unvollständig. Wenn beispielsweise überschreibt ein OEM die Audiofokusbehandlung im Autoservice, indem er eigene Richtlinie für den Audiofokus haben, kann der Audiodienst des Autos keine OEM-Audiodienst des Fahrzeugs. Das kann die Nutzungsfähigkeit des Autos beeinträchtigen OEM-Audiodienst für die Entscheidungsfindung, da möglicherweise Informationen fehlen, die nicht sichtbar sind Audiodienst des Autos.

Dazu ruft der Auto-Audiodienst beim OEM an. Diese Anrufe prozessübergreifend erfolgen, was die Inter-Process-Kommunikation (IPC) erfordert. IPC erhöht die Latenz bei jedem Aufruf. Es ist wichtig, die Latenz in der OEM-Service

Da Anrufe beim Auto-Audiodienst an den OEM-Dienst blockiert werden, sollte den Audiodienst des Autos nicht bei direkten API-Auswertungen aufrufen. Stattdessen Auto-Audiodienst stellt die notwendigen Informationen bereit, damit Anrufe zwischen der müssen sich zwei Prozesse nur in eine Richtung bewegen.

Definitionen für OEM-Audiodienste für Autos

OEM-Auto-Audiofokusdienst

Auto-Audiodienst verwaltet Audiofokus-Anfragen von Apps durch Registrierung Listener für den Fokus der Audiorichtlinie. Der Audiodienst des Autos hat einen Mechanismus, mit dem die Konzentration auf eine statische Interaktionsmatrix: Die Matrix definiert drei verschiedene Arten von Interaktionen:

  • Gleichzeitige Interaktion. Konzentrationsträger können ihre Konzentration .

  • Exklusive Interaktionen: Die eingehende Fokusanfrage wird vom aktuell fokussiert.

  • Interaktion ablehnen. Eingehende Fokusanfrage abgelehnt aufgrund von mit dem aktuellen Fokus.

Auch wenn dies für einige Anwendungsfälle im Automobilbereich ausreicht, werden nicht alle Anforderungen der Interaktion, die sich aufgrund der Anforderungen des OEMs unterscheiden können. Hierzu verwenden wir stelle den OemCarAudioFocusService vor:

public interface OEmCarAudioFocusService {
    OemCarAuddioFocusResults evaluateAudioFocusRequest(
        OemCarAudioFocusEvaluationRequest request);
    
    void notifyAudioFocusChange(
        List<AudioFocusEntry> holder,
        List<AudioFocusEntry> losers, int zoneId);
}

Die API evaluateAudioFocusRequest wird jederzeit über den Audiodienst des Autos aufgerufen der Audiofokus evaluiert werden muss. Es handelt sich dabei API, die die Rückgabe der Ergebnisse blockiert. Die Anfrage enthält Informationen zum aktuellen Status des Audio-Stacks:

Anhand dieser Informationen können newFocusRequest im Vergleich zu den aktuelle Fokusverlierer in focusHolders und aktuelle Fokusverlierer in focusLosers Die API sollte die folgenden Ergebnisse zurückgeben:

class OemCarAudioFocusResult {
    int audioZoneId;
    int audioFocusEvaluationResults;
    AudioFocusEntry focusResult;
    List<AudioFocusEntry> newLosers;
    List<AudioFocusEntry> newlyBlocked;
}

Es enthält die Informationen über tatsächliche Bewertungsergebnisse audioFocusEvaluationResults gibt an, ob die aktuelle Anfrage gewährt wurde, verzögert wurde oder fehlgeschlagen ist. Alle Änderungen am aktuellen Fokusstapel Sollte je nach Art in newLosers und newlyBlocked festgelegt werden der Stack-Änderung.

Dabei enthält newLosers Einträge, die zuvor im Fokus waren, sollte jetzt entweder dauerhaft oder vorübergehend im Fokus verlieren. Personen ohne Fokus werden weiter aus dem Audio-Fokus-Stack entfernt. werden so lange in den aktuellen Fokus verschoben, bis sie wieder fokussiert sind der ursprünglichen Fokusforschern verworfen wurde. Unabhängig davon, wird der entsprechende Fokus verloren.

Die Liste newlyBlocked enthält Einträge, die sich zuvor im Fokusverlierer befanden. werden aber durch den neuen Eintrag blockiert. Die Blockierung kann dauerhaft oder Vorübergehend; wenn der permanente Fokus blockiert ist, wird der Eintrag aus dem Stapel entfernt und der Fokusverlust wird an die Zuhörer gesendet. Bei vorübergehendem Fokusverlust bleibt der Eintrag im Fokusverlierer-Stack, hinzugefügt, wird kein Fokusverlust wie zuvor gesendet. gesendet, als sie blockiert wurde. Die Blockierung der Anfrage wird endlich aufgehoben, Blockierungen werden entfernt. Wenn der Fokus liegt, abgebrochen.

Die zweite API (notifyAudioFocusChange) wird in einer Richtung aufgerufen und Anfrage oder Vorgang abbrechen. Die API dient in der Regel zur Information des OEM-Dienstes. zu Fokusänderungen, die sich auf das Verhalten des Audiodienstes des Autoherstellers auswirken können.

Richtlinien für die Fokusbewertung

In AAOS wird mit dem Audiofokus die Audiowiedergabe gesteuert und ermittelt, App einhalten, um eine optimale Nutzererfahrung zu bieten. Daher sollte der OEM-Plug-in-Dienst bei der Verwaltung eines Anfrage für Audiofokus:

  • Ohne Audiofokus mit hoher Priorität (wie etwa während eines Anrufs, Notfall- oder Sicherheits-Apps sollten den Audiofokus entweder auf vorübergehend oder dauerhaft sein.

  • Während ein Medienfokus aktiv ist, fordern Apps Folgendes an:

    • Schwerpunkt auf Anrufnutzung; sollte den Fokus entweder gleichzeitig erhalten können oder exklusiv.

    • Fokus auf Navigationsnutzung; sollte entweder auf gleichzeitig oder exklusiv.

    • Assistant-Nutzungsfokus, sollte entweder den Fokus auf die gleichzeitig oder exklusiv.

  • Im Stehen von Audiofokus mit hoher Priorität (z. B. während eines Anrufs, oder Sicherheitswarnung) aktiv sind, alle eingehenden Audiofokussierungen mit Verzögerung entweder gewährt oder verzögert werden.

Die Vorschläge oben sind nicht vollständig, können aber garantieren, Apps, die den Fokus anfordern, sollten den Fokus erhalten können, wenn keine Töne mit hoher Priorität. Auch wenn Töne mit hoher Priorität aktiv sind, wird der verzögerte Fokus respektiert werden und sich gezielter konzentrieren können, stoppt der Ton mit hoher Priorität.

OEM-Autovolumenservice

Der Audiodienst des Autos verwaltet Schlüsselereignisse für die Lautstärke, indem er entweder die Lautstärke abhört Anpassungen über das Audiosystem oder durch direktes Abhören von Lautstärke-Schlüsselereignissen aus dem Auto-Eingabedienst. In jedem Fall ist das Standardverhalten des Autos festlegen, welche Lautstärkegruppe auf Grundlage des aktiven Audioplayer und eine Prioritätsliste für den Audiokontext.

Wir bieten zwei Volumenprioritäten. Die erste Liste umfasst alle Audioinhalte Kontexte in dieser Reihenfolge. Die Liste wird in absteigender Reihenfolge angezeigt, Priorität oben und die niedrigste Priorität unten. Wenn beispielsweise „Audio für die Navigation“ und „Musik“ sind gleichzeitig aktiv. die Navigationslautstärke während eines Schlüsselereignisses geändert wird.

  1. Navigation
  2. Anruf
  3. Musik
  4. Mitteilung
  5. Sprachbefehl
  6. Bei Anruf klingeln
  7. Systemton
  8. Sicherheit
  9. Wecker
  10. Benachrichtigung
  11. Bewegungszustand
  12. Notfall

Um die Verwaltung der Lautstärke-Schlüsselereignisse zu vereinfachen, hat der Auto-Audiodienst eine Audiokontext mit der zweiten Priorität:

  1. Anruf
  2. Medien
  3. Mitteilung
  4. Sprachbefehl

Diese Liste wird ebenfalls in absteigender Reihenfolge dargestellt. Der Zweck dieser Liste dass gängige Geräusche durch Schlüsselereignisse geändert werden können. Ungewöhnlich, beispielsweise kürzere Töne, kannst du in den Audioeinstellungen Nur UI.

Die tatsächliche Version der Lautstärke kann über die audioVolumeAdjustmentContextsVersion-Konfiguration. Die Konfiguration kann ist entweder auf 1 oder 2 festgelegt (2 ist die Standardeinstellung).

Um bei der Volumenverwaltung flexibler zu sein, OemCarAudioVolumeService wird mit Android 14 eingeführt:

public interface OemCarAudioVolumeService {
    OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}

Der OEM-Autoradio hat eine einzige Methode, volumeAdjustment und ein OemCarAudioVolumeRequest:

class OemCarAudioVolumeRequest {
    int audioZoneId;
    int callState;
    List<AudioAttributes> activePlaybackAttributes;
    List<AudioAttributes> duckedAttributes;
    List<CarVolumeGroupInfo> volumeGroupState;
}

Die activePlaybackAttributes der Anfrage hat die aktiven Audioattribute. Die duckedAttributes sind derzeit alle Audioattribute, die mithilfe von Duck-Daten umgewandelt wurden. Die volumeGroupState hat den aktuellen Status der Volume-Gruppe. Die Anfrage stellt den aktuellen Status des Audiostacks dar und kann verwendet werden, um welche Volume-Gruppe geändert werden soll. Die Ergebnisse sollten folgendermaßen zurückgegeben werden: OemCarVolumeChangeInfo:

class OemCarVolumeChangeInfo {
    boolean change;
    CarVolumeGroupInfo volumeGroupChanged;
}

Der boolesche Wert change gibt an, ob sich ein Volumen geändert hat. Mit true wird angegeben, Es wird eine Änderung vorgenommen und die Volume-Gruppe sollte aktualisiert werden. Die volumeGroupChanged ist die tatsächliche Volumengruppe, die geändert werden soll. Dieses Die Gruppe sollte gemäß dem ursprünglichen Parameter volumeAdjustment geändert werden an die API übergeben werden. Wenn die Ergebnisse z. B. zeigen, dass die Navigation sollte stummgeschaltet sein, wäre der boolesche Wert true und der zurückgegebene sollte die Lautstärkegruppe für die Navigation sein.

Entenservice für OEMs

Der Audiodienst im Auto verwaltet Audio-Ducking, indem er Veränderungen des Audiofokus überwacht und ein Signal an den AudioControl-HAL, welche Audiogeräte entfernt werden sollen. Wenn sich der Fokus ändert, werden alle aktiven Fokushalter bewertet, um festzustellen, der auf Grundlage dieser Static-Ducking-Phasen Regeln:

  • Bei Notfalltönen werden nur Anruftöne berücksichtigt
  • Die Sicherheitsfunktion macht alles außer Notfallgeräuschen
  • Die Navigation macht alles weg, mit Ausnahme von Sicherheits- und Notfallgeräuschen
  • Anruf-Benachrichtigungen werden auf alle Notruf-, Notfall- und Navigationstöne zurückgesetzt
  • Klingeltontöne von Voice Ducks
  • Musik und Ankündigungen sollten sich von allem erholen

Diese Regeln sind nicht vollständig und die OEMs sind dafür verantwortlich, wie Töne basierend auf diesen Richtlinien erkannt werden sollten. OEMs können diese aktiver Empfehlungen basierend auf den verfügbaren Anforderungen. Die OemCarDuckingService wird mit Android 14 eingeführt:

class OemCarAudioDuckingService {
List<AudioAttributes>   evaluateAttributesToDuck(
        OemCarAudioVolumeRequest request);
}

Diese API wird bei Änderungen des Audiofokus vom Auto-Audiodienst aufgerufen. Sie kann wiederverwendete OemCarAudioVolumeRequest eingeführt in OEM-Fahrzeugvolumen und enthält die relevanten um zu entscheiden, welche Attribute entrückt werden sollen. Die Liste der Die Audioattribute, die über die API in Duck eingefügt werden, werden mit dem aktuellen Audiostatus verglichen:

  • Aktuelles Audioattribut im Duck:

    • Auf der Liste, weiterhin entdeckt
    • Nicht auf der Liste, Ducking deaktiviert
  • Audioattribut ist derzeit nicht im Ducking:

    • Auf der Liste, dudten
    • Nicht auf der Liste, Ducking deaktiviert

Der Audiodienst des Autos bestimmt dann, auf welchen Audioausgabegeräten die Audioausgabe die Attribute, zu denen die Attribute gehören, und fügt sie der Liste der verfügbaren Audioausgabegeräte oder des Liste der nicht aufgeführten Audiogeräte. Diese wird schließlich an die AudioControl HAL, um die erforderte ein Ducking auf Hardwareebene.

Die folgende Abbildung zeigt ein vereinfachtes Sequenzdiagramm des Audio-Duckings. Steuerelement für eine Fokusanfrage, wenn der OEM-Ducking-Dienst verwendet wird:

Bild

Die Sequenz beginnt, wenn eine Anwendung anfordert Audiofokus verwalten über öffentliche Audio-Manager-APIs. Die Anfrage wird an das Audiosystem des Autos weitergeleitet um die Ergebnisse zu ermitteln. Wenn der Audiofokus festgelegt wurde, vom Auto-Audiodienst ausgewertet, der die OemCarAudioDuckingService aufruft, welche Audioattribute ein Ducking erhalten soll. Sobald die Ergebnisse aus der evaluateAttributesToDuck API werden die Audiogeräte zum Duck berechnet. Schließlich werden die Informationen an AudioControl gesendet, um Ducking anzuwenden. mit der Audiohardware.

Implementierung von Referenzen zum Audiodienst eines OEMs

AAOS bietet eine Referenzimplementierung des OEM-Fahrzeugservice in packages/services/Car/tests/OemCarServiceTestApp implementiert die OemCarService, zusammen mit OemCarAudioFocusService, OemCarAudioDuckingService und OemCarAudioVolumeService. Für Letzteres jeder Dienst eine XML-Datei verwendet, um ein statisches Verhalten zu laden. Beispiel: OemCarAudioFocusServiceImp lädt den oem_focus_config.xml, der enthält eine Interaktionsmatrix. Die Matrix wird verwendet, um die Fokusanfrage auszuwerten wenn evaluateAudioFocusRequest aufgerufen wird.

Debugging von Referenztest-Apps

Die Test-App für den Autoservice eines OEMs ist Teil des AOSP-Quellcodes. OEMs können an ihre Bedürfnisse anpassen. Verwende zur Fehlerbehebung den config_oemCarService. Konfiguration zum Aktivieren der Test-App.

<!-- 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>

Um zu prüfen, ob der OEM-Fahrzeugservice den Befehl dump für die OEM-Service:

adb shell dumpsys car_service --oem-service

Die Ergebnisse könnten in etwa so aussehen:

***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

Jeder boolesche Wert in jedem Batch von dump-Informationen bestimmt den Status des Elements und Service. Beispielsweise gibt die Dump-Info mIsOemServiceReady an, ob der Der Dienst kann verwendet werden, wobei true angibt, dass er einsatzbereit ist, und false gibt an, dass sie nicht bereit ist.