Los nuevos servicios de complementos del OEM de automóviles en Android 14 permiten configurar algunos componentes del automóvil. Específicamente para el audio, se introducen tres nuevos servicios de complementos que permiten a los OEM configurar de forma flexible la administración de audio en dispositivos AAOS:
- Control del foco de audio
- Control de volumen y silencio del audio
- Control de autosilenciado de fondo
Arquitectura del servicio de complementos para automóviles
En la siguiente figura, se proporciona una descripción general de los servicios para automóviles y su relación con el servicio para automóviles del OEM. Al igual que los procesos de la app y del servicio del automóvil, el proceso del servicio del automóvil del OEM ocupa su propio espacio de proceso.
El servicio de automóvil inicia el servicio de automóvil 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 del automóvil debe anular las APIs para adquirir el servicio OEM de audio del automóvil:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Para ver un ejemplo, consulta la app de prueba de referencia definida en packages/services/Car/tests/OemCarServiceTestApp.
Aunque el servicio lo inicia el servicio de automóvil, no hereda automáticamente los permisos disponibles para el servicio de audio del automóvil. Por lo tanto, cualquier permiso que requieran los servicios del OEM se debe adquirir con el mecanismo adecuado. Por ejemplo, consulta packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml.
Servicio de audio para automóviles con arquitectura de servicio OEM
En AAOS, el servicio de audio del automóvil administra estas acciones:
- Enrutamiento de audio
- Enfoque de audio
- Autosilenciado de fondo
- Volumen y silencio
Antes de Android 14, este comportamiento era en gran medida estático y solo se podía modificar a través de la configuración, aunque para un conjunto muy limitado de casos. Android 14 introdujo un mecanismo para que el servicio de audio del automóvil se comunique 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 del automóvil y el servicio del OEM del automóvil. El servicio de audio del automóvil define diferentes hooks que pueden llamar al servicio de audio del OEM del automóvil para administrar el comportamiento del audio. Esto último solo ocurre si se define el componente de servicio de audio para automóvil del OEM correspondiente. De lo contrario, el servicio de audio del automóvil usa el comportamiento predeterminado.
Para garantizar que el servicio de audio del automóvil y el servicio de audio del OEM del automóvil estén siempre sincronizados, en cada llamada, el servicio de audio del automóvil pasa las partes requeridas del 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 enfoque de audio, pasa el estado actual de la pila al servicio de audio del OEM del automóvil. El estado actual incluye el titular del enfoque actual y los perdedores del enfoque actuales. Los elementos que pierden el enfoque son solicitudes de enfoque que siguen siendo parte de la pila, pero que perdieron el enfoque de forma temporal.
El servicio de audio del automóvil debe administrar toda la actividad de audio en el automóvil. Si el servicio de audio del automóvil no administra algunas partes del comportamiento del audio, la información expuesta al servicio de audio del OEM del automóvil estará incompleta. Por ejemplo, si un OEM anula el control del enfoque de audio en el servicio del automóvil registrando su propia política de enfoque de audio, el servicio de audio del automóvil no puede proporcionar información completa al servicio de audio del OEM del automóvil. Esto puede afectar la capacidad del servicio de audio del OEM del automóvil para tomar decisiones, ya que puede carecer de información que no es visible para el servicio de audio del automóvil.
Para realizar acciones, el servicio de audio del automóvil llama a los servicios del automóvil del OEM. Estas llamadas se realizan entre procesos, lo que requiere comunicación entre procesos (IPC). La IPC agrega latencia a cada llamada. Es importante minimizar la latencia en el servicio del OEM.
Dado que las llamadas al servicio de audio del automóvil al servicio del OEM son de bloqueo, el servicio del OEM no debe llamar al servicio de audio del automóvil en las evaluaciones directas de la API. En cambio, el servicio de audio del automóvil proporciona la información necesaria para que las llamadas entre los dos procesos solo deban viajar en una dirección.
Definiciones de servicios de audio para automóviles de OEM
Servicio de enfoque de audio para automóviles de OEM
El servicio de audio del automóvil administra las solicitudes de foco de audio de las apps registrando un objeto de escucha de foco de política de audio. El servicio de audio del automóvil tiene un mecanismo para administrar el comportamiento del enfoque según una matriz de interacción estática. La matriz define tres tipos diferentes de interacciones:
Interacción simultánea. Los titulares del foco pueden mantener el foco al mismo tiempo.
Interacciones exclusivas: La solicitud de enfoque entrante le quita el enfoque al titular del enfoque actual.
Rechaza la interacción. Se rechazó la solicitud de enfoque entrante según el titular del enfoque actual.
Si bien esto es suficiente para algunos casos de uso automotriz, no satisface todas las necesidades de interacción que pueden diferir debido a los requisitos del OEM. Para ello, presentamos OemCarAudioFocusService:
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
Se llama a la API de evaluateAudioFocusRequest desde el servicio de audio del automóvil cada vez que hay una solicitud de enfoque de audio que debe evaluarse. Es una API bidireccional que se bloquea hasta que se devuelven los resultados. La solicitud contiene información sobre el estado actual de la pila de audio:
Esta información se puede usar para evaluar el newFocusRequest en comparación con los titulares del enfoque actuales en focusHolders y los perdedores del enfoque actuales en focusLosers. La API debería devolver los resultados:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
Contiene la información sobre los resultados de la evaluación real en audioFocusEvaluationResults, que indica si se otorgó, retrasó o rechazó la solicitud actual. Cualquier cambio en la pila de enfoque actual se debe establecer en las entradas newLosers y newlyBlocked, según la naturaleza del cambio de pila.
Aquí, newLosers contiene entradas que antes mantenían el enfoque, pero que ahora deberían perderlo, ya sea de forma permanente o transitoria. Los que pierden el foco de forma permanente se quitarán de la pila de foco de audio, y los que lo pierden de forma transitoria se moverán a la pila de los que pierden el foco actual hasta que lo recuperen o se abandonen del solicitante de foco original. De todos modos, el objeto de escucha de enfoque para las solicitudes recibirá una pérdida de enfoque correspondiente.
La lista newlyBlocked contiene entradas que antes estaban en la lista de elementos que perdieron el enfoque, pero que ahora están bloqueadas por la entrada nueva. El bloqueo puede ser permanente o transitorio. Si el bloqueo del enfoque es permanente, la entrada se quitará de la pila y se enviará la pérdida de enfoque a los listeners de enfoque. En el caso de la pérdida de enfoque transitoria, la entrada permanecerá en la pila de elementos que perdieron el enfoque, pero se agregará un nuevo bloqueador de enfoque a su lista de bloqueadores. No se enviará ninguna pérdida de enfoque, ya que se envió una anteriormente cuando se bloqueó por primera vez. Finalmente, se desbloqueará la solicitud cuando se quiten todos los bloqueadores actuales, o bien se quitará de la pila si se abandona el enfoque.
La segunda API, notifyAudioFocusChange, es unidireccional y se llama en cada solicitud o abandono del enfoque de audio. La API se usa principalmente para informar al servicio del OEM sobre los cambios de enfoque, lo que puede afectar el comportamiento del servicio de audio para automóviles del OEM.
Lineamientos para la evaluación del enfoque
En AAOS, el enfoque de audio se usa para administrar la reproducción de audio y determinar qué app debe cumplir con los requisitos para brindar una experiencia óptima al usuario. Por lo tanto, el servicio de complementos del OEM debe tener en cuenta lo siguiente cuando administra una solicitud de enfoque de audio:
Sin ningún enfoque de audio de alta prioridad permanente (como una llamada telefónica, una emergencia o seguridad), las apps deberían poder obtener el enfoque de audio de forma transitoria o permanente.
Mientras un enfoque de medios está activo, las apps solicitan lo siguiente:
Enfoque de uso de llamadas, debe poder recibir el enfoque de forma simultánea o exclusiva.
El foco de uso de la navegación debe poder recibir el foco de forma simultánea o exclusiva.
Enfoque de uso del asistente, debe poder recibir el enfoque de forma simultánea o exclusiva.
Mientras las apps con enfoque de audio de alta prioridad (como una llamada telefónica, una alerta de emergencia o una alerta de seguridad) estén activas, cualquier solicitud de enfoque de audio entrante demorada se debe otorgar o demorar según sea necesario.
Si bien las sugerencias anteriores no son exhaustivas, pueden ayudar a garantizar que las apps que soliciten el enfoque puedan obtenerlo cuando no haya sonidos activos de alta prioridad. Incluso mientras los sonidos de prioridad alta están activos, se deben respetar las solicitudes de enfoque retrasadas y se debe poder obtener el enfoque una vez que se detiene el sonido de prioridad alta.
Servicio de volumen de automóviles del OEM
El servicio de audio del automóvil administra los eventos de la tecla de volumen escuchando los ajustes de volumen del sistema de audio o escuchando los eventos de la tecla de volumen directamente desde el servicio de entrada del automóvil. En cada caso, el comportamiento predeterminado del servicio de audio del automóvil es determinar qué grupo de volumen cambiar en función de los reproductores de audio activos y una lista de prioridad del contexto de audio.
Proporcionamos dos listas de prioridad de volumen. La primera lista considera todos los contextos de audio en este orden. La lista se presenta en orden descendente, con la prioridad más alta en la parte superior y la prioridad más baja en la parte inferior. Por ejemplo, si el audio de navegación y el audio de música están activos al mismo tiempo, el volumen de navegación cambia durante un evento de tecla de volumen.
- Navegación
- Llamar
- Música
- Anuncio
- 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 de teclas de volumen sea menos compleja, el servicio de audio del automóvil tiene una segunda lista de prioridad del contexto de audio:
- Llamar
- Contenido multimedia
- Anuncio
- Comando por voz
Esta lista también se presenta en orden descendente. El objetivo de esta segunda lista es permitir que los sonidos más comunes se cambien a través de eventos clave. Los sonidos poco comunes, tal vez de menor duración, solo se pueden administrar a través de la IU de configuración de audio.
La versión real del volumen se puede establecer con la configuración audioVolumeAdjustmentContextsVersion. La configuración se puede establecer en 1 o 2 (2 es el valor predeterminado).
Para proporcionar más flexibilidad a la administración de volumen, se introduce OemCarAudioVolumeService en Android 14:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
El servicio de volumen de audio del automóvil del OEM tiene un solo método, que toma un volumeAdjustment y un 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. Los duckedAttributes son todos los atributos de audio atenuados actualmente. El objeto 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 volumen se debe cambiar. Los resultados se deben devolver en OemCarVolumeChangeInfo:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
El valor booleano change indica si cambió algún volumen, y true indica que hay un cambio y que se debe actualizar el grupo de volumen. volumeGroupChanged es el grupo de volúmenes real que se debe cambiar. Este grupo debe cambiarse según el parámetro volumeAdjustment original que se pasó a la API. Por ejemplo, si los resultados indican que el grupo de volumen de navegación debe silenciarse, el valor booleano sería true y el grupo de volumen devuelto debería ser el de navegación.
Servicio de agachado de automóviles OEM
El servicio de audio del automóvil administra la reducción de audio supervisando los cambios de enfoque de audio y enviando un indicador a la HAL de AudioControl sobre qué dispositivos de audio reducir.
Cuando cambia el enfoque, se evalúan todos los titulares de enfoque activos para determinar cuál se debe reducir según este conjunto de reglas de reducción estática:
- Los sonidos de emergencia atenúan todo, excepto los sonidos de las llamadas
- La seguridad reduce el volumen de todo, excepto los sonidos de emergencia.
- La navegación reduce el volumen de todo, excepto los sonidos de seguridad y emergencia
- El Pato de llamadas silencia todo, excepto los sonidos de seguridad, emergencia y navegación.
- Los patos de voz interrumpen los sonidos de llamada
- La música y los anuncios deben reducirse por todo
Estas reglas no son exhaustivas y los OEM siguen siendo responsables de determinar cómo se deben atenuar los sonidos según estos lineamientos. Los OEM pueden controlar estas recomendaciones de forma más activa según los requisitos disponibles. En Android 14, se introduce OemCarDuckingService:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
Se llama a esta API desde el servicio de audio del automóvil cuando se producen cambios en el foco de audio. Reutiliza el OemCarAudioVolumeRequest introducido en el servicio de volumen de automóviles de OEM y contiene la información pertinente para tomar la decisión sobre qué atributos reducir. La lista de atributos de audio que se deben reducir de la API se compara con el estado de audio actual:
Atributo de audio que se está silenciando:
- En la lista, se sigue atenuando
- No está en la lista y la reducción de audio está desactivada
El atributo de audio no se reduce actualmente:
- En la lista, atenuado
- No está en la lista y la reducción de audio está desactivada
Luego, el servicio de audio del automóvil determina a qué dispositivos de salida de audio pertenecen los atributos de audio y los agrega a la lista de dispositivos de salida de audio atenuados o a la lista de dispositivos de audio sin atenuar, respectivamente. En última instancia, se envía al HAL de AudioControl para realizar la atenuación requerida a nivel del hardware.
En la siguiente figura, se muestra un diagrama de secuencia simplificado del control de reducción de audio para una solicitud de enfoque cuando se usa el servicio de reducción de OEM:
La secuencia comienza cuando una app solicita Administrar el foco de audio a través de las APIs públicas del administrador de audio. La solicitud se reenvía al servicio de audio del automóvil para determinar los resultados. Cuando se decide el enfoque de audio, el servicio de audio del automóvil evalúa la atenuación de audio llamando a OemCarAudioDuckingService para evaluar qué atributos de audio se deben atenuar. Una vez que la API de evaluateAttributesToDuck devuelve los resultados, se calculan los dispositivos de audio que se deben atenuar y, finalmente, se envía la información a AudioControl para aplicar la atenuación al hardware de audio.
Implementación de 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 OemCarService, junto con OemCarAudioFocusService, OemCarAudioDuckingService y OemCarAudioVolumeService. En el último caso, cada servicio usa un archivo XML para cargar un comportamiento estático. Por ejemplo, OemCarAudioFocusServiceImp carga el 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 servicios para automóviles del OEM forma parte del código fuente de AOSP. Los OEM pueden realizar cambios según sus necesidades. Para la depuración, usa la configuración de config_oemCarService 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 de automóvil del OEM use el comando dump del servicio de automóvil para el servicio del OEM, haz lo siguiente:
adb shell dumpsys car_service --oem-service
Los resultados podrían ser similares a los que se muestran a continuación:
***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 de cada lote de información de dump determina el estado de la función y el servicio. Por ejemplo, la información de volcado mIsOemServiceReady especifica si el servicio está listo para usarse, donde true indica que está listo y false indica que no está listo.