Seleção de áudio

Antes de iniciar um stream lógico, um app solicita o foco de áudio usando os mesmos atributos de áudio usados para o stream lógico. O app precisa respeitar as perdas de foco para funcionar como esperado nos casos de uso automotivo.

Embora seja recomendável enviar uma solicitação de foco, isso não é imposto pelo sistema. Portanto, considere o foco como uma forma de controlar e evitar conflitos indiretamente durante a reprodução, em vez de um mecanismo principal de controle de áudio. O veículo não pode depender do sistema de foco para operar o subsistema de áudio.

Interações de foco

Para oferecer suporte ao AAOS, as solicitações de seleção de áudio são processadas com base em interações predefinidas entre o CarAudioContext da solicitação e os detentores de seleção atuais. Há três tipos de interações:

  • Exclusivo
  • Recusar
  • Concurrent

Interação exclusiva

Esse é o modelo de interação mais usado com o Android.

Nas interações exclusivas, apenas um app pode manter o foco por vez. Portanto, uma solicitação de foco recebida recebe o foco enquanto o detentor de foco atual perde o foco. Como os dois apps reproduzem mídia, apenas um pode manter o foco. Como resultado, a solicitação de foco do app recém-iniciado é retornada com AUDIOFOCUS_REQUEST_GRANTED, enquanto o app de música em reprodução atual recebe um evento de mudança de foco com um status de perda que corresponde ao tipo de solicitação feita.

Rejeitar interação

Com as interações de rejeição, a solicitação recebida é sempre rejeitada. Por exemplo, ao tentar tocar música enquanto uma chamada está em andamento. Nesse caso, se o discador mantiver a seleção de áudio para uma chamada e um segundo app solicitar a seleção para tocar música, o app de música vai receber AUDIOFOCUS_REQUEST_FAILED em resposta à solicitação. Como a solicitação de foco é rejeitada, nenhuma perda de foco é enviada ao detentor do foco atual.

Interação simultânea

As interações simultâneas são exclusivas do AAOS. Isso permite que apps que solicitam a seleção de áudio no carro mantenham a seleção simultaneamente com outros apps. Para que uma interação simultânea ocorra, as seguintes condições precisam ser atendidas. O

Se esses critérios forem atendidos, a solicitação de foco retornará com AUDIOFOCUS_REQUEST_GRANTED, e o detentor do foco atual não terá mudanças no foco. No entanto, se o detentor do foco atual optar por receber eventos de redução ou pausar quando reduzido, ele perderá o foco, como ocorre com uma interação exclusiva.

Processar streams simultâneas

Embora a interação simultânea tenha vários usos, tome cuidado ao misturar e reduzir no nível do hardware em dispositivos de saída. Recomendamos que instâncias de CarAudioContext que podem ser reproduzidas simultaneamente sejam encaminhadas para dispositivos de saída diferentes.

Ao ter dispositivos de saída separados para streams simultâneos, a HAL pode reduzir o volume de um dos streams antes de misturá-los ou encaminhar os streams físicos para diferentes alto-falantes no veículo. Se os fluxos lógicos forem misturados no Android, os ganhos não serão alterados e serão entregues como parte do mesmo fluxo físico.

Por exemplo, quando a navegação e a mídia são entregues simultaneamente, o ganho do fluxo de mídia pode ser temporariamente reduzido (ou diminuído) para que as instruções de navegação possam ser ouvidas com mais clareza. Como alternativa, o fluxo de navegação pode ser encaminhado para os alto-falantes do lado do motorista enquanto a mídia continua sendo reproduzida no restante da cabine.

Matriz de interação

Esta tabela mostra a matriz de interação conforme definida por CarAudioService. Cada linha representa o CarAudioContext do detentor do foco atual, e cada coluna representa o da solicitação recebida.

Por exemplo, quando um app de mídia musical mantém o foco enquanto um app de navegação solicita o foco, a matriz indica que as duas interações podem ser executadas simultaneamente, supondo que os outros critérios para interações simultâneas sejam atendidos.

Devido às interações simultâneas, é possível ter mais de um detentor do foco. Nesse caso, uma solicitação de foco recebida é comparada com cada um dos detentores de foco atuais antes de determinar qual interação aplicar. Nesse caso, a interação mais conservadora vence. Rejeitar, depois exclusivo e, por fim, simultâneo.

Matriz de interação de seleção de áudio

Figura 1. Matriz de interação de seleção de áudio.

No Android 11, uma nova configuração de usuário foi introduzida para permitir que os usuários alterem o comportamento de interação entre a navegação e as ligações. Quando definido, android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL muda a interação entre as solicitações de foco NAVIGATION recebidas e os detentores de foco CALL atuais de concorrentes para rejeições. Se um usuário preferir que as instruções de navegação não interrompam uma chamada, ele pode ativar a configuração. Isso é mantido para o usuário e pode ser definido dinamicamente para que as solicitações de foco subsequentes respeitem a nova configuração.

Seleção de áudio adiável

No Android 11, o AAOS adicionou suporte para solicitar o foco de áudio adiável. Isso permite que solicitações de foco não temporárias sejam adiadas quando a interação delas com os detentores de foco atuais normalmente resultaria na rejeição delas. Quando uma mudança no foco resulta em um estado em que a solicitação atrasada pode ganhar foco, ela é concedida.

Regras para solicitações de seleção de áudio atrasadas

  • Apenas solicitações não temporárias. Uma solicitação atrasada só pode ser feita para fontes não transientes para evitar que um som transiente seja reproduzido muito depois de ser relevante.

  • Só é possível atrasar uma solicitação por vez. Se uma solicitação adiável for feita enquanto já houver uma solicitação adiada, a solicitação adiada original receberá um evento de mudança AUDIOFOCUS_LOSS, e a nova solicitação receberá uma resposta síncrona de AUDIOFOCUS_REQUEST_DELAYED.

  • As solicitações adiáveis precisam ter OnAudioFocusChangeListener. Depois que uma solicitação é adiada, o listener é usado para notificar o solicitante quando a solicitação é concedida (AUDIOFOCUS_GAIN) ou rejeitada (AUDIOFOCUS_LOSS).

Solicitar foco adiável

Para criar uma solicitação que pode ser adiada:

  1. Use AudioFocusRequest.Builder#setAcceptsDelayedFocusGain.

    mMediaWithDelayedFocusListener = new MediaWithDelayedFocusListener();

mDelayedFocusRequest = new AudioFocusRequest
     .Builder(AudioManager.AUDIOFOCUS_GAIN)
     .setAudioAttributes(mMusicAudioAttrib)
     .setOnAudioFocusChangeListener(mMediaWithDelayedFocusListener)
     .setForceDucking(false)
     .setWillPauseWhenDucked(false)
     .setAcceptsDelayedFocusGain(true)
     .build();

  2. Ao fazer a solicitação, processe a resposta AUDIOFOCUS_REQUEST_DELAYED:

    int delayedFocusRequestResults = mAudioManager.requestAudioFocus(mDelayedFocusRequest);
if (delayedFocusRequestResults == AudioManager.AUDIOFOCUS_REQUEST_GRANTED) {
    // start audio playback
    return;
}
if (delayedFocusRequestResults == AudioManager.AUDIOFOCUS_REQUEST_DELAYED) {
     // audio playback delayed to audio focus listener
     return;
}

  3. Quando a solicitação é atrasada, o listener de foco processa as mudanças de foco:

    private final class MediaWithDelayedFocusListener implements
OnAudioFocusChangeListener {
       @Override
       public void onAudioFocusChange(int focusChange) {
           synchronized (mLock) {
               switch (focusChange) {
                   case AudioManager.AUDIOFOCUS_GAIN:
                       … // Start focus playback
                   case AudioManager.AUDIOFOCUS_LOSS_TRANSIENT:
                       … // Pause media transiently
                   case AudioManager.AUDIOFOCUS_LOSS:
                       … // Stop media

Fade forçado pelo sistema

O Android 15 introduz o aumento gradual de áudio imposto pelo sistema no AAOS. No Android, a seleção de áudio não é aplicada pelo sistema. Portanto, embora os desenvolvedores de apps sejam incentivados a obedecer às diretrizes de seleção de áudio, se um app continuar tocando em volume alto mesmo depois de perder a seleção de áudio, o sistema não poderá impedir isso.

Em ambientes automotivos críticos para a segurança, a adesão ao foco de áudio é vital para minimizar a distração do motorista. Com esse recurso, a estrutura de áudio agora diminui automaticamente os apps que perdem o foco de áudio, proporcionando uma experiência de áudio mais controlada e previsível.

Essa melhoria ajuda a garantir que os apps sigam a decisão de perda de foco de áudio, conforme definido pela matriz de interação, evitando conflitos de reprodução de áudio.

Design de alto nível

A figura a seguir mostra o design de alto nível e o suporte para o recurso de perda de foco nos carros:

Design de alto nível para o recurso de fade imposto pelo sistema

Figura 2. Design de alto nível para o recurso de fade imposto pelo sistema.

  • Esmaecimento direcionado:a aplicação do sistema de esmaecimento no Android 15 foi projetada especificamente para situações em que um app perde a seleção de áudio, mas continua tocando áudio.
  • Mecanismo de esmaecimento:quando um app perde a seleção de áudio para um novo app solicitante:
    • O framework de áudio esmaece automaticamente o áudio do app perdedor.
    • Depois do fade-out, o fluxo de áudio é silenciado pelo sistema.
    • Em seguida, o app recebe uma notificação de perda de seleção de áudio.
    • Os apps com comportamento inadequado são silenciados até recuperarem o foco de áudio.
    • A lógica padrão é mostrar os apps que estão esmaecidos após 2 segundos. No entanto, os OEMs podem configurar qualquer valor de tempo limite.
    • O framework de áudio usa as configurações do OEM para operações de fade-out e fade-in.

  • Arquivo de configuração do OEM:o Android 15 inclui um novo arquivo de configuração, car_audio_fade_configuration.xml:

    • Esse arquivo permite que os OEMs definam critérios para quando a aplicação da seleção de áudio do sistema é aplicada a um app perdedor.
    • O framework de áudio só aplica o fade-out e o silenciamento se o app perdedor corresponder às regras definidas pelo OEM neste arquivo XML.
    • Isso oferece um mecanismo para que os OEMs personalizem o comportamento do recurso com base nas características do app ou nos tipos de uso de áudio.

  • Controle de recursos com RRO:uma nova flag de recurso de sobreposição de recursos de ambiente de execução (RRO), audioUseFadeManagerConfiguration, foi introduzida para ativar ou desativar esse recurso:

    • Esse recurso fica desativado por padrão.
    • Para ativar a perda de foco de áudio imposta pelo sistema, os OEMs precisam definir essa flag como true.
    • Embora a estrutura de áudio do carro espere definições de configuração de fade válidas quando a flag está ativada, a ausência dessas definições não resulta automaticamente em uma exceção fatal.
    • Todos os apps de configurações de transição precisam ter definições de transição correspondentes. É um erro fatal chamar uma configuração de fade (pelo nome) como parte da configuração de áudio do carro sem fornecer uma definição válida.
    • Quando a flag está desativada, todas as definições de configuração de fade e as referências de configuração são ignoradas.

Configuração do gerenciador de transições

O framework de áudio do Android 15 apresenta um FadeManagerConfiguration unificado para oferecer aos OEMs controle granular sobre o comportamento de fade de áudio. Esse framework é ilustrado na Figura 3:

Configuração do gerenciador de transições

Figura 3. Configuração do gerenciador de transição.

Essa configuração inclui:

  • Propriedades de transição de esmaecimento:configurações para esmaecimento de saída e de entrada.
    • Pode ser definido com usos ou atributos de áudio específicos.
    • Permite configurações de duração personalizadas.
    • Essas configurações são usadas para construir VolumeShaper.Configuration.
  • Políticas de transição gradual:regras que regem quando a transição gradual ocorre.
    • Uma opção global para ativar ou desativar o efeito de fade-in/fade-out.
    • Uma lista configurável de usos de áudio que podem ser atenuados (qualificados para atenuação ao perder o foco).
    • As listas de exclusão (não esmaecíveis) impedem que fontes de áudio críticas ou designadas sejam esmaecidas. Essas listas podem ser baseadas em:
      • Tipos de conteúdo
      • Atributos de áudio
      • UIDs de apps (só podem ser definidos durante a execução)

Configurações de OEM

Nesta seção, vamos analisar as personalizações de OEM disponíveis.

Arquivo XML de configuração de fade de áudio do carro.

O Android 15 apresenta um novo arquivo de configuração, car_audio_fade_configuration.xml, que permite uma ampla personalização do OEM do comportamento de fade-out de áudio durante a perda de foco.

  • Esse arquivo XML permite a definição de várias configurações de transição distintas, cada uma exigindo um nome exclusivo para referências cruzadas em car_audio_configuration.xml.
  • Essas configurações podem ser aplicadas de forma flexível em diferentes zonas de áudio e configurações de zona.
  • Cada configuração de fade aceita apenas valores de duração em milissegundos, que o sistema usa para gerar internamente o VolumeShaper.Configuration correspondente.

Para orientações práticas de implementação, consulte os exemplos de configurações fornecidos para o emulador em device/generic/car/emulator/audio/car_audio_fade_configuration.xml.

Arquivo XML de configuração de áudio do carro

O Android 15 apresenta um arquivo car_audio_configuration.xml atualizado, agora na versão 4, que incorpora novas tags applyFadeConfigs e fadeConfig. A tag applyFadeConfigs pode conter várias definições de fadeConfig, permitindo uma configuração de fade flexível. Cada definição:

  • Precisa incluir um fadeConfig padrão designado com isDefault = true.
  • Pode incluir várias definições de fadeConfig temporárias. Essas configurações temporárias são aplicadas especificamente durante as interações de perda de seleção de áudio, e somente quando o app que ganha a seleção de áudio corresponde aos critérios definidos na configuração temporária.

Para orientações práticas de implementação, consulte os exemplos de configurações fornecidos para o emulador em device/generic/car/emulator/audio/car_audio_configuration.xml.

Extensão de serviço de seleção de áudio do OEM

Os OEMs que implementam um serviço de foco de áudio personalizado para carro têm a flexibilidade de configurar as configurações de fade-out de áudio incluindo-as em OemCarAudioFocusResult. Isso pode ser feito usando o método builder setAudioAttributesToCarAudioFadeConfigurationMap():

/** @see OemCarAudioFocusResult#getAudioAttributesToCarAudioFadeConfigurationMap() **/
@NonNull
public Builder setAudioAttributesToCarAudioFadeConfigurationMap(@NonNull
        Map<AudioAttributes, CarAudioFadeConfiguration> attrsToCarAudioFadeConfig) {
}

Os OEMs podem usar configurações de fade no tempo de inicialização pré-configuradas ou aplicar configurações dinamicamente pelo serviço de foco de áudio personalizado, oferecendo controle adaptável.

Diagrama de sequência

Este diagrama de sequência ilustra o comportamento após a concessão do foco de áudio para App2 e a perda subsequente do foco de áudio por App1:

  • Quando o serviço de áudio do carro envia a perda de foco de áudio para App1, a reprodução do player App1 passa por um fade-out conforme definido pelos FadeManagerConfigurations ativos. Quando a operação de fade-out for concluída, App1 receberá o callback padrão de perda de foco de áudio.
  • Também é possível aumentar o áudio do App1 após uma duração configurável. Os OEMs têm a flexibilidade de definir essa duração usando Builder#setFadeInDurationForUsage(int, long) de acordo com os requisitos específicos do produto.

Diagrama de sequência para o recurso de fade do áudio do carro

Figura 4. Diagrama de sequência para o recurso de fade do áudio do carro.

Gerenciamento de foco em várias zonas

Em veículos com várias zonas de áudio, o foco de áudio é gerenciado de forma independente para cada zona. Assim, uma solicitação para uma zona não considera o que está em foco em outras zonas, nem faz com que os detentores de foco em outras zonas percam o foco. Assim, o foco da cabine principal pode ser gerenciado separadamente de um sistema de entretenimento no banco traseiro, sem interromper a reprodução de áudio em uma zona por mudanças feitas em outra.

Para todos os apps, o CarAudioService gerencia o foco automaticamente. A zona de áudio de uma solicitação de foco é determinada pelo UserId ou UID associado a ela. Para mais detalhes, consulte Roteamento de áudio multizona.

Solicitar áudio de várias zonas simultaneamente

Se um app quiser tocar áudio em várias zonas simultaneamente, ele precisará solicitar o foco de cada zona incluindo AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID no pacote:

//Create attribute with bundle and AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID
Bundle bundle = new Bundle();
bundle.putInt(CarAudioManager.AUDIOFOCUS_EXTRA_REQUEST_ZONE_ID,
               zoneId);

AudioAttributes attributesWithZone = new AudioAttributes.Builder()
     .setUsage(AudioAttributes.USAGE_MEDIA)
     .addBundle(bundle)
     .build();

//Create focus request using built attributesWithZone

Com esse parâmetro de pacote, o solicitante pode substituir os mapeamentos automáticos de zona de áudio e usar o ID de zona especificado. Portanto, um app pode emitir solicitações separadas para diferentes zonas de áudio.

Seleção de áudio da HAL

A partir do Android 11, a HAL pode solicitar o foco em nome de streams externos. Embora seja opcional, o uso dessas APIs é altamente recomendado para permitir que sons externos sejam participantes ideais no ecossistema Android e para oferecer uma experiência do usuário perfeita.

A HAL faz a determinação final sobre quais sons devem ter prioridade. Nesse sentido, os sons críticos de emergência e segurança precisam ser reproduzidos independente de a HAL ter ou não o foco de áudio e precisam continuar sendo reproduzidos conforme apropriado, mesmo que a HAL perca o foco de áudio. O mesmo vale para sons exigidos por regulamentações governamentais.

A HAL precisa silenciar proativamente os fluxos do Android conforme apropriado ao tocar sons de emergência ou críticos para a segurança, garantindo que eles sejam ouvidos com clareza.

AudioControl@2.0

A versão 2.0 da HAL AudioControl apresenta estas novas APIs:

API Finalidade
IAudioControl#registerFocusListener Registra uma instância de IFocusListener com a HAL AudioControl. Esse listener permite que a HAL solicite e abandone a seleção de áudio. A HAL fornece uma instância ICloseHandle para ser usada pelo Android para cancelar o registro do listener.
IAudioControl#onAudioFocusChange Notifica a HAL sobre mudanças no status para focar solicitações feitas pela HAL pela IFocusListener, incluindo respostas a solicitações de foco iniciais.
IFocusListener#requestAudioFocus As solicitações se concentram em nome da HAL para um uso, ID da zona e tipo de ganho de foco especificados.
IFocusListener#abandonAudioFocus Abandona as solicitações de foco da HAL para o uso e o ID da zona especificados.

A HAL pode ter várias solicitações de foco ao mesmo tempo, mas é limitada a uma solicitação por uso e ID de zona. O Android pressupõe que a HAL começa a tocar sons para um uso assim que uma solicitação é feita e continua fazendo isso até abandonar o foco.

Além de registerFocusListener, essas solicitações são oneway para garantir que o Android não atrase a HAL enquanto uma solicitação de foco é processada. A HAL não deve esperar para ganhar foco antes de reproduzir sons críticos para a segurança. É opcional para o HAL detectar e responder a mudanças na seleção de áudio usando IAudioControl#onAudioFocusChange.

Serviço de seleção de áudio do carro OEM

No Android 14, o AAOS introduziu os serviços de plug-in OEM de carro para permitir a capacidade de configuração de alguns componentes do carro. Para o serviço de plug-in de áudio do carro, o serviço de plug-in permite que os OEMs gerenciem solicitações de foco interceptadas pelo serviço de áudio do carro. Isso dá aos OEMs mais flexibilidade para gerenciar o foco conforme exigido por regras e regulamentações. Por isso, a interação do foco de áudio pode variar entre fabricantes e de região para região. A premissa básica do foco de áudio ainda é válida: os apps precisam solicitar o foco para melhorar o gerenciamento de áudio e aprimorar a experiência do usuário. Em geral, algumas regras ainda se aplicam à solicitação de foco de áudio por apps:

  • Sem um foco de áudio permanente e de alta prioridade (incluindo uma ligação telefônica, um alerta de emergência ou uma notificação de segurança), os apps precisam conseguir o foco de áudio de forma temporária ou permanente.

  • Enquanto um foco de mídia estiver ativo:

    • Os apps que solicitam o uso de chamadas precisam ser capazes de receber a ligação de forma simultânea ou exclusiva.

    • Os apps que solicitam o uso do foco de navegação precisam receber o foco de navegação de forma simultânea ou exclusiva.

    • Os apps que solicitam o foco de uso do assistente precisam receber o foco de uso de forma simultânea ou exclusiva.

  • Enquanto os apps com foco de áudio de alta prioridade (incluindo uma ligação, alerta de emergência ou notificação de segurança) estiverem ativos, qualquer solicitação de foco de áudio atrasada recebida deverá ser concedida ou adiada conforme necessário.

Embora essas sugestões não sejam exaustivas, elas podem ajudar os apps que solicitam foco a obtê-lo se não houver sons ativos de alta prioridade. Mesmo quando sons de alta prioridade estão ativos, as solicitações de foco atrasadas ainda precisam ser respeitadas e precisam poder ganhar foco quando o som de alta prioridade parar.