Limite del tipo di dispositivo

In audio Android, audio_devices_t è 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, c'era 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 usato per distinguere dispositivi di ingresso o di uscita. Quando si aggiungono nuovi tipi di dispositivi audio, vengono enumerati i valori negli spazi tra i valori esistenti.

OEM non dovrebbe usare audio_devices_t come una maschera di bit, perché che può causare risultati imprevisti quando vengono aggiunti nuovi tipi di dispositivi audio enumerati.

Esempi e fonte

Prima di Android 11, c'erano due usi tipici dei tipi di dispositivi audio come maschere di bit.

  • Utilizzando audio_devices_t valore per rappresentare i dispositivi audio multipli.
  • Verificando la audio_devices_t valore contiene tipi di dispositivi audio da una determinata categoria.

Per rappresentare più tipi di dispositivi audio, una classe denominata DeviceTypeSet nella /libaudiofoundation/include/media/AudioContainers.h viene utilizzato, che è uno std::set contenitore di audio_devices_t . La classe è dichiarata nella vendor-disponibili libaudiofoundation biblioteca. Per rappresentare più tipi di dispositivi audio nel codice C, una matrice o un elenco di audio_devices_t possono essere usati.

Per verificare se un unico tipo di dispositivo ha uno stile specificato, le funzioni di utilizzo di supporto audio_is_.*_device in /system/media/audio/include/system/audio.h . Per di più l'audio caso tipi di dispositivo, utilizzare le funzioni di supporto in libaudiofoundation . Ad esempio, l'uso areAllOfSameDeviceType (DeviceTypeSet, std::function ) areAllOfSameDeviceType (DeviceTypeSet, std::function ) In AudioContainers.h per controllare se tutti i tipi di dispositivi trovati audio 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. Rimuovere tutta l'archiviazione dei dispositivi su un campo di bit.

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

  2. Interrompi l'uso delle operazioni sui bit per i confronti dei tipi di dispositivi.

    Prima di Android 11, i tipi di dispositivi audio possono essere utilizzati come campo di bit. In tal caso, è comune utilizzare le operazioni sui bit per i confronti dei tipi di dispositivi. Quando vengono aggiunti nuovi tipi di dispositivi audio enumerati, le operazioni sui bit possono causare risultati imprevisti. Utilizzare invece le funzioni di supporto come alternativa. Se c'è un solo tipo di dispositivo audio, usa il confronto diretto per confrontare i due valori. Per verificare se un tipo di dispositivo audio è nella categoria specificata, utilizzare le funzioni di supporto 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 gruppi di tipi di dispositivi audio.

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

  4. Attuare il create_audio_patch() e release_audio_patch() metodi per il routing invece di set_parameters .

    Il set_parameters metodo utilizza tipi di dispositivi audio come un campo di bit, quindi non ci può essere risultati inaspettati se vengono aggiunti nuovi tipi di dispositivi audio enumerati.

    Attualmente sono necessari due tipi di patch audio:

    • Mix su 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, l'HAL audio è necessario per generare un handle di patch univoco che possa identificare la patch audio. In caso contrario, l'HAL audio dovrebbe utilizzare l'handle di patch audio fornito per aggiornare la patch audio.

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

    Per abilitare la funzionalità di patch audio, l'HAL audio deve impostare la versione principale dell'HAL su 3.0 o superiore. Fare riferimento al Device::supportsAudioPatches() in implementazione predefinita HIDL per ulteriori informazioni, che può anche essere trovato su HAL audio per Seppie.

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, quindi le attuali implementazioni HAL funzionano ancora.

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

Convalida

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