In Android-Audio wird audio_devices_t verwendet, um den Audiogerätetyp darzustellen. Es wird häufig im Audio-Quellcode als Bitfeld zum Filtern oder Auswählen eines oder mehrerer bestimmter Geräte verwendet. Vor Android 11 gab es eine Beschränkung auf 30 Audio-Eingabe-/Ausgabegerätetypen und keine freien Steckplätze zum Hinzufügen neuer Audiogerätetypen. Wir haben die Beschränkung der Anzahl der Audiogerätetypen aufgehoben, um das Hinzufügen neuer Audiogerätetypen zu ermöglichen.
Um die Beschränkung der Anzahl der Audiogerätetypen aufzuheben, sind Audiogerätetypen jetzt Aufzählungswerte anstelle von Bitmasken.
Alle vorhandenen Audiogerätetypen bleiben unverändert. AUDIO_DEVICE_BIT_IN wird weiterhin zur Unterscheidung von Eingabe- oder Ausgabegeräten verwendet. Beim Hinzufügen neuer Audiogerätetypen werden diese Werte in den Lücken zwischen vorhandenen Werten aufgelistet.
OEMs sollten audio_devices_t nicht als Bitmaske verwenden, da dies zu unerwarteten Ergebnissen führen kann, wenn neue aufgelistete Audiogerätetypen hinzugefügt werden.
Beispiele und Quelle
Vor Android 11 gab es zwei typische Verwendungen von Audiogerätetypen als Bitmasken.
- Verwenden des
audio_devices_t-Werts zur Darstellung mehrerer Audiogeräte. - Es wird überprüft, ob der
audio_devices_tWert Audiogerätetypen aus einer bestimmten Kategorie enthält.
Um mehrere Audiogerätetypen darzustellen, wird eine Klasse namens DeviceTypeSet in /libaudiofoundation/include/media/AudioContainers.h verwendet, die ein std::set Container von audio_devices_t ist. Die Klasse ist in der vom Anbieter verfügbaren libaudiofoundation Bibliothek deklariert. Um mehrere Audiogerätetypen im C-Code darzustellen, kann ein Array oder eine Liste von audio_devices_t verwendet werden.
Um zu überprüfen, 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 . Bei mehreren Audiogerätetypen verwenden Sie Hilfsfunktionen in libaudiofoundation . Verwenden Sie beispielsweise areAllOfSameDeviceType (DeviceTypeSet, std::function )areAllOfSameDeviceType (DeviceTypeSet, std::function ) in AudioContainers.h , um zu überprüfen, ob alle angegebenen Audiogerätetypen vom gleichen 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 auf einem Bitfeld.
audio_devices_tsollte nicht zur Darstellung mehrerer Audiogerätetypen verwendet werden. Verwenden Sie stattdessen eine Liste oder einen Vektor. - Verwenden Sie keine Bitoperationen mehr für Vergleiche von Gerätetypen.
Vor Android 11 können Audiogerätetypen als Bitfeld verwendet werden. In diesem Fall werden üblicherweise Bitoperationen zum Vergleich von Gerätetypen verwendet. Wenn neue, aufgezählte Audiogerätetypen hinzugefügt werden, können die Bitoperationen zu unerwarteten Ergebnissen führen. Verwenden Sie stattdessen alternativ Hilfsfunktionen. Wenn es einen einzelnen Audiogerätetyp gibt, verwenden Sie den direkten Vergleich, um die beiden Werte zu vergleichen. Um zu überprüfen, ob ein Audiogerätetyp einer bestimmten Kategorie angehört, verwenden Sie Hilfsfunktionen in
/system/media/audio/include/system/audio.h. Zum Beispielaudio_is_output_device(audio_devices_t device). - Hören Sie auf, vordefinierte Werte für Gruppen von Audiogerätetypen zu 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, könnten aber veraltet sein, da sie nicht korrekt sind, wenn neue aufgelistete Audiogerätetypen hinzugefügt werden. Inaudio-base-utils.hsind neue Gruppen von Audiogerätetypen definiert, bei denen es sich um Arrays von Audiogerätetypen handelt, z. B.AUDIO_DEVICE_OUT_ALL_ARRAY. - Implementieren Sie die Methoden
create_audio_patch()undrelease_audio_patch()für das Routing anstelle vonset_parameters.Die
set_parametersMethode verwendet Audiogerätetypen als Bitfeld, daher kann es zu unerwarteten Ergebnissen kommen, wenn neue aufgelistete Audiogerätetypen hinzugefügt werden.Derzeit sind zwei Arten von Audio-Patches erforderlich:
- Zur Wiedergabe mit Geräte-Patches mischen
- Gerät zum Mischen von Patches für die Aufnahme
In nachfolgenden Updates sind möglicherweise zusätzliche Patches für Gerät für Gerät erforderlich.
Wenn beim Erstellen eines Audio-Patches das Patch-Handle nicht angegeben ist, ist die Audio-HAL erforderlich, um ein eindeutiges Patch-Handle zu generieren, das den Audio-Patch identifizieren kann. Andernfalls sollte die Audio-HAL das angegebene Audio-Patch-Handle verwenden, um den Audio-Patch zu aktualisieren.
Wenn Sie eine ältere Audio-HAL und den AOSP HIDL-Wrapper verwenden, sollte die ältere Audio-HAL die Haupt-HAL-Version auf 3.0 setzen.
Um die Audio-Patch-Funktion zu aktivieren, sollte der Audio-HAL die Haupt-HAL-Version auf 3.0 oder höher setzen. Weitere Informationen finden Sie unter
Device::supportsAudioPatches()in der Standard-HIDL-Implementierung , die auch im Audio-HAL für Cuttlefish zu finden ist.
Anpassung
Es ist nicht möglich, die Funktion zu deaktivieren oder die Umgestaltung 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 einzigen gesetzten 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 umsteigen. Es ist zwingend erforderlich, die Hauptversion von HAL auf 3.0 zu aktualisieren und die Methoden create_audio_patch und release_audio_patch “ zu implementieren, da die Verwendung set_parameters zum Weiterleiten des Streams zu unerwarteten Ergebnissen führen kann, wenn neue Audiogerätetypen hinzugefügt werden.
Validierung
Die erforderliche Arbeit für OEMs besteht darin, ihre HAL-Implementierungen zu aktualisieren. VTS für Audio-HAL kann verwendet werden, um zu überprüfen, ob die Implementierung wie beabsichtigt funktioniert. Alle Tests sind in den VTS-Dateien zu finden.