Aktivierung neuer Plug-in-Dienste für OEMs unter Android 14 Autokomponenten konfiguriert werden. Für Audioanzeigen gibt es drei neue Es werden Plug-in-Dienste eingeführt, die es OEMs ermöglichen, Audioverwaltung auf AAOS-Geräten:
- Audiofokus-Steuerung
- Steuerung für 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 Autoservice-Prozessen nimmt der OEM-Autoservice seinen eigenen Prozessbereich ein.
Die Autowerkstatt beginnt die OEM-Fahrzeugserviceleistung, indem die in der
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.
Um sicherzustellen, dass der Audiodienst des Autos und der OEM-Audiodienst immer verfügbar sind Übergibt der Auto-Audiodienst bei jedem Anruf die erforderlichen 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. Beispiel: ü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. Dies kann die Nutzungsfähigkeit des Autos beeinträchtigen OEM-Audiodienst, um Entscheidungen zu treffen, da möglicherweise Informationen fehlen, die nicht sichtbar sind Audiodienst des Autos.
Dazu ruft der Auto-Audiodienst die OEM-Autoservices 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 im 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.
Die newLosers enthält 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,
aktuelle Blockaden 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 festgelegt, 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. Beispiel: „Audio für die Navigation“ und „Musik“ sind gleichzeitig aktiv. die Navigationslautstärke während eines Schlüsselereignisses geändert wird.
- Navigation
- Anruf
- Musik
- Mitteilung
- Sprachbefehl
- Bei Anruf klingeln
- Systemton
- Sicherheit
- Wecker
- Benachrichtigung
- Bewegungszustand
- Notfall
Um die Verwaltung der Lautstärke-Schlüsselereignisse zu vereinfachen, hat der Auto-Audiodienst eine Audiokontext mit der zweiten Priorität:
- Anruf
- Medien
- Mitteilung
- 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 das
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 aktuell 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 wird gesendet, welche Audiogeräte ausgewählt 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 weiterhin 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
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:
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. Die Dump-Informationen mIsOemServiceReady gibt beispielsweise an, ob der
Der Dienst kann verwendet werden, wobei true angibt, dass er einsatzbereit ist, und false
gibt an, dass sie nicht bereit ist.