In Android-Audio wird audio_devices_t verwendet, um den Audiogerätetyp darzustellen. Es wird häufig im Audioquellcode als Bitfeld verwendet, um ein oder mehrere angegebene Geräte zu filtern oder auszuwählen. Vor Android 11 gab es ein Limit von 30 Audio-Ein-/Ausgabegerätetypen und keine freien Slots zum Hinzufügen neuer Audiogerätetypen. Wir haben das Limit für die Anzahl der zulässigen Audiogerätetypen entfernt, damit neue Audiogerätetypen hinzugefügt werden können.
Um das Limit für die Anzahl der Audiogerätetypen aufzuheben, sind Audiogerätetypen jetzt aufgezählte Werte anstelle von Bitmasken.
Alle vorhandenen Audiogerätetypen bleiben unverändert. AUDIO_DEVICE_BIT_IN wird weiterhin verwendet, um zwischen Eingabe- und Ausgabegeräten zu unterscheiden. Wenn Sie neue Audiogerätetypen hinzufügen, werden sie als aufgezählte Werte in den Lücken zwischen vorhandenen Werten eingefügt.
OEMs sollten audio_devices_t nicht als Bitmaske verwenden, da dies zu unerwarteten Ergebnissen führen kann, wenn neue aufgezählte Audiogerätetypen hinzugefügt werden.
Beispiele und Quelle
Vor Android 11 gab es zwei typische Verwendungen von Audiogerätetypen als Bitmasken.
- Verwendung des Werts
audio_devices_tzur Darstellung mehrerer Audiogeräte. - Prüfen, ob der
audio_devices_t-Wert Audiogerätetypen aus einer bestimmten Kategorie enthält.
Zur Darstellung mehrerer Audiogerätetypen wird eine Klasse namens DeviceTypeSet im
/libaudiofoundation/include/media/AudioContainers.h verwendet, die ein std::set-Container von audio_devices_t ist. Die Klasse wird in der vom Anbieter verfügbaren Bibliothek
libaudiofoundation deklariert. Um mehrere Audiogerätetypen im C-Code darzustellen, kann ein Array oder eine Liste von audio_devices_t verwendet werden.
Wenn Sie prüfen möchten, ob ein einzelner Gerätetyp einer bestimmten Kategorie angehört, verwenden Sie die Hilfsfunktionen audio_is_.*_device in
/system/media/audio/include/system/audio.h.
Verwenden Sie für mehrere Audiogerätetypen Hilfsfunktionen in libaudiofoundation. Verwenden Sie beispielsweise areAllOfSameDeviceType (DeviceTypeSet, std::function in
AudioContainers.h, um zu prüfen, ob alle angegebenen Audiogerätetypen vom selben Typ sind.
Implementierung
OEMs müssen die Bitfeld-Darstellung des Audiogerätetyps aus der Audio-HAL-Implementierung entfernen.
- Entfernen Sie die gesamte Speicherung von Geräten in einem Bitfeld.
audio_devices_tsollte nicht verwendet werden, um mehrere Audiogerätetypen darzustellen. Verwenden Sie stattdessen eine Liste oder einen Vektor. - Verwenden Sie keine Bit-Operationen mehr für Vergleiche von Gerätetypen.
Vor Android 11 konnten Audiogerätetypen als Bitfeld verwendet werden. In diesem Fall ist es üblich, Bit-Operationen für Vergleiche von Gerätetypen zu verwenden. Wenn neue, aufgezählte Audiogerätetypen hinzugefügt werden, können die Bit-Operationen zu unerwarteten Ergebnissen führen. Verwenden Sie stattdessen Hilfsfunktionen. Wenn es nur einen Audiogerätetyp gibt, verwenden Sie den direkten Vergleich, um die beiden Werte zu vergleichen. Wenn Sie prüfen möchten, ob ein Audiogerätetyp einer bestimmten Kategorie angehört, verwenden Sie Hilfsfunktionen in
/system/media/audio/include/system/audio.h. Beispiel:audio_is_output_device(audio_devices_t device). - Vordefinierte Werte für Gruppen von Audiogerätetypen werden nicht mehr verwendet.
Es gibt einige vordefinierte Werte für Gruppen von Audiogerätetypen,
AUDIO_DEVICE_OUT_ALL, insystem/media/audio/include/system/audio-base-utils.h. Alle diese Werte sind reserviert, werden aber möglicherweise eingestellt, da sie nicht mehr korrekt sind, wenn neue aufgezählte Audiogerätetypen hinzugefügt werden. Inaudio-base-utils.hsind neue Gruppen von Audiogerätetypen definiert, die Arrays von Audiogerätetypen wieAUDIO_DEVICE_OUT_ALL_ARRAYsind. - Implementieren Sie die Methoden
create_audio_patch()undrelease_audio_patch()für das Routing anstelle vonset_parameters.Bei der
set_parameters-Methode werden Audiogerätetypen als Bitfeld verwendet. Wenn also neue aufgezählte Audiogerätetypen hinzugefügt werden, kann es zu unerwarteten Ergebnissen kommen.Derzeit sind zwei Arten von Audio-Patches erforderlich:
- Mix für Geräte-Patches zur Wiedergabe
- Gerät zum Mischen von Patches für die Aufnahme
Bei nachfolgenden Updates sind möglicherweise zusätzliche Patches für die Geräte erforderlich.
Wenn Sie einen Audio-Patch erstellen und das Patch-Handle nicht angegeben ist, muss die Audio-HAL ein eindeutiges Patch-Handle generieren, mit dem der Audio-Patch identifiziert werden kann. Andernfalls sollte der Audio-HAL das angegebene Audio-Patch-Handle verwenden, um den Audio-Patch zu aktualisieren.
Wenn Sie einen alten Audio-HAL und den AOSP-HIDL-Wrapper verwenden, sollte der alte Audio-HAL die Haupt-HAL-Version auf 3.0 festlegen.
Damit die Audio-Patch-Funktion aktiviert werden kann, muss die Audio-HAL die Haupt-HAL-Version auf 3.0 oder höher festlegen. Weitere Informationen finden Sie unter
Device::supportsAudioPatches()in der Standard-HIDL-Implementierung, die auch im Audio-HAL für Cuttlefish verfügbar ist.
Personalisierung
Es ist nicht möglich, die Funktion zu deaktivieren oder das Refactoring des Audiogeräts im Framework rückgängig zu machen, das das Hinzufügen von Audiogerätetypen ermöglicht.
Alle hinzugefügten Audiogerätetypen ermöglichen die Darstellung eines Gerätetyps mit einem einzelnen gesetzten Bit, sodass aktuelle HAL-Implementierungen weiterhin funktionieren.
Wenn neue Audiogerätetypen hinzugefügt werden und OEMs sie verwenden möchten, müssen sie ihre Audio-HAL-Implementierung aktualisieren und auf HIDL-Version 6.0 oder höher umstellen. Es ist zwingend erforderlich, die Haupt-HAL-Version auf 3.0 zu aktualisieren und die Methoden create_audio_patch und release_audio_patch zu implementieren, da die Verwendung von set_parameters zum Weiterleiten des Streams zu unerwarteten Ergebnissen führen kann, wenn neue Audiogerätetypen hinzugefügt werden.
Zertifizierungsstufe
OEMs müssen ihre HAL-Implementierungen aktualisieren. Mit VTS für Audio-HAL kann geprüft werden, ob die Implementierung wie vorgesehen funktioniert. Alle Tests finden Sie in den VTS-Dateien.