In Android-Audio wird audio_devices_t für den Audiogerätetyp verwendet. Es wird häufig im Audio-Quellcode als Bitfeld verwendet, um ein oder mehrere angegebene Geräte zu filtern oder auszuwählen. Vor Android 11 gab es ein Limit von 30 Gerätetypen für Audioein-/-ausgänge und keine freien Slots, um neue Audiogerätetypen hinzuzufügen. Wir haben die Beschränkung der Anzahl der Audiogerätetypen aufgehoben, damit neue Audiogerätetypen hinzugefügt werden können.
Um die Beschränkung der Anzahl der Audiogerätetypen aufzuheben, werden Audiogerätetypen jetzt als aufgezählte Werte anstelle von Bitmasken angegeben.
Alle vorhandenen Audiogerätetypen bleiben unverändert. AUDIO_DEVICE_BIT_IN wird weiterhin verwendet, um Eingabe- oder Ausgabegeräte zu unterscheiden. Wenn Sie neue Audiogerätetypen hinzufügen, werden sie in den Lücken zwischen den vorhandenen Werten aufgezählt.
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.
- Der Wert
audio_devices_twird verwendet, um mehrere Audiogeräte darzustellen. - Prüfen, ob der Wert von
audio_devices_tAudiogerätetypen aus einer bestimmten Kategorie enthält
Um mehrere Audiogerätetypen darzustellen, wird in
/libaudiofoundation/include/media/AudioContainers.h die Klasse DeviceTypeSet verwendet, ein std::set-Container von audio_devices_t. Die Klasse wird in der vom Anbieter bereitgestellten Bibliothek
libaudiofoundation deklariert. Um mehrere Audiogerätetypen in 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 zu einer bestimmten Kategorie gehört, verwenden Sie die Hilfsfunktionen audio_is_.*_device in
/system/media/audio/include/system/audio.h.
Wenn mehrere Audiogerätetypen unterstützt werden sollen, verwende die 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 Bitfelddarstellung des Audiogerätetyps aus der Audio-HAL-Implementierung entfernen.
- Entfernen Sie den gesamten Speicher 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 Bitvorgänge mehr für Vergleiche von Gerätetypen.
Vor Android 11 können Audiogerätetypen als Bitfeld verwendet werden. In diesem Fall werden häufig Bitvorgänge für Vergleiche von Gerätetypen verwendet. Wenn neue, aufgezählte Audiogerätetypen hinzugefügt werden, können die Bitvorgänge 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 du prüfen möchtest, ob ein Audiogerätetyp zu einer bestimmten Kategorie gehört, verwende die 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 nicht mehr verwenden
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 korrekt sind, wenn neue Audiogerätetypen hinzugefügt werden. Inaudio-base-utils.hsind neue Gruppen von Audiogerätetypen definiert, die Arrays von Audiogerätetypen sind, z. B.AUDIO_DEVICE_OUT_ALL_ARRAY. - 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. Daher können unerwartete Ergebnisse auftreten, wenn neue aufgezählte Audiogerätetypen hinzugefügt werden.Derzeit sind zwei Arten von Audio-Patches erforderlich:
- Mix to Device-Patches für die Wiedergabe
- Gerät zum Mischen von Patches, zur Aufnahme
Bei nachfolgenden Updates sind möglicherweise zusätzliche Patches für die Gerätekommunikation erforderlich.
Wenn beim Erstellen eines Audio-Patches der Patch-Handle nicht angegeben ist, muss die Audio-HAL einen eindeutigen Patch-Handle generieren, mit dem der Audio-Patch identifiziert werden kann. Andernfalls sollte die Audio-HAL den angegebenen Audio-Patch-Handle verwenden, um den Audio-Patch zu aktualisieren.
Wenn Sie ein älteres Audio-HAL und den AOSP-HIDL-Wrapper verwenden, sollte das ältere Audio-HAL die Hauptversion des HAL auf 3.0 festlegen.
Um die Audio-Patch-Funktion zu aktivieren, muss die HAL-Hauptversion in der Audio-HAL auf 3.0 oder höher festgelegt sein. Weitere Informationen finden Sie unter
Device::supportsAudioPatches()in der Standard-HIDL-Implementierung. Sie können sich auch die Audio-HAL für Cuttlefish ansehen.
Personalisierung
Es ist nicht möglich, die Funktion zu deaktivieren oder die Refaktorisierung von Audiogeräten im Framework rückgängig zu machen, die das Hinzufügen von Audiogerätetypen ermöglicht.
Alle hinzugefügten Audiogerätetypen ermöglichen die Darstellung eines Gerätetyps mit einem einzelnen Bit, sodass aktuelle HAL-Implementierungen weiterhin funktionieren.
Wenn neue Audiogerätetypen hinzugefügt werden und OEMs diese verwenden möchten, müssen sie ihre Audio-HAL-Implementierung aktualisieren und auf HIDL-Version 6.0 oder höher umstellen. Sie müssen die Hauptversion der HAL auf 3.0 aktualisieren und die Methoden create_audio_patch und release_audio_patch 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 die Audio-HAL können Sie prüfen, ob die Implementierung wie vorgesehen funktioniert. Alle Tests finden Sie in den VTS-Dateien.