Limite del tipo di dispositivo

Nell'audio 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, esisteva un limite di 30 tipi di dispositivi di input/output audio e nessuno slot libero 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, i tipi di dispositivi audio ora sono valori enumerati anziché maschere di bit.

Tutti i tipi di dispositivi audio esistenti vengono mantenuti così come sono. AUDIO_DEVICE_BIT_IN è ancora utilizzato per distinguere i dispositivi di input o output. Quando si aggiungono nuovi tipi di dispositivi audio, i valori vengono enumerati negli spazi tra i valori 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 fonte

Prima di Android 11, esistevano due usi 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 specificata.

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 dal fornitore. 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, utilizzare le funzioni di supporto audio_is_.*_device in /system/media/audio/include/system/audio.h . Nel caso di più tipi di dispositivi audio, utilizzare le funzioni di supporto in libaudiofoundation . Ad esempio, utilizzare areAllOfSameDeviceType (DeviceTypeSet, std::function ) areAllOfSameDeviceType (DeviceTypeSet, std::function ) in AudioContainers.h per verificare se tutti i tipi di dispositivi audio specificati sono dello stesso tipo.

Implementazione

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

  1. Rimuovi tutta la memorizzazione dei dispositivi su un campo bit.

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

  2. Smettere di utilizzare operazioni bit per i confronti dei tipi di dispositivi.

    Prima di Android 11, i tipi di dispositivi audio potevano essere utilizzati come bitfield. In tal caso, è normale utilizzare operazioni bit per i confronti dei tipi di dispositivi. Quando vengono aggiunti nuovi tipi di dispositivi audio enumerati, le operazioni bit potrebbero causare risultati imprevisti. Utilizzare invece le funzioni di supporto 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, utilizzare le funzioni di supporto in /system/media/audio/include/system/audio.h . Ad esempio, audio_is_output_device(audio_devices_t device) .

  3. Smetti di utilizzare valori predefiniti per gruppi di tipi di dispositivi audio.

    Esistono alcuni valori predefiniti per 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 deprecati poiché non saranno corretti quando verranno aggiunti nuovi tipi di dispositivi audio enumerati. Ci sono nuovi gruppi di tipi di dispositivi audio definiti in audio-base-utils.h , che sono array di tipi di dispositivi audio, come AUDIO_DEVICE_OUT_ALL_ARRAY .

  4. Implementa i metodi create_audio_patch() e release_audio_patch() per il routing invece di 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.

    Attualmente sono richiesti due tipi di patch audio:

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

    Negli aggiornamenti successivi potrebbero essere necessarie patch aggiuntive da dispositivo a dispositivo.

    Quando si crea una patch audio, se l'handle della patch non è specificato, è necessario che l'HAL audio generi un handle della patch univoco in grado di identificare la patch audio. In caso contrario, l'HAL audio dovrebbe utilizzare l'handle della patch audio fornito per aggiornare la patch audio.

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

    Per abilitare la funzionalità di patch audio, l'HAL audio deve impostare la versione principale dell'HAL su 3.0 o successiva. Per ulteriori informazioni, fare riferimento a Device::supportsAudioPatches() nell'implementazione HIDL predefinita , reperibile anche nell'HAL audio per Cuttlefish.

Personalizzazione

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

Tutti i tipi di dispositivi audio aggiunti consentono di rappresentare un tipo di dispositivo con un singolo bit impostato, quindi le attuali implementazioni HAL funzionano ancora.

Se vengono aggiunti nuovi tipi di dispositivi audio e gli OEM desiderano utilizzarli, devono aggiornare la propria implementazione HAL audio e passare alla versione HIDL 6.0 o successiva. È obbligatorio aggiornare la versione principale dell'HAL alla 3.0 e implementare i metodi create_audio_patch e release_audio_patch , poiché l'utilizzo set_parameters per instradare il flusso può causare risultati imprevisti quando vengono aggiunti nuovi tipi di dispositivi audio.

Validazione

Il lavoro richiesto per gli OEM è aggiornare le proprie implementazioni HAL. VTS per HAL audio può essere utilizzato per verificare se l'implementazione funziona come previsto. Tutti i test possono essere trovati nei file VTS .