Foco de áudio

Antes de iniciar um fluxo lógico, um aplicativo solicita foco de áudio usando os mesmos atributos de áudio usados ​​para o fluxo lógico. O aplicativo deve respeitar as perdas de foco para funcionar conforme o esperado nos casos de uso automotivo.

Embora seja recomendado enviar uma solicitação de foco, ela não é imposta pelo sistema. Portanto, considere o foco como um meio de controlar indiretamente e evitar conflitos durante a reprodução, em vez de um mecanismo primário de controle de áudio. O veículo não deve depender do sistema de foco para operação do subsistema de áudio.

Interações de foco

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

• Exclusivo
• Rejeitar
• Simultâneo

Interação exclusiva

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

Em interações exclusivas , apenas um aplicativo pode manter o foco por vez. Portanto, uma solicitação de foco recebida recebe foco enquanto o detentor do foco existente perde o foco. Como ambos os aplicativos reproduzem mídia, apenas um aplicativo pode manter o foco. Como resultado, a solicitação de foco do aplicativo recém-iniciado é retornada com AUDIOFOCUS_REQUEST_GRANTED enquanto o aplicativo que está reproduzindo música no momento 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 interações de rejeição , a solicitação recebida é sempre rejeitada. Por exemplo, ao tentar reproduzir música enquanto uma chamada está em andamento. Nesse caso, se o Discador mantiver o foco de áudio para uma chamada e um segundo aplicativo solicitar foco para reproduzir música, o aplicativo de música receberá AUDIOFOCUS_REQUEST_FAILED em resposta à solicitação. Como a solicitação de foco é rejeitada, nenhuma perda de foco é despachada para o detentor do foco atual.

Interação simultânea

Exclusivas do AAOS são as interações simultâneas . Isso dá aos aplicativos que solicitam foco de áudio no carro a capacidade de manter o foco simultaneamente com outros aplicativos. Para que uma interação simultânea ocorra, as seguintes condições devem ser atendidas. O:

• A solicitação de foco recebida deve solicitar AudioManager.AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK

• O detentor do foco atual não definePauseWhenDucked(true)

• O atual detentor do foco opta por não receber eventos de pato

Se esses critérios forem atendidos, a solicitação de foco retornará com AUDIOFOCUS_REQUEST_GRANTED enquanto o detentor do foco atual não tiver alteração no foco. Porém, se o atual detentor do foco optar por receber eventos de pato ou pausar quando for abaixado, o atual detentor do foco perderá o foco, como ocorre com uma interação exclusiva.

Lidando com fluxos simultâneos

Embora a interação simultânea tenha vários usos, tome cuidado ao mixar e reduzir no nível do hardware nos dispositivos de saída. Recomendamos fortemente que os CarAudioContext que podem ser reproduzidos simultaneamente sejam roteados para diferentes dispositivos de saída.

Ao ter dispositivos de saída separados para fluxos simultâneos, isso permite que o HAL reduza um dos fluxos antes de misturá-los ou encaminhe os fluxos físicos para diferentes alto-falantes no veículo. Se os fluxos lógicos forem misturados no Android, os ganhos permanecerão inalterados e 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 reduzido) para que as instruções de navegação possam ser ouvidas com mais clareza. Alternativamente, o fluxo de navegação pode ser direcionado para os alto-falantes do lado do motorista enquanto a mídia continua a ser reproduzida no resto da cabine.

Matriz de interação

A tabela abaixo mostra a matriz de interação 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 aplicativo de mídia musical mantém o foco enquanto um aplicativo de navegação solicita o foco, a matriz indica que as duas interações podem ser reproduzidas simultaneamente, assumindo 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 de foco. Neste 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, vence a interação mais conservadora. Rejeitar, depois exclusivo e finalmente concorrente.

Figura 1. Matriz de interação do foco de áudio.

Navegação durante chamadas telefônicas

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 navegação e chamadas telefônicas. Quando definido, android.car.KEY_AUDIO_FOCUS_NAVIGATION_REJECTED_DURING_CALL altera a interação entre as solicitações de foco NAVIGATION recebidas e os detentores de foco CALL atuais de simultâneos para rejeitados . Se um usuário preferir que as instruções de navegação não interrompam a chamada, ele poderá ativar a configuração. Isso é persistido para o usuário e pode ser definido dinamicamente para que as solicitações de foco subsequentes respeitem a nova configuração.

Foco de áudio atrasável

No Android 11, AAOS adicionou suporte para solicitação de foco de áudio atrasável . Isso permite que solicitações de foco não transitórias sejam atrasadas quando sua interação 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, a solicitação é atendida.

Regras para solicitações de foco de áudio atrasadas

• Somente solicitações não transitórias. Uma solicitação atrasada só pode ser feita para fontes não transitórias, a fim de evitar a reprodução de um som transitório muito depois de ser relevante.

• Apenas uma solicitação pode ser adiada por vez. Se uma solicitação atrasada for feita enquanto já houver uma solicitação atrasada, a solicitação atrasada original receberá um evento de alteração AUDIOFOCUS_LOSS e a nova solicitação receberá uma resposta síncrona de AUDIOFOCUS_REQUEST_DELAYED .

• Solicitações atrasadas devem ter um OnAudioFocusChangeListener Quando uma solicitação é atrasada, o ouvinte é usado para notificar o solicitante quando a solicitação for eventualmente concedida ( AUDIOFOCUS_GAIN ) ou se for rejeitada posteriormente ( AUDIOFOCUS_LOSS ).

Solicitar foco atrasável

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

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, trate 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 ouvinte de foco trata as alterações 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
   

Gerenciamento de foco multizona

Para veículos com múltiplas zonas de áudio, o foco de áudio é gerenciado de forma independente para cada zona. Dessa forma, uma solicitação para uma zona não leva em consideração o que mantém o foco em outras zonas, nem faz com que os detentores de foco em outras zonas percam o foco. Com isto, o foco da cabine principal pode ser gerenciado separadamente do sistema de entretenimento do banco traseiro, não interrompendo assim a reprodução de áudio em uma zona por alterações feitas no foco em outra.

Para todos os aplicativos, o CarAudioService gerencia automaticamente o foco. A zona de áudio de uma solicitação de foco é determinada por seu UserId ou UID associado (para obter detalhes, consulte Roteamento de áudio ).

Solicite áudio de várias zonas simultaneamente

Se um aplicativo quiser reproduzir áudio em várias zonas simultaneamente, ele deverá solicitar o foco para 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

Este parâmetro de pacote permite que o solicitante substitua os mapeamentos automáticos de zona de áudio para usar o ID de zona especificado. Portanto, um aplicativo pode emitir solicitações separadas para zonas de áudio diferentes.

Foco de áudio HAL

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

O HAL toma a decisão final sobre quais sons devem ter prioridade. Nesta medida, os sons críticos de emergência e segurança devem ser reproduzidos independentemente de o HAL receber ou não o foco de áudio e devem continuar a ser reproduzidos conforme apropriado, mesmo que o HAL perca o foco de áudio. O mesmo se aplica a quaisquer sons exigidos por regulamentações governamentais.

O HAL deve silenciar proativamente as transmissões do Android conforme apropriado ao reproduzir sons de emergência ou críticos para a segurança, para garantir que sejam ouvidos com clareza.

ÁudioControl@2.0

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

O HAL pode ter múltiplas solicitações de foco ao mesmo tempo, mas está limitado a uma solicitação por uso e emparelhamento de ID de zona. O Android assume que o HAL começa imediatamente a reproduzir sons para uso assim que uma solicitação é feita e continua a fazê-lo até abandonar o foco.

Além de registerFocusListener , essas solicitações são oneway para garantir que o Android não atrase o HAL enquanto uma solicitação de foco é processada. O HAL não deve esperar para obter foco antes de reproduzir sons críticos para a segurança. É opcional para o HAL ouvir e responder às mudanças no foco do áudio por meio de IAudioControl#onAudioFocusChange .

Serviço de foco de áudio automotivo OEM

No Android 14, a AAOS introduziu os serviços de plug-in OEM do carro para permitir a configurabilidade de alguns componentes do carro. Para Car Audio Plugin Service , o serviço de plug-in permite que os OEMs gerenciem solicitações de foco interceptadas pelo serviço de áudio automotivo. Isto dá aos OEMs mais flexibilidade em termos de gerenciamento do foco, conforme exigido pelas regras e regulamentos. Como tal, a interação do foco de áudio pode diferir entre fabricantes e de região para região. A premissa básica para o foco no áudio ainda é válida: os aplicativos ainda devem solicitar foco para um melhor gerenciamento do áudio para aprimorar a experiência do usuário. Em geral, certas regras ainda se aplicam à solicitação de foco de áudio por aplicativos:

• Sem qualquer foco de áudio permanente e de alta prioridade (incluindo uma chamada telefônica, alerta de emergência ou notificação de segurança), os aplicativos devem ser capazes de obter foco de áudio de forma transitória ou permanente.

• Enquanto um foco de mídia estiver ativo:

  • Os aplicativos que solicitam foco no uso de chamadas devem poder receber a chamada simultaneamente ou exclusivamente.

  • Os aplicativos que solicitam foco de uso de navegação devem poder receber foco de navegação simultânea ou exclusivamente.

  • Os aplicativos que solicitam foco de uso do assistente devem poder receber foco de uso de forma simultânea ou exclusiva.

• Enquanto os aplicativos de foco de áudio de alta prioridade (incluindo uma chamada telefônica, 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 atrasada conforme necessário.

Embora as sugestões acima não sejam exaustivas, elas podem ajudar os aplicativos que solicitam foco a obter foco se não existirem sons ativos de alta prioridade. Mesmo enquanto os sons de alta prioridade estão ativos, as solicitações de foco atrasado ainda devem ser respeitadas e devem ser capazes de ganhar foco quando o som de alta prioridade parar.