Gerätetyplimit

Bei Android-Audioinhalten wird audio_devices_t für den Audiogerätetyp verwendet. Es ist im Audioquellcode weit verbreitet als Bitfeld zum Filtern oder Auswählen eines oder mehrerer angegebenen Geräten. Vor Android 11 gab es ein Limit von 30 Audioeingabe- und -ausgabegeräte und keine freien Steckplätze für neue Audiogerätetypen. Wir haben Das Limit für die Anzahl der zulässigen Audiogerätetypen wurde entfernt neue Audiogerätetypen hinzugefügt werden.

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 ist wird weiterhin zur Unterscheidung von Eingabe- und Ausgabegeräten verwendet. Wenn Sie neue Audiogerätetypen hinzufügen, in den Lücken zwischen vorhandenen Werten Werte angeben.

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_t zur Darstellung mehrerer Audiogeräte.
  • Es wird geprüft, ob der Wert audio_devices_t Audiogerätetypen enthält aus einer bestimmten Kategorie stammen.

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 wird im Feld "vendor-available" libaudiofoundation. Um zu repräsentieren, mehrere Audiodateien Gerätetypen in C-Code, ein Array oder eine Liste mit audio_devices_t kann 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.

  1. Entferne alle gespeicherten Geräte auf einem Bitfeld.

    audio_devices_t sollte nicht für mehrere Audiogeräte verwendet werden Typen. Verwenden Sie stattdessen eine Liste oder einen Vektor.

  2. Verwenden Sie keine Bitvorgänge für Gerätetypen-Vergleiche.

    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 eine Audiogerätetyp und 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).

  3. Verwenden Sie vordefinierte Werte nicht mehr für Gruppen von Audiogerätetypen.

    Es gibt vordefinierte Werte für Gruppen von Audiogerätetypen, AUDIO_DEVICE_OUT_ALL, in system/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. Es gibt neue Gruppen von Audiogerätetypen, die in audio-base-utils.h sind Arrays von Audiogerätetypen, z. B. AUDIO_DEVICE_OUT_ALL_ARRAY.

  4. Implementieren Sie die Methoden create_audio_patch() und release_audio_patch() für das Routing anstelle von set_parameters.

    Bei der Methode set_parameters werden Audiogerätetypen als Bitfeld verwendet. unerwartete Ergebnisse, wenn neue aufgelistete Audiogerätetypen hinzugefügt werden.

    Derzeit sind zwei Arten von Audio-Patches erforderlich:

    • Mix auf Geräte-Patches zur 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 das Patch-Handle beim Erstellen eines Audio-Patches ist der Audio-HAL erforderlich, um einen eindeutigen Patch-Handle zu generieren, um das Audiofeld zu identifizieren. Andernfalls sollte die Audio-HAL den angegebenen Audio-Patch-Handle verwenden, um den Audio-Patch zu aktualisieren.

    Wenn Sie einen älteren Audio-HAL und den AOSP HIDL-Wrapper verwenden, sollte der Legacy-Audio-HAL Folgendes festlegen: HAL-Hauptversion auf 3.0.

    Um die Audio-Patch-Funktion zu aktivieren, sollte 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 können einen Gerätetyp mit einem einzelnen Bit-Set darstellen, sodass aktuelle HAL-Implementierungen noch funktionieren.

Wenn neue Audiogerätetypen hinzugefügt werden und die OEMs sie verwenden möchten, müssen ihre Audio-HAL-Implementierung aktualisieren und zu HIDL Version 6.0 oder höher wechseln. Es ist erforderlich, um die HAL-Hauptversion auf 3.0 zu aktualisieren und die create_audio_patch- und release_audio_patch-Methoden, weil die Verwendung von set_parameters zum Weiterleiten des Streams kann zu unerwarteten Ergebnissen führen, wenn neue Audiogerätetypen hinzugefügt.

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.