Beschränkung des Gerätetyps

In Android Audio, audio_devices_t wird verwendet , um den Audio-Gerätetyp zu repräsentieren. Es wird häufig im Audioquellcode als Bitfeld verwendet, um ein oder mehrere bestimmte Geräte zu filtern oder auszuwählen. Vor Android 11 gab es ein Limit von 30 Audio-Ein-/Ausgabegerätetypen und keine freien Steckplätze, 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 von Audiogerätetypen aufzuheben, sind Audiogerätetypen jetzt Aufzählungswerte anstelle von Bitmasken.

Alle vorhandenen Audiogerätetypen bleiben unverändert. AUDIO_DEVICE_BIT_IN noch verwendet Geräte Ein- oder Ausgang zu unterscheiden. Beim Hinzufügen neuer Audiogerätetypen handelt es sich um Aufzählungswerte in den Lücken zwischen vorhandenen Werten.

OEMs sollten nicht verwenden audio_devices_t als Bitmaske, weil das zu unerwarteten Ergebnissen führen kann , wenn neue Aufzählungsaudiogerätetypen hinzugefügt werden.

Beispiele und Quelle

Vor Android 11 gab es zwei typische Verwendungen von Audiogerätetypen als Bitmasken.

  • Mit Hilfe des audio_devices_t Wert mehr Audiogeräte repräsentieren.
  • Prüfen , ob der audio_devices_t Wert Audiogerätetypen aus einer bestimmten Kategorie enthält.

Um mehr Audio-Gerätetypen, eine Klasse mit dem Namen zu repräsentieren DeviceTypeSet im /libaudiofoundation/include/media/AudioContainers.h verwendet wird , das ist ein std::set Behälter audio_devices_t . Die Klasse wird im hersteller verfügbar erklärt libaudiofoundation Bibliothek. Um mehrere Audiogerätetypen in C - Code, ein Array oder eine Liste der repräsentieren audio_devices_t verwendet werden.

Um zu überprüfen , ob ein einzelner Gerätetyp einer bestimmte Kategorie ist, verwenden Sie Hilfsfunktionen audio_is_.*_device in /system/media/audio/include/system/audio.h . Für mehr Audio - Gerätetypen Fall verwenden Helferfunktionen in libaudiofoundation . Verwenden Sie zum Beispiel areAllOfSameDeviceType (DeviceTypeSet, std::function ) areAllOfSameDeviceType (DeviceTypeSet, std::function ) In AudioContainers.h zu überprüfen , ob alle gegebenen Audio-Gerätetypen des gleichen Typs sind.

Implementierung

OEMs müssen die Bitfelddarstellung des Audiogerätetyps aus der Audio-HAL-Implementierung entfernen.

  1. Entfernen Sie den gesamten Speicher von Geräten in einem Bitfeld.

    audio_devices_t sollte nicht mehrere Audio - Gerät zu repräsentieren Typen verwendet werden. Verwenden Sie stattdessen eine Liste oder einen Vektor.

  2. Stoppen Sie die Verwendung von Bitoperationen für Gerätetypvergleiche.

    Vor Android 11 können Audiogerätetypen als Bitfeld verwendet werden. In diesem Fall ist es üblich, Bitoperationen für Vergleiche von Gerätetypen zu verwenden. Wenn neue, aufgezählte Audiogerätetypen hinzugefügt werden, können die Bitoperationen zu unerwarteten Ergebnissen führen. Verwenden Sie stattdessen als Alternative Hilfsfunktionen. Wenn es einen einzelnen Audiogerätetyp gibt, verwenden Sie den direkten Vergleich, um die beiden Werte zu vergleichen. Um zu überprüfen , ob eine Audiogerätetyp einer bestimmten Kategorie ist, verwenden Sie Hilfsfunktionen in /system/media/audio/include/system/audio.h . Zum Beispiel audio_is_output_device(audio_devices_t device) .

  3. Beenden Sie die Verwendung vordefinierter Werte für Gruppen von Audiogerätetypen.

    Es gibt einige vordefinierte Werte für die Gruppen von Audio - Gerätetypen, AUDIO_DEVICE_OUT_ALL , in system/media/audio/include/system/audio-base-utils.h . Alle diese Werte sind reserviert, aber möglicherweise veraltet, da sie nicht korrekt sind, wenn neue aufgezählte Audiogerätetypen hinzugefügt werden. Es gibt neue Gruppen von Audio - Gerätetypen definiert in audio-base-utils.h , die Anordnungen von Audiogerätetypen sind, wie AUDIO_DEVICE_OUT_ALL_ARRAY .

  4. Umsetzung der create_audio_patch() und release_audio_patch() Verfahren zur Leitweglenkung anstelle von set_parameters .

    Die set_parameters Methode verwendet Audiogerätetypen als Bitfeld, so kann es zu unerwarteten Ergebnissen, wenn neue Aufzählungsaudiogerä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, zum Aufnehmen

    Bei nachfolgenden Updates sind möglicherweise zusätzliche Patches von Gerät zu Gerät erforderlich.

    Wenn beim Erstellen eines Audio-Patches kein Patch-Handle angegeben ist, ist die Audio-HAL erforderlich, um ein eindeutiges Patch-Handle zu generieren, das das Audio-Patch identifizieren kann. Andernfalls sollte die Audio-HAL das angegebene Audio-Patch-Handle verwenden, um das Audio-Patch zu aktualisieren.

    Wenn Sie eine Legacy-Audio-HAL und den AOSP-HIDL-Wrapper verwenden, sollte die Legacy-Audio-HAL die HAL-Hauptversion auf 3.0 setzen.

    Um die Audio-Patch-Funktion zu aktivieren, sollte die Audio-HAL die Haupt-HAL-Version auf 3.0 oder höher setzen. Siehe Device::supportsAudioPatches() in Standard HIDL Implementierung für weitere Informationen, die auch auf Audio-HAL für Tintenfische zu finden sind.

Anpassung

Es ist nicht möglich, die Funktion zu deaktivieren oder die Audiogeräterefaktorierung 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 Bitsatz, 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 notwendig , die wichtigsten HAL - Version 3.0 und implementieren , um die Upgrade create_audio_patch und release_audio_patch Methoden, weil mit set_parameters zu routen den Strom kann zu unerwarteten Ergebnissen führen , wenn neue Audio-Gerä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 können in den finden VTS - Dateien .