Limite di tipo di dispositivo

Nell'audio di Android, audio_devices_t viene utilizzato per rappresentare il tipo di dispositivo audio. È ampiamente utilizzato nel codice sorgente audio come campo di bit per filtrare o selezionare uno o più dispositivi specificati. Prima di Android 11, era previsto un limite di 30 tipi di dispositivi di input/output audio e non erano disponibili slot aggiuntivi per aggiungere nuovi tipi di dispositivi audio. Abbiamo rimosso il limite al numero di tipi di dispositivi audio per consentire l'aggiunta di nuovi tipi di dispositivi audio.

Per rimuovere il limite al numero di tipi di dispositivi audio, ora i tipi di dispositivi audio sono valori enumerati anziché maschere di bit.

Tutti i tipi di dispositivi audio esistenti vengono mantenuti invariati. AUDIO_DEVICE_BIT_IN viene ancora utilizzato per distinguere i dispositivi di input o output. Quando vengono aggiunti nuovi tipi di dispositivi audio, questi vengono enumerati nei valori intermedi tra quelli esistenti.

Gli OEM non devono utilizzare audio_devices_t come maschera di bit, perché ciò può causare risultati imprevisti quando vengono aggiunti nuovi tipi di dispositivi audio enumerati.

Esempi e origine

Prima di Android 11, esistevano due utilizzi tipici dei tipi di dispositivi audio come maschere di bit.

  • Utilizzo del valore audio_devices_t per rappresentare più dispositivi audio.
  • Verifica se il valore audio_devices_t contiene tipi di dispositivi audio di una categoria specifica.

Per rappresentare più tipi di dispositivi audio, viene utilizzata una classe denominata DeviceTypeSet in /libaudiofoundation/include/media/AudioContainers.h che è un contenitore std::set di audio_devices_t. La classe è dichiarata nella libreria libaudiofoundation disponibile per i fornitori. Per rappresentare più tipi di dispositivi audio nel codice C, è possibile utilizzare un array o un elenco di audio_devices_t.

Per verificare se un singolo tipo di dispositivo appartiene a una categoria specifica, utilizza le funzioni di assistenza audio_is_.*_device in /system/media/audio/include/system/audio.h. Per il caso di più tipi di dispositivi audio, utilizza le funzioni di assistenza in libaudiofoundation. Ad esempio, utilizza areAllOfSameDeviceType (DeviceTypeSet, std::function) in AudioContainers.h per verificare se tutti i tipi di dispositivi audio forniti sono dello stesso tipo.

Implementazione

Gli OEM devono rimuovere la rappresentazione del campo di bit del tipo di dispositivo audio dall'implementazione HAL audio.

  1. Rimuovi tutta la memorizzazione dei dispositivi in un campo di bit.

    audio_devices_t non deve essere utilizzato per rappresentare più tipi di dispositivi audio. Utilizza invece un elenco o un vettore.

  2. Interrompi l'utilizzo delle operazioni bit a bit per i confronti tra tipi di dispositivi.

    Prima di Android 11, i tipi di dispositivi audio possono essere utilizzati come bitfield. In questo caso, è comune utilizzare operazioni bit a bit per i confronti dei tipi di dispositivo. Quando vengono aggiunti nuovi tipi di dispositivi audio enumerati, le operazioni bitwise potrebbero causare risultati imprevisti. Utilizza invece le funzioni di assistenza come alternativa. Se esiste un solo tipo di dispositivo audio, utilizza il confronto diretto per confrontare i due valori. Per verificare se un tipo di dispositivo audio appartiene a una categoria specifica, utilizza le funzioni di assistenza in /system/media/audio/include/system/audio.h. Ad esempio, audio_is_output_device(audio_devices_t device).

  3. Interrompi l'utilizzo di valori predefiniti per i gruppi di tipi di dispositivi audio.

    Esistono alcuni valori predefiniti per i gruppi di tipi di dispositivi audio, AUDIO_DEVICE_OUT_ALL, in system/media/audio/include/system/audio-base-utils.h. Tutti questi valori sono riservati, ma potrebbero essere ritirati perché non saranno corretti quando verranno aggiunti nuovi tipi di dispositivi audio enumerati. Sono stati definiti nuovi gruppi di tipi di dispositivi audio in audio-base-utils.h, che sono array di tipi di dispositivi audio, ad esempio AUDIO_DEVICE_OUT_ALL_ARRAY.

  4. Implementa i metodi create_audio_patch() e release_audio_patch() per il routing anziché set_parameters.

    Il metodo set_parameters utilizza i tipi di dispositivi audio come bitfield, quindi potrebbero verificarsi risultati imprevisti se vengono aggiunti nuovi tipi di dispositivi audio enumerati.

    Al momento, sono necessari due tipi di patch audio:

    • Mixare le patch del dispositivo per la riproduzione
    • Dispositivo per mixare le patch, per la registrazione

    Negli aggiornamenti successivi, potrebbero essere necessarie patch aggiuntive per il dispositivo.

    Quando crei una patch audio, se l'handle della patch non è specificato, l'HAL audio deve generare un handle della patch univoco che possa identificare la patch audio. In caso contrario, l'HAL audio deve utilizzare l'handle della patch audio specificato per aggiornare la patch audio.

    Se utilizzi un HAL audio legacy e il wrapper HIDL AOSP, l'HAL audio legacy deve impostare la versione principale dell'HAL su 3.0.

    Per attivare la funzionalità di patch audio, l'HAL audio deve impostare la versione HAL principale su 3.0 o versioni successive. Per ulteriori informazioni, consulta Device::supportsAudioPatches() nella implementazione HIDL predefinita, che puoi trovare anche in audio HAL per Cuttlefish.

Personalizzazione

Non è possibile disattivare la funzionalità o ripristinare il refactoring del dispositivo audio nel framework che consente di aggiungere tipi di dispositivi audio.

Tutti i tipi di dispositivi audio aggiunti consentono di rappresentare un tipo di dispositivo con un singolo bit impostato, in modo che le attuali implementazioni HAL continuino a funzionare.

Se vengono aggiunti nuovi tipi di dispositivi audio e gli OEM vogliono utilizzarli, devono aggiornare l'implementazione HAL audio e passare alla versione HIDL 6.0 o successive. È obbligatorio eseguire l'upgrade della versione principale dell'HAL alla 3.0 e implementare i metodi create_audio_patch e release_audio_patch, perché l'utilizzo di set_parameters per instradare lo stream può causare risultati imprevisti quando vengono aggiunti nuovi tipi di dispositivi audio.

Convalida

Il lavoro richiesto per gli OEM è l'aggiornamento delle implementazioni HAL. VTS per l'HAL audio può essere utilizzato per verificare se l'implementazione funziona come previsto. Tutti i test sono disponibili nei file VTS.