Os novos serviços de plug-in de OEM para carros no Android 14 permitem alguns componentes do carro para serem configurados. Especificamente para o áudio, três novas serviços de plug-in são introduzidos, permitindo que OEMs configurem gerenciamento de áudio em dispositivos AAOS:
- Controle de foco de áudio
- Controle de volume e desativação do áudio
- Controle de redução de áudio
Arquitetura de serviço do plug-in do carro
A figura abaixo mostra uma visão geral dos serviços do carro e a relação entre eles ao serviço automotivo do OEM. Semelhante aos processos de apps e de manutenção do carro, o processo de conserto de carros de OEM ocupa um espaço de processamento próprio.
O serviço automobilístico inicia a manutenção automotiva do OEM encontrando o componente definido em
config_oemCarService: Se a configuração estiver vazia, o serviço do OEM não existe.
e nenhum serviço é iniciado. O componente precisa ter extensão
OemCarService (link em inglês).
O serviço de áudio do carro precisa substituir as APIs para adquirir o OEM de áudio do carro
serviço:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Para
exemplo, consulte
o app de teste de referência definido
packages/services/Car/tests/OemCarServiceTestApp
Mesmo que o serviço seja iniciado pelo serviço veicular, ele não é ativado automaticamente
herdam as permissões disponíveis para o serviço de áudio do carro. Dessa forma, qualquer
a permissão exigida por serviços de OEM deve ser adquirida com as devidas
mecanismo de atenção. Por exemplo, consulte
packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml:
Serviço de áudio para carros com arquitetura de serviço de OEM
No AAOS, o serviço de áudio do carro gerencia estas ações:
- Roteamento de áudio
- Seleção de áudio
- Redução de áudio
- Volume e desativação do som
Antes do Android 14, esse comportamento era em grande parte estático e só podem ser modificadas por configurações, ainda que em um conjunto muito limitado de casos. O Android 14 introduziu um mecanismo para áudio de carro se comunique com um componente definido pelo OEM que gerencia:
- Seleção de áudio
- Redução de áudio
- Volume e desativação do som
A figura abaixo mostra uma arquitetura simplificada para o serviço de áudio do carro e serviço de OEM do carro. O serviço de áudio do carro define diferentes ganchos que podem chamar o serviço de áudio do OEM do carro para gerenciar o comportamento de áudio. O último caso ocorre apenas se o componente correspondente do serviço de áudio do carro do OEM estiver definido. Caso contrário, o serviço de áudio do carro usa o comportamento padrão.
Para garantir que os serviços de áudio do carro e do OEM do carro estejam sempre ativados para cada chamada, o serviço de áudio do carro passa pelas partes necessárias do estado atual da pilha de áudio para o serviço de áudio do OEM do carro. Por exemplo, quando o serviço de áudio do carro intercepta uma solicitação para avaliar a seleção de áudio, passa o estado atual da pilha para o serviço de áudio do OEM do carro. O estado atual inclui o detentor de foco atual e os perdedores de foco atuais. Perdedores de foco são solicitações de foco que ainda fazem parte da pilha, mas que perderam temporariamente foco.
O serviço de áudio do carro precisa gerenciar toda a atividade de áudio do carro. Se o carro serviço de áudio não gerencia algumas partes do comportamento do áudio, as informações expostas ao serviço de áudio do OEM do carro estão incompletas. Por exemplo, se um OEM substitui o tratamento da seleção de áudio no serviço do carro registrando uma política própria de seleção de áudio, o serviço de áudio do carro não poderá oferecer ao serviço de áudio do OEM do carro. Isso pode afetar a capacidade do carro Serviço de áudio do OEM para tomar decisões, porque pode faltar informações não visíveis para o serviço de áudio do carro.
Para realizar ações, o serviço de áudio do carro chama os serviços do OEM para carros. Essas chamadas são feitas entre processos, o que exige a comunicação entre processos (IPC). IPC adiciona latência a cada chamada. É importante minimizar a latência Serviço de OEM.
Como as chamadas de serviço de áudio do carro para o serviço de OEM estão bloqueando, esse serviço não podem chamar o serviço de áudio do carro em avaliações diretas da API. Em vez disso, serviço de áudio do carro fornece as informações necessárias para que as chamadas entre os dois processos só precisam se deslocar em uma direção.
Definições de serviços de áudio para carros de OEM
Serviço de seleção de áudio para carros OEM
O serviço de áudio do carro gerencia solicitações de seleção de áudio de apps com o registro um listener de foco na política de áudio. O serviço de áudio do carro tem um mecanismo para gerenciar o comportamento de foco baseado em um modelo Matriz de interação. A matriz define três tipos diferentes de interações:
Interação simultânea. Os fixadores de foco podem manter o foco ao mesmo tempo de resposta.
Interações exclusivas. A solicitação de seleção recebida toma o foco da detentor de foco atual.
Recusar interação. Solicitação de foco recebida rejeitada com base em do detentor de foco atual.
Embora isso seja suficiente para alguns casos de uso automotivos, ele não atende a todos os
necessidades de interação que podem ser diferentes devido aos requisitos do OEM. Para isso,
apresente o OemCarAudioFocusService:
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
A API evaluateAudioFocusRequest é chamada pelo serviço de áudio do carro a qualquer momento
houver uma solicitação de seleção de áudio que precisa ser avaliada, é um método bidirecional
API que bloqueia o retorno dos resultados. A solicitação contém informações
sobre o estado atual da pilha de áudio:
Essas informações podem ser usadas para avaliar o newFocusRequest em comparação com
os detentores de foco atuais em focusHolders e os perdedores de foco atuais em
focusLosers A API vai retornar os resultados:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
Ele contém as informações sobre os resultados reais da avaliação em
audioFocusEvaluationResults, que indica se a solicitação atual tem
foi concedido, atrasado ou falhou. Qualquer mudança na pilha de foco atual
precisa ser definido nas entradas newLosers e newlyBlocked, dependendo da natureza do elemento.
da mudança na pilha.
Em que newLosers contém entradas que anteriormente tinham o foco, mas
vai perder o foco, seja de forma permanente ou temporária. Perdedores de foco permanentes
serão removidos da pilha de foco de áudio e os perdedores de foco transitórios
serão movidos para a pilha atual de perdedores de foco até recuperarem o foco ou
abandonado pelo solicitante original. Independentemente disso, o ouvinte de foco
as solicitações vão receber
uma perda de foco correspondente.
A lista newlyBlocked contém entradas que estavam anteriormente no perdedor de foco
lista, mas agora são bloqueados pela nova entrada. O bloqueio pode ser permanente ou
temporário. Quando o foco estiver bloqueado, a entrada será removida da pilha.
e a perda de foco será enviada
para os listeners de foco. Para a perda de foco transitória,
a entrada permanecerá na pilha de perdedores de foco, mas um novo bloqueador de foco será
adicionado à lista de bloqueadores, nenhuma perda de foco será enviada como anteriormente.
enviado quando foi bloqueado pela primeira vez. A solicitação será desbloqueada quando todos
os bloqueadores atuais são removidos ou serão removidos da pilha se o foco for
abandonado.
A segunda API, notifyAudioFocusChange, é uma maneira de chamar a cada
solicitação ou abandono da seleção de áudio. A API é usada principalmente para informar o serviço do OEM
sobre mudanças de foco, o que pode afetar o comportamento do serviço de áudio do carro do OEM.
Diretrizes para a avaliação de foco
No AAOS, a seleção de áudio é usada para gerenciar a reprodução de áudio e determinar que o app precisa aderir para oferecer uma experiência ideal ao usuário. Assim, o serviço de plug-in OEM precisa considerar o seguinte ao gerenciar uma solicitação de seleção de áudio:
Sem foco de áudio de alta prioridade em pé (como uma ligação, emergência ou segurança) devem ter a seleção de áudio temporária ou permanentemente.
Com o foco de mídia ativo, os apps que solicitam:
Foco no uso da chamada (precisa ser capaz de receber foco simultaneamente) ou exclusivamente.
Foco de uso da navegação: deve ser capaz de receber foco de maneira simultânea ou exclusiva.
Foco de uso do Google Assistente. Deve ser capaz de receber foco de maneira simultânea ou exclusiva.
Ao permanecer em pé com foco de áudio de alta prioridade (como uma chamada telefônica, alerta ou alerta de segurança) estão ativos, qualquer seleção de áudio com atraso a solicitação deve ser concedida ou atrasada, conforme necessário.
As sugestões acima não incluem todas as possibilidades, mas podem ajudar a garantir que os apps que solicitam foco precisam ser capazes de definir o foco quando não há nenhuma sons de alta prioridade. Mesmo com sons de alta prioridade ativos, o foco atrasado as solicitações ainda devem ser respeitadas e receber foco assim que o som de alta prioridade é interrompido.
Serviço de volume de carros OEM
O serviço de áudio do carro gerencia eventos de tecla de volume ouvindo o volume ajustes do sistema de áudio ou ouvindo eventos das teclas de volume diretamente do serviço de entrada do carro. Em cada caso, o comportamento padrão do carro serviço de áudio é determinar qual grupo de volumes alterar com base no players de áudio e uma lista de prioridade de contexto de áudio.
Oferecemos duas listas de prioridade de volume. A primeira lista considera todos os áudios contextos nessa ordem. A lista é apresentada em ordem decrescente, ou seja, a prioridade é a prioridade mais alta, e a mais baixa, a prioridade mais baixa. Por exemplo, se o áudio de navegação e o áudio de música estejam ativos ao mesmo tempo, o volume da navegação é alterado durante um evento da tecla de volume.
- Navegação
- Ligar
- Música
- Aviso
- Comando de voz
- Toque da chamada
- Som do sistema
- Segurança
- Alarme
- Notificação
- Status do veículo
- Emergência
Para tornar o gerenciamento de eventos das teclas de volume menos complexo, o serviço de áudio do carro tem um segunda prioridade de contexto de áudio:
- Ligar
- Mídia
- Aviso
- Comando de voz
Essa lista também é apresentada em ordem decrescente. O objetivo dessa lista de ações é permitir que sons mais comuns sejam alterados com eventos de tecla. Incomum, talvez sons de menor duração, podem ser gerenciados nas configurações de áudio Somente interface.
A versão real do volume pode ser definida com o
audioVolumeAdjustmentContextsVersion. A configuração pode ser
Defina como 1 ou 2 (o padrão é 2).
Para oferecer mais flexibilidade
ao gerenciamento de volume,
O OemCarAudioVolumeService foi lançado no Android 14:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
O serviço OEM de volume de áudio para carros tem um único método, que recebe um
volumeAdjustment e um OemCarAudioVolumeRequest:
class OemCarAudioVolumeRequest {
int audioZoneId;
int callState;
List<AudioAttributes> activePlaybackAttributes;
List<AudioAttributes> duckedAttributes;
List<CarVolumeGroupInfo> volumeGroupState;
}
O activePlaybackAttributes da solicitação tem os atributos de áudio ativos. A
duckedAttributes são todos os atributos de áudio reduzidos no momento. A
volumeGroupState tem o estado atual do grupo de volumes. A solicitação
representa o estado atual da pilha de áudio e pode ser usado para determinar
qual grupo de volumes deve ser alterado. Os resultados devem ser retornados em
OemCarVolumeChangeInfo:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
O booleano change indica se algum volume foi alterado, true indica que
houver uma mudança e o grupo de volumes será atualizado. A
volumeGroupChanged é o grupo de volumes real que precisa ser alterado. Isso
O grupo precisa ser alterado de acordo com o parâmetro volumeAdjustment original.
passados para a API. Por exemplo, se os resultados indicarem que a navegação
o grupo de volumes deve ser silenciado, o booleano será true e o
precisa ser usado para navegação.
Serviço de atenuação de carros de OEM
O serviço de áudio do carro gerencia a redução de áudio monitorando mudanças na seleção de áudio e
enviar um sinal para a HAL AudioControl sobre quais dispositivos de áudio reduzir.
Quando o foco muda, todos os detentores de foco ativos são avaliados para determinar
que deve ser diminuída com base
neste conjunto de abaixamento estático
rules:
- Os sons de emergência abastecem tudo, exceto os sons de chamada
- A segurança agacha tudo, exceto sons de emergência
- A navegação apaga tudo, exceto sons de segurança e emergência
- Chame patos para tudo, exceto sons de segurança, emergência e navegação
- Sons de toque de chamada dos patos do Voice
- Músicas e anúncios devem ser abatidos por tudo
Essas regras não incluem todas as possibilidades, e os OEMs continuam sendo responsáveis por determinar
como os sons devem ser diminuídos
com base nessas diretrizes. Os OEMs podem controlar esses
as recomendações de forma mais ativa
com base nos requisitos disponíveis. A
O OemCarDuckingService foi lançado no Android 14:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
Essa API é chamada no serviço de áudio do carro quando a seleção de áudio muda. Ele reutiliza
o OemCarAudioVolumeRequest introduzido no
OEM do volume de carro do OEM e contém os
informações para tomar a decisão sobre quais atributos devem ser patos. A lista de
Os atributos de áudio da API para reduzir os valores são comparados ao estado de áudio atual:
Atributo de áudio reduzido no momento:
- Na lista, continua a ser reduzido
- Não está na lista, a redução de áudio está desativada
Atributo de áudio não reduzido no momento:
- Na lista, abaixado
- Não está na lista, a redução de áudio está desativada
Em seguida, o serviço de áudio do carro determina em quais dispositivos de saída de áudio o áudio a que pertencem e os adiciona à lista de dispositivos de saída de áudio reduzidos ou ao lista de dispositivos de áudio não disponíveis, respectivamente. Em última análise, isso é enviado ao HAL AudioControl para executar a redução necessária no nível do hardware.
A figura abaixo mostra um diagrama de sequência simplificado da redução de áudio para uma solicitação de foco quando o serviço de redução de OEM é usado:
A sequência começa quando um app solicita
Gerenciar a seleção de áudio
usando APIs de gerenciadores de áudio públicos. A solicitação é encaminhada para o áudio do carro
para determinar os resultados. Quando a seleção de áudio é decidida, a redução de áudio é
é avaliado pelo serviço de áudio do carro chamando o OemCarAudioDuckingService para
avaliar quais atributos de áudio precisam ser reduzidos. Quando os resultados forem retornados
da API evaluateAttributesToDuck, os dispositivos de áudio para a redução são computados,
e, por fim, a informação é enviada ao AudioControl para aplicar a redução de
ao hardware de áudio.
Implementação de referência do serviço de áudio do carro do OEM
A AAOS fornece uma implementação de referência do serviço automotivo de OEM em
packages/services/Car/tests/OemCarServiceTestApp, que implementa o
OemCarService, com OemCarAudioFocusService,
OemCarAudioDuckingService e OemCarAudioVolumeService. Para este último,
cada serviço usa e um arquivo XML para carregar um comportamento estático. Por exemplo:
OemCarAudioFocusServiceImp carrega o oem_focus_config.xml, que
que contém uma matriz de interação. A matriz é usada para avaliar a solicitação de foco
quando o evaluateAudioFocusRequest é chamado.
Referência à depuração do app de teste
O app de teste de serviços automotivos do OEM faz parte do código-fonte do AOSP. OEMs podem tornar
muda de acordo com suas necessidades. Para depuração, use o config_oemCarService
para ativar o app de teste.
<!-- This is the component name for the OEM customization service. OEM can choose to implement
this service to customize car service behavior for different policies. If OEMs choose to
implement it, they have to implement a service extending OemCarService exposed by car-lib,
and implement the required component services.
If the component name is invalid, CarService would not connect to any OEM service.
Component name can not be a third party package. It should be pre-installed -->
<string name="config_oemCarService" translatable="false">
com.android.car.oemcarservice.testapp/.OemCarServiceImpl
</string>
Para verificar o serviço do carro do OEM, use o comando dump do serviço veicular para o
Serviço de OEM:
adb shell dumpsys car_service --oem-service
Os resultados podem ser semelhantes à saída abaixo:
***CarOemProxyService dump***
mIsFeatureEnabled: true
mIsOemServiceBound: true
mIsOemServiceReady: true
mIsOemServiceConnected: true
mInitComplete: true
OEM_CAR_SERVICE_CONNECTED_TIMEOUT_MS: 5000
OEM_CAR_SERVICE_READY_TIMEOUT_MS: 5000
mComponentName: com.android.car.oemcarservice.testapp/.OemCarServiceImpl
Cada booleano em cada lote de informações dump determina o estado do atributo
e serviço. Por exemplo, a informação de despejo mIsOemServiceReady especifica se o
serviço está pronto para ser usado, em que true indica que está pronto e false
indica que ele não está pronto.