Neue Auto-OEM-Plugin-Dienste in Android 14 ermöglichen die Konfiguration einiger Autokomponenten. Speziell für Audio werden drei neue Plugin-Dienste eingeführt, die es OEMs ermöglichen, das Audiomanagement auf AAOS-Geräten flexibel zu konfigurieren:
- Audio-Fokussteuerung
- Lautstärke- und Stummschaltungssteuerung
- Audio-Ducking-Steuerung
Auto-Plugin-Service-Architektur
Die folgende Abbildung gibt einen Überblick über die Autoservices und ihre Beziehung zum OEM-Autoservice. Ähnlich wie die App-Prozesse und der Autoservice-Prozess belegt der OEM-Autoservice-Prozess einen eigenen Prozessraum.
Der Autoservice startet den OEM-Autoservice, indem er die in config_oemCarService definierte Komponente findet. Wenn die Konfiguration leer ist, existiert der OEM-Dienst nicht und es wird kein Dienst gestartet. Die Komponente muss OemCarService erweitern. Der Car-Audio-Dienst muss die APIs für den Erwerb des Car-Audio-OEM-Dienstes überschreiben:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Sehen Sie sich beispielsweise die Referenztest-App an, die in packages/services/Car/tests/OemCarServiceTestApp definiert ist.
Auch wenn der Dienst vom Autodienst gestartet wird, erbt er nicht automatisch die für den Autoradiodienst verfügbaren Berechtigungen. Daher sollte jede für OEM-Dienste erforderliche Genehmigung mit dem richtigen Mechanismus eingeholt werden. Siehe beispielsweise packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml .
Car-Audio-Service mit OEM-Service-Architektur
In AAOS verwaltet der Car-Audio-Dienst die folgenden Aktionen:
- Audio-Routing
- Audio-Fokus
- Audio-Ducking
- Lautstärke und Stummschaltung
Vor Android 14 war dieses Verhalten weitgehend statisch und konnte nur über Einstellungen geändert werden, wenn auch für eine sehr begrenzte Anzahl von Fällen. Mit Android 14 wurde ein Mechanismus für den Car-Audio-Dienst eingeführt, um mit einer OEM-definierten Komponente zu kommunizieren, die Folgendes verwaltet:
- Audio-Fokus
- Audio-Ducking
- Lautstärke und Stummschaltung
Die folgende Abbildung zeigt eine vereinfachte Architektur für den Car-Audio-Dienst und den Auto-OEM-Dienst. Der Auto-Audiodienst definiert verschiedene Hooks, die den Auto-OEM-Audiodienst aufrufen können, um das Audioverhalten zu verwalten. Letzteres geschieht nur, wenn die entsprechende OEM-Car-Audio-Dienstkomponente definiert ist. Andernfalls verwendet der Car-Audio-Dienst das Standardverhalten.
Um sicherzustellen, dass der Car-Audio-Dienst und der Auto-OEM-Audiodienst immer synchron sind, übergibt der Car-Audio-Dienst bei jedem Anruf die erforderlichen Teile des aktuellen Status des Audio-Stacks an den Auto-OEM-Audio-Dienst. Wenn der Auto-Audiodienst beispielsweise eine Anfrage zur Bewertung des Audiofokus abfängt, übergibt er den aktuellen Status des Stapels an den Auto-OEM-Audiodienst. Der aktuelle Status umfasst den aktuellen Fokushalter und die aktuellen Fokusverlierer. Fokusverlierer sind Fokusanfragen, die noch Teil des Stapels sind, aber vorübergehend den Fokus verloren haben.
Der Car-Audio-Dienst muss alle Audioaktivitäten im Auto verwalten. Wenn der Auto-Audiodienst einige Teile des Audioverhaltens nicht verwaltet, sind die dem Auto-OEM-Audiodienst zur Verfügung gestellten Informationen unvollständig. Wenn beispielsweise ein OEM die Audio-Fokus-Verwaltung im Autodienst überschreibt, indem er seine eigene Audio-Fokus-Richtlinie registriert, kann der Auto-Audiodienst dem Auto-OEM-Audiodienst keine vollständigen Informationen bereitstellen. Dies kann die Entscheidungsfähigkeit des Auto-OEM-Audiodienstes beeinträchtigen, da ihm möglicherweise Informationen fehlen, die für den Auto-Audiodienst nicht sichtbar sind.
Um Maßnahmen zu ergreifen, ruft der Car-Audio-Dienst die OEM-Autodienste an. Diese Aufrufe erfolgen prozessübergreifend, was eine Interprozesskommunikation (IPC) erfordert. IPC erhöht die Latenz bei jedem Anruf. Es ist wichtig, die Latenz im OEM-Dienst zu minimieren.
Da Car-Audio-Dienstaufrufe an den OEM-Dienst blockierend sind, sollte der OEM-Dienst den Car-Audio-Dienst bei direkten API-Auswertungen nicht aufrufen. Stattdessen stellt der Car-Audio-Dienst die notwendigen Informationen bereit, sodass Anrufe zwischen den beiden Prozessen nur in eine Richtung erfolgen müssen.
Definitionen von OEM-Car-Audio-Diensten
OEM-Car-Audio-Fokusservice
Der Car-Audio-Dienst verwaltet Audio-Fokus-Anfragen von Apps durch die Registrierung eines Audio-Richtlinien-Fokus-Listeners. Der Car-Audio-Dienst verfügt über einen Mechanismus zur Verwaltung des Fokusverhaltens basierend auf einer statischen Interaktionsmatrix . Die Matrix definiert drei verschiedene Arten von Interaktionen:
Gleichzeitige Interaktion. Fokushalter können gleichzeitig den Fokus beibehalten.
Exklusive Interaktionen. Eine eingehende Fokusanforderung übernimmt den Fokus vom aktuellen Fokushalter.
Interaktion ablehnen. Eingehende Fokusanfrage wurde basierend auf dem aktuellen Fokusinhaber abgelehnt.
Während dies für einige Anwendungsfälle im Automobilbereich ausreicht, werden nicht alle Interaktionsanforderungen erfüllt, die aufgrund von OEM-Anforderungen unterschiedlich sein können. Hierzu stellen wir den OemCarAudioFocusService vor:
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
Die API evaluateAudioFocusRequest wird immer dann vom Car-Audio-Dienst aufgerufen, wenn eine Anforderung für den Audiofokus vorliegt, die ausgewertet werden muss. Dabei handelt es sich um eine Zwei-Wege-API, die die Rückgabe der Ergebnisse blockiert. Die Anfrage enthält Informationen zum aktuellen Status des Audio-Stacks:
Diese Informationen können verwendet werden, um die newFocusRequest im Vergleich zu den aktuellen Fokusinhabern in focusHolders und den aktuellen Fokusverlierern in focusLosers auszuwerten. Die API sollte die Ergebnisse zurückgeben:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
Enthält die Informationen zu den tatsächlichen Bewertungsergebnissen in audioFocusEvaluationResults , die angeben, ob die aktuelle Anforderung gewährt, verzögert oder fehlgeschlagen wurde. Jegliche Änderungen am aktuellen Fokusstapel sollten je nach Art der Stapeländerung in den Einträgen newLosers und newlyBlocked festgelegt werden.
Wobei newLosers Einträge enthält, die zuvor den Fokus hatten, jetzt aber dauerhaft oder vorübergehend den Fokus verlieren sollten. Permanente Fokusverlierer werden weiter aus dem Audio-Fokusstapel entfernt, und vorübergehende Fokusverlierer werden in den aktuellen Fokusverliererstapel verschoben, bis sie wieder den Fokus erlangen oder vom ursprünglichen Fokusanforderer aufgegeben werden. Unabhängig davon erhält der Fokus-Listener für die Anfragen einen entsprechenden Fokusverlust.
Die Liste newlyBlocked enthält Einträge, die zuvor in der Focus-Loser-Liste waren, jetzt aber durch den neuen Eintrag blockiert werden. Die Blockierung kann dauerhaft oder vorübergehend sein. Bei dauerhafter Fokusblockierung wird der Eintrag aus dem Stapel entfernt und der Fokusverlust wird an die Fokus-Listener gesendet. Bei einem vorübergehenden Fokusverlust bleibt der Eintrag im Fokusverliererstapel, aber ein neuer Fokusblocker wird zu seiner Blockerliste hinzugefügt. Es wird kein Fokusverlust gesendet, da einer zuvor gesendet wurde, als er zum ersten Mal blockiert wurde. Die Anforderung wird endgültig entsperrt, wenn alle aktuellen Blocker entfernt werden, oder sie wird vom Stapel entfernt, wenn der Fokus aufgegeben wird.
Die zweite API, notifyAudioFocusChange , ist eine Einweg-API, die bei jeder Audio-Fokus-Anfrage oder jedem Abbruch aufgerufen wird. Die API wird hauptsächlich verwendet, um den OEM-Dienst über Fokusänderungen zu informieren, die sich auf das Verhalten des OEM-Car-Audio-Dienstes auswirken können.
Richtlinien zur Fokusbewertung
In AAOS wird der Audiofokus verwendet, um die Audiowiedergabe zu verwalten und zu bestimmen, welche App eingehalten werden soll, um dem Benutzer ein optimales Erlebnis zu bieten. Daher sollte der OEM-Plugin-Dienst bei der Verwaltung einer Audio-Fokus-Anfrage Folgendes berücksichtigen:
Ohne einen ständigen Audio-Fokus mit hoher Priorität (z. B. ein Telefonanruf, ein Notfall oder eine Sicherheitsvorkehrung) sollten Apps in der Lage sein, vorübergehend oder dauerhaft einen Audio-Fokus zu erhalten.
Während ein Medienfokus aktiv ist, fordern Apps Folgendes an:
Der Anrufnutzungsfokus sollte in der Lage sein, den Fokus entweder gleichzeitig oder ausschließlich zu erhalten.
Der Navigationsnutzungsfokus sollte entweder gleichzeitig oder ausschließlich den Fokus erhalten können.
Der Fokus der Assistentennutzung sollte in der Lage sein, den Fokus entweder gleichzeitig oder ausschließlich zu erhalten.
Während Apps mit hoher Audio-Fokus-Priorität (z. B. ein Telefonanruf, Notfallalarm oder Sicherheitsalarm) aktiv sind, sollte jede eingehende verzögerte Audio-Fokus-Anfrage je nach Bedarf entweder gewährt oder verzögert werden.
Obwohl die oben genannten Vorschläge keinen Anspruch auf Vollständigkeit erheben, können sie dazu beitragen, sicherzustellen, dass Apps, die den Fokus anfordern, auch dann den Fokus erhalten können, wenn keine aktiven Töne mit hoher Priorität vorhanden sind. Auch wenn Töne mit hoher Priorität aktiv sind, sollten verzögerte Fokusanforderungen weiterhin berücksichtigt werden und in der Lage sein, den Fokus zu erlangen, sobald der Ton mit hoher Priorität stoppt.
Volumenservice für OEM-Fahrzeuge
Der Car-Audio-Dienst verwaltet Lautstärketastenereignisse, indem er entweder Lautstärkeanpassungen vom Audiosystem abhört oder Lautstärketastenereignisse direkt vom Autoeingabedienst abhört. In jedem Fall besteht das Standardverhalten des Car-Audio-Dienstes darin, anhand der aktiven Audio-Player und einer Audio-Kontext-Prioritätsliste zu bestimmen, welche Lautstärkegruppe geändert werden soll.
Wir stellen zwei Volumenprioritätslisten zur Verfügung. Die erste Liste berücksichtigt alle Audiokontexte in dieser Reihenfolge. Die Liste wird in absteigender Reihenfolge angezeigt, wobei die höchste Priorität oben und die niedrigste Priorität unten steht. Wenn beispielsweise Navigations-Audio und Musik-Audio gleichzeitig aktiv sind, wird die Navigationslautstärke während eines Lautstärketastenereignisses geändert.
- Navigation
- Anruf
- Musik
- Bekanntmachung
- Sprachbefehl
- Anruf klingeln
- Systemton
- Sicherheit
- Alarm
- Benachrichtigung
- Fahrzeugstatus
- Notfall
Um die Verwaltung von Lautstärketastenereignissen weniger komplex zu gestalten, verfügt der Car-Audio-Dienst über eine zweite Prioritätsliste für Audiokontexte:
- Anruf
- Medien
- Bekanntmachung
- Sprachbefehl
Diese Liste wird auch in absteigender Reihenfolge angezeigt. Der Zweck dieser zweiten Liste besteht darin, die Änderung gebräuchlicherer Geräusche durch Tastenereignisse zu ermöglichen. Ungewöhnliche Geräusche, möglicherweise von kürzerer Dauer, können nur über die Benutzeroberfläche der Audioeinstellungen verwaltet werden.
Die tatsächliche Version des Volumes kann mit der audioVolumeAdjustmentContextsVersion Konfiguration festgelegt werden. Die Konfiguration kann entweder auf 1 oder 2 eingestellt werden ( 2 ist die Standardeinstellung).
Um mehr Flexibilität bei der Lautstärkeverwaltung zu bieten, wird OemCarAudioVolumeService in Android 14 eingeführt:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
Der OEM-Autoradio-Lautstärkedienst verfügt über eine einzige Methode, die ein volumeAdjustment und ein OemCarAudioVolumeRequest akzeptiert:
class OemCarAudioVolumeRequest {
int audioZoneId;
int callState;
List<AudioAttributes> activePlaybackAttributes;
List<AudioAttributes> duckedAttributes;
List<CarVolumeGroupInfo> volumeGroupState;
}
Die activePlaybackAttributes der Anfrage verfügen über die aktiven Audioattribute. Die duckedAttributes sind alle derzeit ducked Audioattribute. Der volumeGroupState enthält den aktuellen Status der Volume-Gruppe. Die Anfrage stellt den aktuellen Zustand des Audio-Stacks dar und kann verwendet werden, um zu bestimmen, welche Volume-Gruppe geändert werden soll. Die Ergebnisse sollten in OemCarVolumeChangeInfo zurückgegeben werden:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
Der boolesche change gibt an, ob sich ein Volume geändert hat. „ true gibt an, dass eine Änderung vorliegt und die Volume-Gruppe aktualisiert werden sollte. volumeGroupChanged ist die eigentliche Volume-Gruppe, die geändert werden soll. Diese Gruppe sollte entsprechend dem ursprünglichen volumeAdjustment Parameter geändert werden, der an die API übergeben wurde. Wenn die Ergebnisse beispielsweise darauf hinweisen, dass die Navigations-Volume-Gruppe stummgeschaltet werden sollte, wäre der boolesche Wert „ true und die zurückgegebene Volume-Gruppe sollte die für die Navigation sein.
OEM-Auto-Ducking-Service
Der Car-Audio-Dienst verwaltet das Audio-Ducking, indem er Änderungen des Audio-Fokus überwacht und ein Signal an die AudioControl HAL sendet, um anzugeben, welche Audiogeräte geduckt werden sollen. Wenn sich der Fokus ändert, werden alle aktiven Fokushalter ausgewertet, um anhand dieses Satzes statischer Ducking- Regeln zu bestimmen, welche geduckt werden sollen:
- Notruftöne unterdrücken alles außer Ruftönen
- Die Sicherheit unterdrückt alles außer Notfallgeräuschen
- Die Navigation blendet alles außer Sicherheits- und Notfallgeräuschen aus
- Call duckt alles außer Sicherheits-, Notfall- und Navigationsgeräuschen
- Sprachenten rufen Klingeltöne an
- Musik und Ansagen sollten von allem unterdrückt werden
Diese Regeln erheben keinen Anspruch auf Vollständigkeit und es liegt weiterhin bei den OEMs, auf der Grundlage dieser Richtlinien zu bestimmen, wie Geräusche unterdrückt werden sollen. OEMs können diese Empfehlungen basierend auf den verfügbaren Anforderungen aktiver steuern. Der OemCarDuckingService wird in Android 14 eingeführt:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
Diese API wird vom Car-Audio-Dienst bei Änderungen des Audio-Fokus aufgerufen. Es verwendet die im OEM-Autovolumendienst eingeführte OemCarAudioVolumeRequest wieder und enthält die relevanten Informationen, um die Entscheidung darüber zu treffen, welche Attribute entfernt werden sollen. Die Liste der Audioattribute, die aus der API entfernt werden sollen, wird mit dem aktuellen Audiostatus verglichen:
Derzeit ausgeblendetes Audioattribut:
- Auf der Liste wird weiterhin geduckt
- Nicht auf der Liste, Ducking ausgeschaltet
Audioattribut derzeit nicht ausgeblendet:
- Auf der Liste, geduckt
- Nicht auf der Liste, Ducking ausgeschaltet
Der Car-Audio-Dienst ermittelt dann, zu welchen Audioausgabegeräten die Audioattribute gehören, und fügt sie der Liste der ausgeblendeten Audioausgabegeräte bzw. der Liste der ausgeblendeten Audiogeräte hinzu. Dies wird letztendlich an die AudioControl HAL gesendet, um das erforderliche Ducking auf Hardwareebene durchzuführen.
Die folgende Abbildung zeigt ein vereinfachtes Sequenzdiagramm der Audio-Ducking-Steuerung für eine Fokusanforderung bei Verwendung des OEM-Ducking-Dienstes:
Die Sequenz beginnt, wenn eine App den Audiofokus über öffentliche Audio-Manager-APIs verwalten anfordert. Die Anfrage wird an den Car-Audio-Dienst weitergeleitet, um die Ergebnisse zu ermitteln. Wenn der Audio-Fokus festgelegt ist, wird das Audio-Ducking durch den Car-Audio-Dienst ausgewertet, der den OemCarAudioDuckingService aufruft, um zu ermitteln, welche Audioattribute geduckt werden sollten. Sobald die Ergebnisse von der evaluateAttributesToDuck -API zurückgegeben werden, werden die zu duckenden Audiogeräte berechnet und schließlich werden die Informationen an AudioControl gesendet, um Ducking auf die Audio-Hardware anzuwenden.
Referenzimplementierung eines OEM-Car-Audio-Dienstes
AAOS stellt eine Referenzimplementierung des OEM-Autoservices in packages/services/Car/tests/OemCarServiceTestApp bereit, die den OemCarService zusammen mit OemCarAudioFocusService , OemCarAudioDuckingService und OemCarAudioVolumeService implementiert. Für Letzteres verwendet jeder Dienst eine XML-Datei, um ein statisches Verhalten zu laden. Beispielsweise lädt OemCarAudioFocusServiceImp die Datei oem_focus_config.xml , die eine Interaktionsmatrix enthält. Die Matrix wird verwendet, um die Fokusanforderung auszuwerten, wenn „ evaluateAudioFocusRequest aufgerufen wird.
Referenztest-App-Debugging
Die OEM-Autoservice-Test-App ist Teil des AOSP-Quellcodes. OEMs können je nach Bedarf Änderungen vornehmen. Verwenden Sie zum Debuggen die Konfiguration config_oemCarService , um die Test-App zu aktivieren.
<!-- 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 den OEM-Autodienst zu überprüfen, verwenden Sie den Befehl „car service dump für den OEM-Dienst:
adb shell dumpsys car_service --oem-service
Die Ergebnisse könnten der folgenden Ausgabe ähneln:
***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 Stapel von dump Informationen bestimmt den Status der Funktion und des Dienstes. Die Dump-Info mIsOemServiceReady gibt beispielsweise an, ob der Dienst zur Verwendung bereit ist, wobei true angibt, dass er bereit ist, und „ false angibt, dass er nicht bereit ist.