Mit den neuen OEM-Plug-in-Diensten für Autos in Android 14 können einige Autokomponenten konfiguriert werden. Speziell für Audio werden drei neue Plug-in-Dienste eingeführt, mit denen OEMs die Audioverwaltung auf AAOS-Geräten flexibel konfigurieren können:
- Audiofokussteuerung
- Lautstärke und Stummschaltung der Audiowiedergabe
- Audio-Ducking-Steuerung
Architektur des Plug-in-Dienstes für Autos
Die folgende Abbildung bietet einen Überblick über die Fahrzeugdienste und ihre Beziehung zum Fahrzeugdienst des OEMs. Ähnlich wie die App-Prozesse und der Autoserviceprozess belegt der OEM-Autoserviceprozess einen eigenen Prozessbereich.
Der Autodienst startet den OEM-Autodienst, indem er die in config_oemCarService definierte Komponente sucht. Wenn die Konfiguration leer ist, gibt es keinen OEM-Dienst und es wird kein Dienst gestartet. Die Komponente muss OemCarService erweitern.
Der Autoaudiodienst muss die APIs zum Abrufen des OEM-Dienstes für die Autoaudiowiedergabe überschreiben:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Beispiel: Sehen Sie sich die Referenztest-App an, die in packages/services/Car/tests/OemCarServiceTestApp definiert ist.
Auch wenn der Dienst vom Autodienst gestartet wird, werden ihm nicht automatisch die Berechtigungen für den Autoaudiodienst vererbt. Daher sollten alle Berechtigungen, die von OEM-Diensten benötigt werden, mit dem entsprechenden Mechanismus abgerufen werden. Beispiel: packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml.
Autoaudiodienst mit OEM-Dienstarchitektur
In AAOS werden die folgenden Aktionen vom Autoaudiodienst verwaltet:
- Audio routing
- Audiofokus
- Audio-Ducking
- Lautstärke und Stummschalten
Vor Android 14 war dieses Verhalten weitgehend statisch und konnte nur in sehr begrenzten Fällen über die Einstellungen geändert werden. In Android 14 wurde ein Mechanismus für den Autoaudiodienst eingeführt, mit dem eine vom OEM definierte Komponente für Folgendes kommuniziert:
- Audiofokus
- Audio-Ducking
- Lautstärke und Stummschalten
Die folgende Abbildung zeigt eine vereinfachte Architektur für den Autoaudiodienst und den OEM-Dienst für Autos. Der Audiodienst für das Auto definiert verschiedene Hooks, die den Audiodienst des OEMs des Autos aufrufen können, um das Audioverhalten zu verwalten. Letzteres ist nur der Fall, wenn die entsprechende OEM-Komponente für den Autoaudiodienst definiert ist. Andernfalls verwendet der Autoaudiodienst das Standardverhalten.
Damit der Audiodienst des Autos und der Audiodienst des Autoherstellers immer synchron sind, gibt der Audiodienst des Autos bei jedem Aufruf die erforderlichen Teile des aktuellen Status des Audiostacks an den Audiodienst des Autoherstellers weiter. Wenn der Audiodienst des Autos beispielsweise eine Anfrage zur Bewertung des Audiofokus abfängt, übergibt er den aktuellen Status des Stacks an den Audiodienst des OEMs des Autos. Der aktuelle Status umfasst den aktuellen Fokusinhaber und die aktuellen Fokusempfänger. Anfragen, die den Fokus verloren haben, sind Anfragen, die noch Teil des Stapels sind, aber vorübergehend nicht mehr den Fokus haben.
Der Autoaudiodienst muss alle Audioaktivitäten im Auto verwalten. Wenn der Audiodienst des Autos einige Teile des Audioverhaltens nicht verwaltet, sind die Informationen, die für den Audiodienst des OEMs des Autos freigegeben werden, unvollständig. Wenn ein OEM beispielsweise die Audiofokus-Verarbeitung im Autodienst überschreibt, indem er seine eigene Audiofokus-Richtlinie registriert, kann der Autoaudiodienst dem Audiodienst des OEMs keine vollständigen Informationen zur Verfügung stellen. Dies kann sich auf die Fähigkeit des Audiodiensts des Fahrzeugherstellers auswirken, Entscheidungen zu treffen, da ihm möglicherweise Informationen fehlen, die für den Audiodienst des Fahrzeugs nicht sichtbar sind.
Um Maßnahmen zu ergreifen, ruft der Autoaudiodienst die OEM-Autodienste auf. Diese Aufrufe erfolgen prozessübergreifend, was eine interprozedurale Kommunikation (Inter-Process Communication, IPC) erfordert. IPC erhöht die Latenz jedes Aufrufs. Es ist wichtig, die Latenz im OEM-Dienst zu minimieren.
Da Aufrufe des Autoaudiodienstes an den OEM-Dienst blockiert werden, sollte der OEM-Dienst den Autoaudiodienst nicht bei direkten API-Bewertungen aufrufen. Stattdessen stellt der Audiodienst für das Auto die erforderlichen Informationen bereit, sodass Aufrufe zwischen den beiden Prozessen nur in eine Richtung erfolgen müssen.
OEM-Definitionen für Auto-Audiodienste
OEM-Audiofokusdienst für Autos
Der Autoaudiodienst verwaltet Audiofokusanfragen von Apps, indem er einen Audiorichtlinien-Fokus-Listener registriert. Der Autoaudiodienst hat einen Mechanismus zum Verwalten des Fokusverhaltens basierend auf einer statischen Interaktionsmatrix. Die Matrix definiert drei verschiedene Arten von Interaktionen:
Parallele Interaktion Personen, die den Fokus halten, können gleichzeitig den Fokus beibehalten.
Exklusive Interaktionen: Durch eine eingehende Fokusanfrage wird der Fokus vom aktuellen Fokusinhaber entfernt.
Interaktion ablehnen Eingehende Fokusanfrage wurde aufgrund des aktuellen Fokusinhabers abgelehnt.
Das reicht zwar für einige Anwendungsfälle in der Automobilbranche aus, erfüllt aber nicht alle Interaktionsanforderungen, die sich aufgrund von OEM-Anforderungen unterscheiden können. Dazu führen wir die OemCarAudioFocusService ein:
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
Die API evaluateAudioFocusRequest wird vom Autoaudiodienst immer dann aufgerufen, wenn eine Anfrage für den Audiofokus ausgewertet werden muss. Es handelt sich um eine bidirektionale API, die blockiert, bis die Ergebnisse zurückgegeben werden. Die Anfrage enthält Informationen zum aktuellen Status des Audiostacks:
Anhand dieser Informationen können Sie die newFocusRequest im Vergleich zu den aktuellen Fokusinhabern in focusHolders und den aktuellen Fokusverlierern in focusLosers bewerten. Die API sollte die folgenden Ergebnisse zurückgeben:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
Hier finden Sie die Informationen zu den tatsächlichen Bewertungsergebnissen in audioFocusEvaluationResults. Sie geben an, ob die aktuelle Anfrage gewährt, verzögert oder fehlgeschlagen ist. Alle Änderungen am aktuellen Fokusstapel sollten je nach Art der Stapeländerung in den Einträgen newLosers und newlyBlocked festgelegt werden.
Die newLosers enthält Einträge, die zuvor den Fokus hatten, ihn aber jetzt verlieren sollen, entweder dauerhaft oder vorübergehend. Elemente, die dauerhaft den Fokus verlieren, werden aus dem Audiofokus-Stack entfernt. Elemente, die vorübergehend den Fokus verlieren, werden in den aktuellen Stack der Elemente verschoben, die den Fokus verloren haben, bis sie den Fokus wiedererlangen oder vom ursprünglichen Fokusanfragenden aufgegeben werden. Unabhängig davon erhält der Fokus-Listener für die Anfragen eine entsprechende Benachrichtigung, dass der Fokus verloren gegangen ist.
Die Liste newlyBlocked enthält Einträge, die zuvor in der Liste der Verlierer des Fokus waren, jetzt aber durch den neuen Eintrag blockiert werden. Die Blockierung kann dauerhaft oder vorübergehend sein. Bei einer dauerhaften Blockierung 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 Stapel der Fokusverlierer, aber der Liste der Fokusblocker wird ein neuer Fokusblocker hinzugefügt. Es wird kein Fokusverlust gesendet, da bereits einer gesendet wurde, als die Blockierung zum ersten Mal erfolgte. Die Anfrage wird schließlich entsperrt, wenn alle aktuellen Blockierungen entfernt wurden, oder sie wird aus dem Stack entfernt, wenn der Fokus aufgehoben wird.
Die zweite API, notifyAudioFocusChange, ist eine Einweg-API, die bei jeder Audiofokusanfrage oder -aufgabe aufgerufen wird. Die API wird hauptsächlich verwendet, um den OEM-Dienst über Fokusänderungen zu informieren, die sich auf das Verhalten des OEM-Autoaudiodienstes auswirken können.
Leitlinien für die Fokusbewertung
In AAOS wird der Audiofokus verwendet, um die Audiowiedergabe zu verwalten und zu bestimmen, welche App verwendet werden soll, um dem Nutzer eine optimale Nutzung zu ermöglichen. Daher sollte der OEM-Plug-in-Dienst beim Verwalten einer Anfrage für den Audiofokus Folgendes berücksichtigen:
Wenn kein Audiofokus mit hoher Priorität aktiv ist (z. B. ein Telefonanruf, ein Notfall oder eine Sicherheitsfunktion), sollten Apps den Audiofokus entweder vorübergehend oder dauerhaft erhalten können.
Wenn ein Medienfokus aktiv ist, dürfen Apps Folgendes nicht anfordern:
Der Fokus der Anrufnutzung sollte entweder gleichzeitig oder ausschließlich möglich sein.
Der Navigationsfokus sollte entweder gleichzeitig oder ausschließlich fokussiert werden können.
Die Nutzung von Assistant sollte entweder gleichzeitig oder ausschließlich möglich sein.
Wenn Apps mit dauerhafter Audiofokus-Priorität (z. B. Telefonanrufe, Notfallwarnungen oder Sicherheitswarnungen) aktiv sind, sollte jede eingehende Anfrage für den verzögerten Audiofokus entweder gewährt oder bei Bedarf verzögert werden.
Die oben genannten Vorschläge sind nicht vollständig, können aber dazu beitragen, dass Apps, die den Fokus anfordern, den Fokus erhalten, wenn keine Töne mit hoher Priorität aktiv sind. Auch wenn Töne mit hoher Priorität aktiv sind, sollten verzögerte Fokusanfragen berücksichtigt werden und der Fokus sollte auf das Gerät gerichtet werden, sobald der Ton mit hoher Priorität stoppt.
OEM-Lautstärkedienst für Autos
Der Autoaudiodienst verwaltet Lautstärketasten-Ereignisse, indem er entweder Lautstärkeanpassungen des Audiosystems oder Lautstärketasten-Ereignisse direkt vom Eingabedienst des Autos überwacht. In jedem Fall bestimmt der Audiodienst des Autos standardmäßig anhand der aktiven Audioplayer und einer Prioritätsliste für den Audiokontext, welche Lautstärkegruppe geändert werden soll.
Wir stellen zwei Listen mit Prioritäten für das Antragsvolumen bereit. In der ersten Liste werden alle Audiokontexte in dieser Reihenfolge berücksichtigt. Die Liste wird in absteigender Reihenfolge angezeigt, wobei die höchste Priorität oben und die niedrigste Priorität unten steht. Wenn beispielsweise Navigationsaudio und Musikaudio gleichzeitig aktiv sind, wird die Navigationslautstärke während eines Lautstärkeereignisses geändert.
- Navigation
- Anruf
- Musik
- Mitteilung
- Sprachbefehl
- Bei Anruf klingeln
- Systemton
- Sicherheit
- Wecker
- Benachrichtigung
- Bewegungszustand
- Notfall
Um die Verwaltung von Lautstärketasten-Ereignissen zu vereinfachen, hat der Autoaudiodienst eine zweite Prioritätsliste für den Audiokontext:
- Anruf
- Medien
- Mitteilung
- Sprachbefehl
Diese Liste wird ebenfalls in absteigender Reihenfolge angezeigt. Mit dieser zweiten Liste können häufiger verwendete Töne über Schlüsselereignisse geändert werden. Seltene Töne, z. B. mit 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 festgelegt werden (2 ist die Standardeinstellung).
Um die Speicherverwaltung flexibler zu gestalten, wird in Android 14 OemCarAudioVolumeService eingeführt:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
Der OEM-Dienst zur Lautstärkeregelung der Autoaudioanlage hat eine einzige Methode, die eine volumeAdjustment und eine OemCarAudioVolumeRequest annimmt:
class OemCarAudioVolumeRequest {
int audioZoneId;
int callState;
List<AudioAttributes> activePlaybackAttributes;
List<AudioAttributes> duckedAttributes;
List<CarVolumeGroupInfo> volumeGroupState;
}
Die activePlaybackAttributes der Anfrage enthält die aktiven Audioattribute. Die duckedAttributes sind alle derzeit geduckten Audioattribute. Die volumeGroupState enthält den aktuellen Status der Volumegruppe. Die Anfrage stellt den aktuellen Status des Audiostacks dar und kann verwendet werden, um zu ermitteln, welche Lautstärkegruppe geändert werden soll. Die Ergebnisse sollten in OemCarVolumeChangeInfo zurückgegeben werden:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
Der boolesche Wert change gibt an, ob sich die Lautstärke geändert hat. true gibt an, dass eine Änderung vorliegt und die Lautstärkegruppe aktualisiert werden sollte. volumeGroupChanged ist die tatsächliche Volumegruppe, 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 angeben, dass die Lautstärkegruppe für die Navigation stummgeschaltet werden soll, ist der boolesche Wert true und die zurückgegebene Lautstärkegruppe sollte die für die Navigation sein.
OEM-Dienst für Auto-Ducking
Der Autoaudiodienst verwaltet die Audioducking-Funktion, indem er Änderungen des Audiofokus überwacht und ein Signal an die AudioControl HAL sendet, um anzugeben, welche Audiogeräte gedämpft werden sollen.
Wenn sich der Fokus ändert, werden alle aktiven Elemente mit Fokus anhand dieser Regeln für die statische Stummschaltung bewertet, um zu ermitteln, welche Elemente stummgeschaltet werden sollen:
- Notfalltöne übertönen alle Töne außer Anruftönen
- Der Modus „Sicherheit“ unterdrückt alle Töne außer Notsignalen.
- Bei der Navigation werden alle Töne außer Sicherheits- und Notruftönen stummgeschaltet.
- „Lautlos“ deaktiviert alle Töne außer Sicherheits-, Notruf- und Navigationstönen
- Klingeltöne für Anrufe von Sprachenten
- Musik und Ansagen sollten von allem überdeckt werden
Diese Regeln sind nicht vollständig. OEMs sind weiterhin dafür verantwortlich, anhand dieser Richtlinien zu bestimmen, wie Töne unterdrückt werden sollen. OEMs können diese Empfehlungen basierend auf den verfügbaren Anforderungen aktiver steuern. Die OemCarDuckingService wird in Android 14 eingeführt:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
Diese API wird vom Audiodienst des Autos aufgerufen, wenn sich der Audiofokus ändert. Dabei wird die OemCarAudioVolumeRequest verwendet, die im OEM-Autovolumendienst eingeführt wurde. Sie enthält die relevanten Informationen, um zu entscheiden, welche Attribute unterdrückt werden sollen. Die Liste der Audioattribute, die über die API stummgeschaltet werden sollen, wird mit dem aktuellen Audiostatus verglichen:
Audioattribut, das derzeit gedimmt ist:
- Auf der Liste, wird weiterhin ausgeblendet
- Nicht auf der Liste, Ducking deaktiviert
Audioattribut wird derzeit nicht gedimmt:
- Auf der Liste, minimiert
- Nicht auf der Liste, Ducking deaktiviert
Der Audiodienst für das Auto ermittelt dann, zu welchen Audioausgabegeräten die Audioattribute gehören, und fügt sie der Liste der Audioausgabegeräte mit gedimmtem Ton bzw. der Liste der Audioausgabegeräte mit normalem Ton hinzu. Diese Informationen werden schließlich an die AudioControl HAL gesendet, um die erforderliche Unterdrückung auf Hardwareebene durchzuführen.
Die folgende Abbildung zeigt ein vereinfachtes Sequenzdiagramm der Audio-Ducking-Steuerung für eine Fokusanfrage, wenn der OEM-Ducking-Dienst verwendet wird:
Die Abfolge beginnt, wenn eine App über öffentliche Audiomanager-APIs Audiofokus verwalten anfordert. Die Anfrage wird an den Audiodienst des Autos weitergeleitet, um die Ergebnisse zu ermitteln. Wenn der Audiofokus festgelegt wird, wird die Audioducking-Funktion vom Autoaudiodienst ausgewertet, der OemCarAudioDuckingService aufruft, um zu bestimmen, welche Audioattribute gedämpft werden sollen. Sobald die Ergebnisse von der evaluateAttributesToDuck API zurückgegeben wurden, werden die Audiogeräte berechnet, die stummgeschaltet werden sollen. Die Informationen werden dann an die AudioControl gesendet, um die Audiohardware zu stummschalten.
Referenzimplementierung für OEM-Autoaudiodienste
AAOS bietet eine Referenzimplementierung des OEM-Autodienstes in packages/services/Car/tests/OemCarServiceTestApp, die OemCarService, OemCarAudioFocusService, OemCarAudioDuckingService und OemCarAudioVolumeService implementiert. Bei letzterem verwendet jeder Dienst eine XML-Datei, um ein statisches Verhalten zu laden. Beispiel: OemCarAudioFocusServiceImp lädt den oem_focus_config.xml, der eine Interaktionsmatrix enthält. Die Matrix wird verwendet, um die Fokusanfrage zu bewerten, wenn evaluateAudioFocusRequest aufgerufen wird.
Referenz für das Debuggen der Test-App
Die Test-App für den OEM-Autodienst ist Teil des AOSP-Quellcodes. OEMs können Änderungen nach Bedarf vornehmen. Verwenden Sie für die Fehlerbehebung die config_oemCarService-Konfiguration, 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>
So prüfen Sie, ob der OEM-Autodienst den Befehl dump für den OEM-Dienst verwendet:
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
Jedes Boolesche Element in jeder Batch-Datei mit dump-Informationen gibt den Status der Funktion und des Dienstes an. Die Dump-Informationen mIsOemServiceReady geben beispielsweise an, ob der Dienst einsatzbereit ist. true bedeutet, dass er einsatzbereit ist, und false, dass er es nicht ist.