Los nuevos servicios del complemento OEM para vehículos en Android 14 habilitan configurar algunos componentes del vehículo. En el caso del audio, de complementos, que permiten a los OEM configurar Administración de audio en dispositivos AAOS:
- Control de foco de audio
- Control de silencio y volumen del audio
- Control de autosilenciado de fondo
Arquitectura del servicio del complemento para vehículos
En la siguiente figura, se proporciona una descripción general de los servicios para automóviles y su relación al servicio de automóviles del OEM. Al igual que los procesos de la aplicación y del servicio de mantenimiento del automóvil, el proceso del servicio de automóviles del OEM ocupa su propio espacio de procesos.
El servicio de reparación de automóviles inicia el servicio de reparación de automóviles del OEM buscando el componente definido en
config_oemCarService Si la configuración está vacía, el servicio del OEM no existe.
y no se inicia ningún servicio. El componente debe extender
OemCarService
El servicio de audio para vehículos debe reemplazar las APIs para adquirir el OEM de audio para vehículos.
servicio:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Para
ejemplo, consulta
la aplicación de prueba de referencia definida en
packages/services/Car/tests/OemCarServiceTestApp
Si bien el servicio se inicia con un servicio de automóvil, no se activa
heredarán los permisos disponibles
para el servicio de audio del automóvil. Por lo tanto, cualquier
el permiso requerido por los servicios del OEM se debe adquirir con la
de atención. Por ejemplo, consulta
packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml
Servicio de audio para automóviles con arquitectura de servicio del OEM
En AAOS, el servicio de audio para automóviles administra estas acciones:
- Enrutamiento de audio
- Enfoque de audio
- Autosilenciado de fondo
- Volumen y silencio
Antes de Android 14, este comportamiento era mayormente estático y solo se puede modificar a través de la configuración, aunque en un conjunto muy limitado de casos. Android 14 introdujo un mecanismo para el audio de vehículos para comunicarse con un componente definido por el OEM que administra lo siguiente:
- Enfoque de audio
- Autosilenciado de fondo
- Volumen y silencio
En la siguiente figura, se muestra una arquitectura simplificada para el servicio de audio para vehículos y servicio del OEM del automóvil. El servicio de audio del auto define diferentes ganchos que pueden llamar el servicio de audio del OEM del automóvil para administrar el comportamiento del audio. Esto último ocurre solo si se define el componente del servicio de audio para automóviles del OEM correspondiente. De lo contrario, el el servicio de audio para automóviles usa el comportamiento predeterminado.
Para garantizar que el servicio de audio del automóvil y el servicio de audio del OEM siempre estén activados, de audio, para cada llamada, el servicio de audio del automóvil pasa las partes requeridas de la estado actual de la pila de audio al servicio de audio del OEM del automóvil Por ejemplo, cuando el servicio de audio del automóvil intercepta una solicitud para evaluar el foco de audio, la pasa el estado actual de la pila al servicio de audio del OEM del automóvil El estado actual incluye el contenedor de enfoque actual y los perdedores actuales. Los perdedores de enfoque que siguen siendo parte de la pila, pero que se han perdido temporalmente tu enfoque.
El servicio de audio del vehículo debe administrar toda la actividad de audio en el vehículo. Si el vehículo servicio de audio no administra algunas partes del comportamiento de audio, la la información expuesta al servicio de audio del OEM del automóvil está incompleta. Por ejemplo, un OEM reemplaza el manejo del foco de audio en el servicio del vehículo al registrar su propia política de foco de audio, el servicio de audio del auto al servicio de audio del OEM del automóvil. Esto puede afectar la capacidad del vehículo Servicio de audio de OEM para tomar decisiones, ya que puede carecer de información no visible al servicio de audio del automóvil.
Para realizar acciones, el servicio de audio llama al servicio de automóviles del OEM. Estas llamadas se realizan en procesos, lo que requiere comunicación entre procesos (IPC). IPC agrega latencia a cada llamada. Es importante minimizar la latencia servicio de OEM.
Como las llamadas del servicio de audio del automóvil al servicio del OEM se bloquean, el servicio del OEM No debe llamar al servicio de audio para vehículos con evaluaciones directas de la API. En cambio, el servicio de audio del auto brinda la información necesaria para que las llamadas entre dos procesos solo necesitan desplazarse en una dirección.
Definiciones del servicio de audio para automóviles del OEM
Servicio de foco de audio para automóviles del OEM
El servicio de audio para automóviles registra las solicitudes de foco de audio de las apps un objeto de escucha de enfoque de política de audio. El servicio de audio del automóvil tiene un mecanismo para administrar de enfoque basado en una configuración Matriz de interacción. La matriz define tres tipos diferentes de interacciones:
Interacciones simultáneas. Los titulares de enfoque pueden mantener el enfoque al mismo tiempo.
Interacciones exclusivas. La solicitud de enfoque entrante toma el enfoque del contenedor de foco actual.
Rechaza la interacción. Se rechazó la solicitud de enfoque entrante según el contenedor de foco actual.
Si bien esto es suficiente para algunos casos de uso de la industria automotriz, no cumple con todos los
necesidades de interacción que pueden diferir debido a los requisitos del OEM. Para ello,
Introduce el OemCarAudioFocusService:
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
Se llama a la API evaluateAudioFocusRequest desde el servicio de audio para vehículos en cualquier momento.
hay una solicitud de foco de audio que debe evaluarse, es una solicitud
que bloquea los resultados para que se devuelvan. La solicitud contiene información
acerca del estado actual de la pila de audio:
Esta información se puede usar para evaluar el newFocusRequest en comparación con el
contenedores de enfoque actuales en focusHolders y los perdedores actuales de enfoque en
focusLosers La API debería mostrar los resultados:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
Contiene la información sobre los resultados reales de la evaluación
audioFocusEvaluationResults, que indica si la solicitud actual tiene
se otorgó, se retrasó o falló. Cualquier cambio en la pila de enfoque actual
se debe establecer en entradas newLosers y newlyBlocked, según la naturaleza
del cambio en la pila.
Donde el newLosers contiene entradas que antes mantenían el foco, pero
ahora debería perder el foco, ya sea de forma permanente o transitoria. Perdedores del enfoque permanente
se quitará aún más de la pila de foco de audio y los perdedores de enfoque transitorios
se moverán a la pila de perdedores del enfoque actual hasta que recuperen el enfoque o
abandonado del solicitante de foco original. De cualquier manera, el oyente de enfoque para
las solicitudes recibirán el foco perdido correspondiente.
La lista newlyBlocked contiene entradas que antes estaban en el perdedor del enfoque.
pero ahora están bloqueadas por la nueva entrada. El bloqueo puede ser permanente o
transitorio; para el enfoque permanente bloqueado, la entrada se quitará de la pila
y la pérdida de foco se enviarán a los objetos de escucha de enfoque. Para la pérdida transitoria del foco,
la entrada permanecerá en la pila de perdedores del enfoque, pero se implementará un nuevo bloqueador del enfoque
agregado a su lista de bloqueador, no se enviará ninguna pérdida de foco como se había hecho anteriormente
enviado cuando se bloqueó por primera vez. Finalmente, la solicitud se desbloqueará cuando
se quitan los bloqueadores actuales o de la pila si el enfoque está
abandonados.
La segunda API, notifyAudioFocusChange, es una forma unidireccional a la que se llama en cada
una solicitud o un abandono del foco de audio. La API se usa principalmente para brindar información al servicio del OEM
sobre los cambios de enfoque, que podrían afectar el comportamiento del servicio de audio para automóviles del OEM.
Lineamientos para la evaluación del enfoque
En AAOS, el foco de audio se usa para administrar la reproducción de audio y determinar qué app debe cumplir para brindar una experiencia óptima al usuario. Por lo tanto, el servicio del complemento de OEM debe tener en cuenta lo siguiente al administrar un solicitud de foco de audio:
Sin enfoque de audio de alta prioridad permanente (como una llamada telefónica, las apps de emergencia o seguridad) deben poder obtener foco de audio transitoria o permanentemente.
Mientras un enfoque multimedia está activo, las apps que solicitan lo siguiente:
Enfoque de uso de llamadas, debe poder recibir el enfoque al mismo tiempo o exclusivamente.
Enfoque de uso de navegación, debe poder recibir el enfoque de forma simultánea o exclusiva.
Enfoque en el uso de Asistente, debe poder recibir el enfoque de forma simultánea o exclusiva.
Al estar de pie, el foco de audio de alta prioridad (como una llamada telefónica, (alertas o alertas de seguridad) estén activas, cualquier foco de audio retrasado la solicitud debe aprobarse o retrasarse según sea necesario.
Si bien las sugerencias anteriores no son exhaustivas, pueden ayudar a garantizar que Las apps que lo solicitan deben poder enfocarse cuando no hay actividad los sonidos de prioridad alta. Incluso cuando los sonidos de prioridad alta están activos, el enfoque retrasado las solicitudes deben seguir respetando y deberían poder enfocarse una vez que el el sonido de prioridad alta se detendrá.
Servicio de volumen de autos del OEM
El servicio de audio para automóviles administra los eventos de tecla de volumen escuchando el volumen ajustes desde el sistema de audio o escuchando eventos de teclas de volumen directamente del servicio de entrada de vehículos. En cada caso, el comportamiento predeterminado servicio de audio es determinar qué grupo de volúmenes cambiar en función del reproductores de audio y una lista de prioridades de contexto de audio.
Proporcionamos dos listas de prioridad de volumen. La primera lista considera todo el audio contextos en este orden. La lista se presenta en orden descendente, el más alto prioridad en la parte superior y la menor prioridad en la parte inferior. Por ejemplo, el audio de navegación y el audio musical están activos al mismo tiempo y, luego, el volumen de navegación se cambia durante un evento de tecla de volumen.
- Navegación
- Llamar
- Música
- Aviso
- Comando por voz
- Sonido de llamada
- Sonido del sistema
- Seguridad
- Alarma
- Notificación
- Estado del vehículo
- Emergencia
Para que la administración de eventos clave de volumen sea menos compleja, el servicio de audio para automóviles tiene un segunda prioridad de contexto de audio:
- Llamar
- Contenido multimedia
- Aviso
- Comando por voz
Esta lista también se presenta en orden descendente. El propósito de esta lista de segundos es permitir que se cambien los sonidos más comunes mediante eventos clave. Poco común, tal vez los sonidos de menor duración, se pueden gestionar a través de la configuración de audio IU únicamente.
La versión real del volumen se puede establecer con el
Configuración de audioVolumeAdjustmentContextsVersion. La configuración se puede
Se establece en 1 o 2 (2 es la configuración predeterminada).
Para brindar más flexibilidad a la administración del volumen,
OemCarAudioVolumeService se introdujo en Android 14:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
El servicio OEM para el volumen del audio del automóvil tiene un único método, que toma un
volumeAdjustment y OemCarAudioVolumeRequest:
class OemCarAudioVolumeRequest {
int audioZoneId;
int callState;
List<AudioAttributes> activePlaybackAttributes;
List<AudioAttributes> duckedAttributes;
List<CarVolumeGroupInfo> volumeGroupState;
}
El activePlaybackAttributes de la solicitud tiene los atributos de audio activos. El
duckedAttributes son todos los atributos de audio atenuados en este momento. El
volumeGroupState tiene el estado actual del grupo de volúmenes. La solicitud
representa el estado actual de la pila de audio y se puede usar para determinar
qué grupo de volúmenes se debe cambiar. Los resultados deberían devolverse en
OemCarVolumeChangeInfo:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
El valor booleano change indica si cambió algún volumen, y true indica lo siguiente:
hay un cambio, y el grupo de volúmenes debería estar actualizado. El
volumeGroupChanged es el grupo de volúmenes real que se debe cambiar. Esta
el grupo se debe cambiar de acuerdo con el parámetro volumeAdjustment original
pasan a la API. Por ejemplo, si los resultados indican que la navegación
el grupo de volúmenes se debe silenciar, el valor booleano será true y el que se mostrará
para la navegación.
Servicio de autosilenciado de autos OEM
El servicio de audio del automóvil administra el autosilenciado de fondo supervisando los cambios del foco del audio y
enviando una señal a la HAL de AudioControl para indicar qué dispositivos de audio debes atenuar.
Cuando cambia el enfoque, se evalúan todos los contenedores de enfoque activos para determinar
que debe reducirse según este conjunto de autosilenciado estático
reglas:
- Los sonidos de emergencia silencian todo, excepto los sonidos de llamada
- La seguridad atenúa todo, excepto los sonidos de emergencia
- La navegación atenúa todo, excepto los sonidos de seguridad y emergencia
- Las llamadas atenúan todo, excepto los sonidos de seguridad, emergencia y navegación
- La voz de patos hace sonar el tono de la llamada
- La música y los anuncios deben estar ocultos por todo.
Estas reglas no son exhaustivas, y los OEM siguen siendo responsables de determinar
y cómo se debe reducir el volumen de los sonidos según estas pautas. Los OEM pueden controlar estas
recomendaciones de forma más activa en función de los requisitos disponibles. El
OemCarDuckingService se introdujo en Android 14:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
El servicio de audio para vehículos llama a esta API en cambios de foco de audio. Reutiliza
el OemCarAudioVolumeRequest que se introdujo en
Servicio de volumen de vehículos del OEM y contiene las
información para tomar la decisión sobre qué atributos pato. La lista de
los atributos de audio para duck desde la API se comparan con el estado de audio actual:
Atributo de audio atenuado actualmente:
- En la lista, sigue disminuyendo
- No está en la lista, se desactivó el autosilenciado de fondo
El atributo de audio no atenuó el volumen actualmente:
- En la lista, atenuado
- No está en la lista, se desactivó el autosilenciado de fondo
Luego, el servicio de audio del vehículo determina con qué dispositivos de salida a los que pertenecen y los agrega a la lista de dispositivos de salida de audio dispositivos de audio sin atenuar, respectivamente. En última instancia, esto se envía al HAL de AudioControl para realizar la requería la disminución automática del volumen a nivel de hardware.
En la siguiente figura, se muestra un diagrama de secuencia simplificado del autosilenciado de fondo Control para una solicitud de foco cuando se usa el servicio de autosilenciado de fondo:
La secuencia comienza cuando una app solicita
Cómo administrar el foco de audio
a través de las APIs públicas del administrador de audio. La solicitud se reenvía al audio del vehículo
para determinar los resultados. Cuando se decide el foco de audio, el autosilenciado de fondo
lo evalúa el servicio de audio del vehículo que llama a OemCarAudioDuckingService para
evaluar qué atributos de audio se deben atenuar. Cuando se devuelven los resultados
desde la API de evaluateAttributesToDuck, se calculan los dispositivos de audio para ocultarlos
Por último, la información se envía a AudioControl para aplicar el autosilenciado de fondo.
al hardware de audio.
Implementación de la referencia del servicio de audio para automóviles del OEM
AAOS proporciona una implementación de referencia del servicio para automóviles del OEM en
packages/services/Car/tests/OemCarServiceTestApp, que implementa la
OemCarService, junto con OemCarAudioFocusService,
OemCarAudioDuckingService y OemCarAudioVolumeService. Para el último,
usa cada servicio y un archivo en formato XML para cargar un comportamiento estático. Por ejemplo:
OemCarAudioFocusServiceImp carga oem_focus_config.xml, que
contiene una matriz de interacción. La matriz se usa para evaluar la solicitud de enfoque.
cuando se llama a evaluateAudioFocusRequest.
Depuración de la app de prueba de referencia
La app de prueba de servicio para automóviles del OEM es parte del código fuente del AOSP. Los OEM pueden hacer
cambia según sus necesidades. Para la depuración, usa config_oemCarService.
actual para habilitar la app de prueba.
<!-- 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 que el servicio para vehículos del OEM use el comando dump correspondiente a la
Servicio de OEM:
adb shell dumpsys car_service --oem-service
El resultado podría ser similar al siguiente:
***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 valor booleano en cada lote de información de dump determina el estado del atributo.
y servicio. Por ejemplo, la información de volcado mIsOemServiceReady especifica si el elemento
servicio está listo para usarse, donde true indica que está listo y false
indica que no está listo.