O Google tem o compromisso de promover a igualdade racial para as comunidades negras. Saiba como.

Esta página foi traduzida pela API Cloud Translation.

Foco de áudio

Antes de iniciar um stream lógico, um app solicita a seleção de áudio usando a mesma os atributos de áudio como são usados para o stream lógico. O app precisa respeitar o foco o desempenho esperado nos casos de uso automotivos.

Embora o envio de uma solicitação de foco seja recomendado, ela não é aplicada pelo sistema. Portanto, considere o foco como um meio de controlar indiretamente e evitar conflitos durante a reprodução, e não como mecanismo principal de controle de áudio. O veículo não pode depender do sistema de foco para a operação do subsistema de áudio.

Focar interações

Para oferecer suporte ao AAOS, as solicitações de seleção de áudio são processadas com base interações entre o CarAudioContext da solicitação e o da atual fixadores de foco. Existem três tipos de interações:

Exclusivo
Recusar
Concurrent

Interação exclusiva

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

Em interações exclusivas, somente um app pode manter o foco por vez. Portanto, uma solicitação de foco recebida recebe foco, enquanto o foco existente o detentor perder o foco. Como os dois apps reproduzem mídia, apenas um deles tem permissão para manter foco. Como resultado, a solicitação de foco do app recém-iniciado é retornada com AUDIOFOCUS_REQUEST_GRANTED enquanto o app que está tocando música recebe uma evento de alteração de foco com um status de perda que corresponde ao tipo de solicitação que foi feita.

Recusar interação

Com interações reject, a solicitação recebida é sempre rejeitada. Para por exemplo, ao tentar tocar música durante uma chamada. Neste caso o Telefone mantenha a seleção de áudio para uma chamada e um segundo app solicite a seleção. para tocar música, o app 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 de foco atual.

Interação simultânea

Exclusivas do AAOS são interações simultâneas. Dessa forma, os apps que solicitam áudio focar no carro, mantendo o foco ao mesmo tempo que outros apps. Para um interação simultânea ocorrer, as condições a seguir precisam ser atendidas. A:

A solicitação de foco recebida precisa solicitar: AudioManager.AUDIOFOCUS_GAIN_TRANSIENT_MAY_DUCK (em inglês)
O detentor de foco atual não setPauseWhenDucked(true).
O detentor do foco atual 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 armazenador de foco atual não tiver mudanças em foco. No entanto, se o detentor do foco atual optar por receber eventos de pato ou pausa quando está abaixado, o detentor atual perde o foco, como ocorre com uma uma interação exclusiva.

Como processar streams simultâneos

Embora a interação simultânea tenha vários usos, tenha cuidado ao misturar e redução de volume no nível do hardware em todos os dispositivos de saída. É altamente recomendável Os CarAudioContexts que têm permissão para reproduzir simultaneamente precisam ser roteados para diferentes dispositivos de saída.

Por ter dispositivos de saída separados para streams simultâneos, isso permite que a HAL para desviar uma das transmissões antes de mixá-las ou rotear as transmissões físicas para vários alto-falantes no veículo. Se as transmissões lógicas estiverem misturadas No Android, os ganhos sã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 podem ser ouvidas com mais clareza. Por outro lado, o menu de navegação ela pode ser encaminhada para os alto-falantes do lado do motorista enquanto a mídia continua brincar pelo resto da cabine.

Matriz de interação

A tabela abaixo mostra a matriz de interação conforme definido por CarAudioService. Cada linha representa o CarAudioContext do detentor de foco atual e cada representa aquela da solicitação recebida.

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

Devido às interações simultâneas, é possível ter mais de um detentor de foco. Nesse caso, uma solicitação de foco recebida é comparada a cada um os detentores de foco atuais antes de determinar qual interação aplicar. Neste nesse caso, a interação mais conservadora vence. Rejeitar, depois exclusiva e finalmente simultâneas.

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

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

Foco de áudio retardável

No Android 11, o AAOS adicionou suporte à solicitação de seleção de áudio atrasável. Isso permite que solicitações de foco não transitórias sejam atrasadas quando a interação com eles os detentores de foco atuais normalmente resultariam na rejeição deles. Uma vez que mudança de foco resulta em um estado em que a solicitação atrasada pode ganhar foco, a solicitação é concedida.

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

Apenas solicitações não temporárias. Uma solicitação atrasada só pode ser feita para fontes não temporárias, a fim de evitar uma reprodução de som transitória longa depois de ser relevante.
Apenas uma solicitação pode atrasar por vez. Se uma solicitação com atraso for feita enquanto já existe uma solicitação atrasada, a solicitação original atrasada recebe um evento de mudança AUDIOFOCUS_LOSS, e a nova solicitação recebe um resposta síncrona de AUDIOFOCUS_REQUEST_DELAYED.
As solicitações atrasadas precisam ter um OnAudioFocusChangeListener Quando um a solicitação estiver atrasada, o listener será usado para notificar o solicitante quando o a solicitação é concedida (AUDIOFOCUS_GAIN) ou se for rejeitada depois (AUDIOFOCUS_LOSS).

Solicitar foco com atraso

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

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();

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;
}

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

Gerenciamento de foco em várias zonas

Nos veículos com várias zonas de áudio, a seleção de áudio é gerenciada 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 perder o foco. Com isso, o foco da cabine principal pode ser administrado separadamente de sistema de entretenimento no assento traseiro, sem interromper a reprodução de áudio uma zona por alterações feitas no foco para outra.

O CarAudioService gerencia o foco automaticamente em todos os apps. Um foco a zona de áudio da solicitação é determinada pelo UserId ou UID associado Veja mais detalhes em Roteamento de áudio.

Solicitar áudio de várias zonas simultaneamente

Se um aplicativo quiser reproduzir áudio em diversas zonas ao mesmo tempo, ele deve solicitar 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 a zona de áudio automática para que usem o ID de zona especificado. Portanto, um app pode apresentar solicitações separadas para diferentes zonas de áudio.

Foco de áudio HAL

No Android 11 e versões mais recentes, a HAL é ativada para solicitar foco em nome da streams externos. Embora opcional, o uso dessas APIs é altamente incentivado para permitem que sons externos sejam os melhores participantes no ecossistema Android e para fornecer uma experiência do usuário perfeita.

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

A HAL precisa silenciar proativamente as transmissões do Android conforme necessário durante a reprodução sons de emergência ou essenciais para a segurança para garantir que eles sejam ouvidos com clareza.

Controle de áudio@2.0

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

API	Objetivo
`IAudioControl#registerFocusListener`	Registra uma instância de `IFocusListener` com o HAL AudioControl. Esse listener permite que a HAL solicite e abandone áudio foco. O HAl fornece uma instância `ICloseHandle` para ser usada Android para cancelar o registro do listener.
`IAudioControl#onAudioFocusChange`	Notifica a HAL sobre alterações de status para solicitações de foco feitas por ela pelo `IFocusListener`, incluindo respostas a solicitações solicitações de foco.
`IFocusListener#requestAudioFocus`	As solicitações se concentram em nome da HAL para um uso especificado, ID de zona, e o tipo de ganho de foco.
`IFocusListener#abandonAudioFocus`	Abandona as solicitações de foco da HAL existentes para o uso e a zona especificados ID.

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

Além de registerFocusListener, essas solicitações são oneway para garantir que O Android não atrasa a HAL enquanto uma solicitação de foco é processada. A HAL precisa não espere para conseguir o foco antes de reproduzir sons críticos para a segurança. É opcional para que a HAL detecte e responda a mudanças na seleção de áudio IAudioControl#onAudioFocusChange:

Serviço de seleção de áudio para carros OEM

No Android 14, o AAOS lançou os serviços de plug-in de OEM para carros para permitir configuração para alguns componentes do carro. Para Car Audio Plugin Service, o plug-in. permite que OEMs gerenciem solicitações de foco interceptadas pelo áudio do carro serviço. Isso dá aos OEMs mais flexibilidade para gerenciar o foco conforme necessário. de acordo com regras e regulamentos. Assim, a interação da seleção de áudio pode ser diferente entre fabricantes e de região para região. Premissa básica para a seleção de áudio ainda é preciso, os apps ainda precisam solicitar a seleção para melhorar o gerenciamento do áudio para melhorar a experiência do usuário. Em geral, algumas regras ainda se aplicam ao áudio solicitação de foco por apps:

Sem foco de áudio de alta prioridade em pé (incluindo uma ligação, alerta de emergência ou notificação de segurança) vão poder receber áudio de forma temporária ou permanente.
Enquanto um foco de mídia estiver ativo:
- Os apps que solicitam foco no uso da chamada devem ser capazes de receber a chamada. de maneira simultânea ou exclusiva.
- Os apps que solicitam foco no uso da navegação precisam receber a navegação. de forma simultânea ou exclusiva.
- Os apps que solicitam foco de uso do Assistente devem receber foco de uso de forma simultânea ou exclusiva.
Em pé com foco de áudio de alta prioridade (incluindo uma ligação, alerta de emergência ou notificação de segurança) estão ativos, todos os a solicitação de seleção de áudio atrasada deve ser concedida ou atrasada conforme necessário.

As sugestões acima não incluem todas as possibilidades, mas podem ajudar os apps que solicitam focar para obter foco se não existirem sons de alta prioridade ativos. Mesmo quando for alta os sons prioritários estão ativos, e as solicitações de seleção atrasadas ainda precisam ser respeitadas. e precisa conseguir o foco quando o som de alta prioridade for interrompido.