Los nuevos servicios de complementos de OEM para automóviles en Android 14 permiten configurar algunos componentes del automóvil. En particular, para el audio, se presentan tres nuevos servicios de complementos que permiten a los OEMs configurar de forma flexible la administración de audio en dispositivos AAOS:
- Control de foco de audio
- Control de volumen y silencio de 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 de automóviles y su relación con el servicio de automóviles del OEM. Al igual que los procesos de la app y el proceso de servicio del automóvil, el proceso de servicio del automóvil del OEM ocupa su propio espacio de proceso.
El servicio de automóviles inicia el servicio 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 servicio OEM de audio para vehículos:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Por
ejemplo, consulta
la app de prueba de referencia definida en
packages/services/Car/tests/OemCarServiceTestApp.
Aunque el servicio de automóvil lo inicia, 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 debe adquirirse 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 de OEM
En el AAOS, el servicio de audio para automóviles administra las siguientes acciones:
- Enrutamiento de audio
- Enfoque de audio
- Autosilenciado de fondo
- Volumen y silenciamiento
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 silenciamiento
En la siguiente figura, se muestra una arquitectura simplificada del servicio de audio para automóviles y del servicio de OEM de automóviles. El servicio de audio para vehículos define diferentes hooks que pueden llamar al servicio de audio del OEM del vehículo para administrar el comportamiento de audio. Esto último solo ocurre si se define el componente correspondiente del servicio de audio para automóviles del OEM. De lo contrario, 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 del automóvil siempre estén sincronizados, para 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 de enfoque actual y los perdedores de enfoque actuales. Los perdedores de enfoque son solicitudes de enfoque que aún forman parte de la pila, pero que perdieron el enfoque temporalmente.
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 de audio, la información expuesta al servicio de audio del OEM del automóvil no está completa. Por ejemplo, si un OEM reemplaza el control de 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 OEM del automóvil para tomar decisiones, ya que puede faltar información que no es visible para el servicio de audio del automóvil.
Para realizar acciones, el servicio de audio para automóviles llama a los servicios de automóviles del OEM. Estas llamadas se realizan entre procesos, lo que requiere comunicación entre procesos (IPC). El IPC agrega latencia a cada llamada. Es importante minimizar la latencia en el servicio del OEM.
Dado que las llamadas del servicio de audio para automóviles al servicio del OEM se bloquean, el servicio del OEM no debe llamar al servicio de audio para automóviles en las evaluaciones directas de la API. En cambio, el servicio de audio para automóviles proporciona la información necesaria para que las llamadas entre los dos procesos solo tengan que viajar en una dirección.
Definiciones de servicios de audio para automóviles del OEM
Servicio de enfoque de audio para automóviles del OEM
El servicio de audio para vehículos administra las solicitudes de foco de audio de las apps mediante el registro de un objeto de escucha de foco de política de audio. El servicio de audio para automóviles tiene un mecanismo para administrar el comportamiento de enfoque en función de una matriz de interacción estática. La matriz define tres tipos diferentes de interacciones:
Interacción simultánea. Los elementos de enfoque pueden mantener el enfoque al mismo tiempo.
Interacciones exclusivas. La solicitud de enfoque entrante quita el enfoque del titular de enfoque actual.
Rechazar la interacción. Se rechazó la solicitud de enfoque entrante según el titular de enfoque actual.
Si bien esto es suficiente para algunos casos de uso de la industria automotriz, no cumple con todas las necesidades de interacción que pueden diferir debido a los requisitos de los 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 evaluateAudioFocusRequest desde el servicio de audio del automóvil cada vez que hay una solicitud de enfoque de audio que se debe evaluar. Es una API de dos vías que bloquea los resultados para que se muestren. 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 de enfoque actuales en focusHolders y los perdedores de enfoque actuales en focusLosers. La API debe mostrar los siguientes 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 en audioFocusEvaluationResults, que indica si se otorgó, retrasó o falló la solicitud actual. Cualquier cambio en la pila de enfoque actual debe establecerse en las entradas newLosers y newlyBlocked, según la naturaleza del cambio de pila.
En el que newLosers contiene entradas que antes tenían el enfoque, pero ahora deberían perderlo, ya sea de forma permanente o transitoria. Los elementos que pierden el foco de forma permanente se quitarán de la pila de enfoque de audio, y los que pierden el foco de forma transitoria se moverán a la pila de elementos que pierden el foco actual hasta que recuperen el foco o se abandonen del solicitante de enfoque original. Independientemente, el objeto de escucha de enfoque para las solicitudes recibirá un foco perdido 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. En el caso del foco bloqueado de forma permanente, la entrada se quitará de la pila y la pérdida de foco se enviará a los objetos de escucha de foco. Para la pérdida de enfoque transitoria, la entrada permanecerá en la pila de perdedores de 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 cuando se bloqueó por primera vez. La solicitud finalmente se desbloqueará cuando se quiten todos los bloqueadores actuales, o se quitará de la pila si se abandona el enfoque.
La segunda API, notifyAudioFocusChange, es unidireccional y se llama en cada solicitud o abandono de 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 de enfoque
En AAOS, el enfoque de audio se usa para administrar la reproducción de audio y determinar qué app debe cumplir para proporcionar una experiencia óptima al usuario. Por lo tanto, el servicio del complemento del OEM debe tener en cuenta lo siguiente cuando administre 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 multimedia está activo, las apps que soliciten lo siguiente:
El enfoque de uso de llamadas debe poder recibir enfoque de forma simultánea o exclusiva.
El enfoque de uso de la navegación debe poder recibir enfoque de forma simultánea o exclusiva.
El enfoque de uso del Asistente debe poder recibir enfoque de forma simultánea o exclusiva.
Mientras las apps de enfoque de audio de alta prioridad (como una llamada telefónica, una alerta de emergencia o una alerta de seguridad) están activas, se debe otorgar o retrasar cualquier solicitud de enfoque de audio retrasado entrante según sea necesario.
Si bien las sugerencias anteriores no son exhaustivas, pueden ayudar a garantizar que las apps que soliciten enfoque puedan obtenerlo cuando no haya sonidos de alta prioridad activos. Incluso mientras los sonidos de prioridad alta están activos, se deben respetar las solicitudes de enfoque retrasado y deben poder enfocarse una vez que se detenga el sonido de prioridad alta.
Servicio de volumen del automóvil del OEM
El servicio de audio para automóviles administra los eventos de teclas de volumen escuchando los ajustes de volumen del sistema de audio o escuchando los eventos de teclas 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 prioridades de 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 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
- 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 de teclas de volumen sea menos compleja, el servicio de audio para automóviles tiene una segunda lista de prioridad de contexto de audio:
- Llamar
- Contenido multimedia
- Aviso
- Comando por voz
Esta lista también se presenta en orden descendente. El objetivo de esta segunda lista es permitir que se cambien los sonidos más comunes a través de eventos de teclas. Los sonidos poco comunes, quizás de una duración más corta, solo se pueden administrar a través de la IU de la configuración de audio.
La versión real del volumen se puede establecer con la configuración de audioVolumeAdjustmentContextsVersion. La configuración se puede establecer en 1 o 2 (2 es la opción predeterminada).
Para proporcionar más flexibilidad a la administración de volumen, se introdujo OemCarAudioVolumeService en Android 14:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
El servicio de volumen de audio para automóviles 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 silenciados actualmente. 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 mostrar en OemCarVolumeChangeInfo:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
El valor booleano change indica si cambió algún volumen. true indica que hay un cambio y que se debe actualizar el grupo de volumen. volumeGroupChanged es el grupo de volumen real que se debe cambiar. Este grupo se debe cambiar según el parámetro volumeAdjustment original que se pasa 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 que se muestra debe ser el de navegación.
Servicio de disminución del volumen de la bocina de automóviles OEM
El servicio de audio para vehículos administra la atenuación de audio supervisando los cambios de enfoque de audio y enviando una señal a la HAL de AudioControl sobre qué dispositivos de audio atenuar.
Cuando cambia el enfoque, se evalúan todos los elementos de enfoque activos para determinar cuál se debe ocultar según este conjunto de reglas de ocultación estáticas:
- Los sonidos de emergencia silencian todo, excepto los sonidos de llamada.
- Seguridad silencia todo, excepto los sonidos de emergencia
- La navegación silencia todo, excepto los sonidos de seguridad y emergencia.
- Silencia todo excepto los sonidos de seguridad, emergencia y navegación
- Sonido de llamada de voz de pato
- La música y los anuncios deben silenciarse con todo
Estas reglas no son exhaustivas, y los OEMs siguen siendo responsables de determinar cómo se deben atenuar los sonidos según estos lineamientos. Los OEMs pueden controlar estas recomendaciones de forma más activa en función de los requisitos disponibles. OemCarDuckingService se introdujo en Android 14:
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 enfoque de audio. Vuelve a usar el OemCarAudioVolumeRequest que se presentó en el servicio de volumen de automóviles OEM y contiene la información relevante para tomar la decisión sobre qué atributos omitir. La lista de atributos de audio que se silenciarán desde la API se compara con el estado de audio actual:
Atributo de audio que se está silenciando:
- En la lista, sigue oculta
- No está en la lista, la función de atenuación está desactivada
El atributo de audio no está silenciado actualmente:
- En la lista, oculta
- No está en la lista, la función de atenuación está desactivada
Luego, el servicio de audio para automóviles 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 silenciados o a la lista de dispositivos de audio no silenciados, respectivamente. Esto 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 secuencias simplificado del control de atenuación de audio para una solicitud de enfoque cuando se usa el servicio de atenuación del 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 se muestran los resultados de la API de evaluateAttributesToDuck, se calculan los dispositivos de audio que se silenciarán y, por último, la información se envía a AudioControl para aplicar el silenciamiento al hardware de audio.
Implementación de referencia del servicio de audio para vehículos OEM
AAOS proporciona una implementación de referencia del servicio de automóvil 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 en formato 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.
Referencia de la depuración de la app de prueba
La app de prueba de servicio de automóviles del OEM forma parte del código fuente de AOSP. Los OEMs pueden realizar cambios según sus necesidades. Para depurar, 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óviles OEM use el comando dump del servicio de automóviles OEM, haz lo siguiente:
adb shell dumpsys car_service --oem-service
Los resultados podrían ser similares a los siguientes:
***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 de la función y el servicio. Por ejemplo, la información de volcado mIsOemServiceReady especifica si el servicio está listo para usarse, en el que true indica que está listo y false indica que no está listo.