Los nuevos servicios de complementos OEM para 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 manera flexible la administración de audio en dispositivos AAOS:
- Control de enfoque de audio
- Control de volumen y silencio de audio.
- Control de reducción de audio
Arquitectura del servicio de complementos para automóviles
La siguiente figura proporciona una descripción general de los servicios de automóviles y su relación con el servicio de automóviles OEM. De manera similar a los procesos de la aplicación y el proceso de servicio del automóvil, el proceso de servicio del automóvil OEM ocupa su propio espacio de proceso.
El servicio de automóvil inicia el servicio de automóvil OEM al encontrar el componente definido en config_oemCarService . Si la configuración está vacía, el servicio OEM no existe y no se inicia ningún servicio. El componente debe ampliar OemCarService . El servicio de audio para automóvil debe sobrescribir las API para adquirir el servicio OEM de audio para automóvil:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Por ejemplo , consulte la aplicación 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. Como tal, cualquier permiso requerido por los servicios OEM debe adquirirse con el mecanismo adecuado. Por ejemplo, consulte packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml .
Servicio de audio para automóvil con arquitectura de servicio OEM
En AAOS, el servicio de audio para automóvil gestiona estas acciones:
- Enrutamiento de audio
- Enfoque de audio
- Audio ducking
- Volumen y silencio
Antes de Android 14, este comportamiento era en gran medida estático y solo podía modificarse mediante la configuración, aunque en 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:
- Enfoque de audio
- Audio ducking
- Volumen y silencio
La siguiente figura muestra una arquitectura simplificada para el servicio de audio para automóvil y el servicio OEM para automóvil. El servicio de audio para automóvil define diferentes ganchos que pueden recurrir al servicio de audio OEM para automóvil para administrar el comportamiento del audio. Esto último ocurre sólo si se define el componente de servicio de audio para automóvil OEM correspondiente. De lo contrario, el servicio de audio para automóvil utiliza el comportamiento predeterminado.
Para garantizar que el servicio de audio para automóvil y el servicio de audio OEM para automóvil estén siempre sincronizados, para cada llamada, el servicio de audio para automóvil pasa las partes requeridas del estado actual de la pila de audio al servicio de audio OEM para 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 OEM del automóvil. El estado actual incluye al poseedor del foco actual y a los perdedores del foco actual. Los perdedores de enfoque son solicitudes de enfoque que todavía forman parte de la pila pero que han perdido el enfoque temporalmente.
El servicio de audio para el automóvil debe gestionar toda la actividad de audio en el automóvil. Si el servicio de audio del automóvil no gestiona algunas partes del comportamiento del audio, entonces la información expuesta al servicio de audio OEM del automóvil está incompleta. Por ejemplo, si un OEM sobrescribe el manejo del enfoque de audio en el servicio de automóvil al registrar su propia política de enfoque de audio, entonces el servicio de audio del automóvil no puede proporcionar información completa al servicio de audio OEM del automóvil. Esto puede afectar la capacidad del servicio de audio 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 tomar medidas, el servicio de audio del automóvil llama a los servicios de automóviles OEM. Estas llamadas se realizan entre procesos, lo que requiere comunicación entre procesos (IPC). IPC agrega latencia a cada llamada. Es importante minimizar la latencia en el servicio OEM.
Dado que las llamadas del servicio de audio del automóvil al servicio OEM están bloqueadas, el servicio OEM no debe llamar al servicio de audio del automóvil en evaluaciones API directas. En cambio, el servicio de audio para el automóvil proporciona la información necesaria para que las llamadas entre ambos procesos solo tengan que viajar en una dirección.
Definiciones de servicios de audio para automóviles OEM
Servicio de enfoque de audio para automóvil OEM
El servicio de audio para automóviles gestiona las solicitudes de enfoque de audio de las aplicaciones registrando un oyente de enfoque de política de audio. El servicio de audio para automóvil tiene un mecanismo para gestionar el comportamiento de enfoque basado en una matriz de interacción estática. La matriz define tres tipos diferentes de interacciones:
Interacción concurrente. Los titulares de enfoque pueden mantener el enfoque al mismo tiempo.
Interacciones exclusivas. La solicitud de enfoque entrante toma el enfoque del titular de enfoque actual.
Rechazar la interacción. Solicitud de enfoque entrante rechazada según el titular de enfoque actual.
Si bien esto es suficiente para algunos casos de uso automotrices, no satisface todas las necesidades de interacción que pueden diferir debido a los requisitos del OEM. Para ello presentamos el OemCarAudioFocusService :
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
La API evaluateAudioFocusRequest se llama 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 bloquea la devolución de los resultados. La solicitud contiene información sobre el estado actual de la pila de audio:
Esta información se puede utilizar para evaluar newFocusRequest en comparación con los titulares de enfoque actuales en focusHolders y los perdedores de 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 la solicitud actual se ha concedido, se ha retrasado o ha fallado. Cualquier cambio en la pila de enfoque actual debe establecerse en las entradas newLosers y newlyBlocked , según la naturaleza del cambio de pila.
Donde newLosers contiene entradas que anteriormente mantenían el foco pero que ahora deberían perderlo, ya sea de forma permanente o transitoria. Los perdedores de enfoque permanentes se eliminarán aún más de la pila de enfoque de audio, y los perdedores de enfoque transitorios se moverán a la pila de perdedores de enfoque actual hasta que recuperen el enfoque o sean abandonados por el solicitante de enfoque original. De todos modos, el oyente de enfoque de las solicitudes recibirá la correspondiente pérdida de enfoque.
La lista newlyBlocked contiene entradas que anteriormente estaban en la lista de perdedores de enfoque pero que ahora están bloqueadas por la nueva entrada. El bloqueo puede ser permanente o transitorio; para el enfoque permanente bloqueado, la entrada se eliminará de la pila y la pérdida de enfoque se enviará a los oyentes de enfoque. 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 como se envió anteriormente cuando se bloqueó por primera vez. La solicitud finalmente se desbloqueará cuando se eliminen todos los bloqueadores actuales, o se eliminará de la pila si se abandona el foco.
La segunda API, notifyAudioFocusChange , es unidireccional y se llama en cada solicitud o abandono de enfoque de audio. La API se utiliza principalmente para informar al servicio OEM sobre cambios de enfoque, que pueden afectar el comportamiento del servicio de audio para automóvil OEM.
Directrices para la evaluación del enfoque
En AAOS, el enfoque de audio se utiliza para administrar la reproducción de audio y determinar qué aplicación debe cumplir para brindar una experiencia óptima al usuario. Como tal, el servicio de complemento OEM debe tener en cuenta lo siguiente al gestionar una solicitud de enfoque de audio:
Sin ningún enfoque de audio de alta prioridad (como una llamada telefónica, una emergencia o seguridad), las aplicaciones deberían poder obtener un enfoque de audio de forma transitoria o permanente.
Mientras un enfoque multimedia está activo, las aplicaciones que solicitan:
El enfoque de uso de llamadas debería poder recibir el enfoque de forma simultánea o exclusiva.
El enfoque en el uso de la navegación debería poder recibir el enfoque de forma simultánea o exclusiva.
El enfoque de uso del asistente debería poder recibir el enfoque de forma simultánea o exclusiva.
Mientras las aplicaciones de enfoque de audio de alta prioridad (como una llamada telefónica, alerta de emergencia o alerta de seguridad) estén activas, cualquier solicitud entrante de enfoque de audio retrasado debe concederse o retrasarse según sea necesario.
Si bien las sugerencias anteriores no son exhaustivas, pueden ayudar a garantizar que las aplicaciones que solicitan enfoque puedan obtenerlo cuando no haya sonidos activos de alta prioridad. Incluso cuando los sonidos de alta prioridad están activos, las solicitudes de enfoque retardado aún deben respetarse y deberían poder enfocarse una vez que el sonido de alta prioridad se detenga.
Servicio de volumen de automóviles OEM
El servicio de audio para automóvil administra los eventos de las teclas de volumen escuchando los ajustes de volumen desde el sistema de audio o escuchando los eventos de las teclas de volumen directamente desde el servicio de entrada del automóvil. En cada caso, el comportamiento predeterminado del servicio de audio para 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, 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 de voz
- timbre de llamada
- sonido del sistema
- Seguridad
- Alarma
- Notificación
- Estado del vehículo
- Emergencia
Para que la gestión de eventos de teclas de volumen sea menos compleja, el servicio de audio para automóvil tiene una segunda lista de prioridad de contexto de audio:
- Llamar
- Medios de comunicación
- Anuncio
- Comando de voz
Esta lista también se presenta en orden descendente. El propósito de esta segunda lista es permitir que se cambien sonidos más comunes a través de eventos clave. Los sonidos poco comunes, quizás de menor duración, se pueden administrar únicamente a través de la interfaz de usuario de configuración de audio.
La versión real del volumen se puede configurar con la configuración audioVolumeAdjustmentContextsVersion . La configuración se puede establecer en 1 o 2 ( 2 es el valor predeterminado).
Para brindar más flexibilidad a la administración de volúmenes, OemCarAudioVolumeService se introduce en Android 14:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
El servicio de volumen de audio para automóvil OEM tiene un método único, que admite un volumeAdjustment y una OemCarAudioVolumeRequest :
class OemCarAudioVolumeRequest {
int audioZoneId;
int callState;
List<AudioAttributes> activePlaybackAttributes;
List<AudioAttributes> duckedAttributes;
List<CarVolumeGroupInfo> volumeGroupState;
}
Los activePlaybackAttributes de la solicitud tienen los atributos de audio activos. Los duckedAttributes son todos atributos de audio actualmente atenuados. volumeGroupState tiene el estado actual del grupo de volúmenes. La solicitud representa el estado actual de la pila de audio y se puede utilizar para determinar qué grupo de volúmenes se debe cambiar. Los resultados deben devolverse en OemCarVolumeChangeInfo :
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
El change booleano indica si algún volumen ha cambiado, true indica que hay un cambio y el grupo de volúmenes debe actualizarse. volumeGroupChanged es el grupo de volúmenes real que debe cambiarse. Este grupo debe cambiarse de acuerdo con el parámetro volumeAdjustment original pasado a la API. Por ejemplo, si los resultados indican que el grupo de volúmenes de navegación debe silenciarse, entonces el booleano sería true y el grupo de volúmenes devuelto debería ser el de navegación.
Servicio de amortiguación de automóviles OEM
El servicio de audio para automóvil gestiona la atenuación de audio monitoreando los cambios de enfoque de audio y enviando una señal al AudioControl HAL sobre qué dispositivos de audio anular. Cuando el foco cambia, todos los titulares de focos activos se evalúan para determinar cuáles deben esquivarse según este conjunto de reglas de esquivado estáticas:
- Los sonidos de emergencia atenúan todo excepto los sonidos de llamada.
- La seguridad evita todo excepto los sonidos de emergencia.
- La navegación evita todo excepto los sonidos de seguridad y emergencia.
- La llamada evita todo excepto los sonidos de seguridad, emergencia y navegación.
- Sonidos de timbre de llamada de patos de voz.
- La música y los anuncios deberían ser esquivados por todo.
Estas reglas no son exhaustivas y los OEM siguen siendo responsables de determinar cómo se deben atenuar los sonidos según estas pautas. Los OEM pueden controlar estas recomendaciones de forma más activa en función de los requisitos disponibles. OemCarDuckingService se introduce en Android 14:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
Esta API se llama desde el servicio de audio del automóvil en caso de cambios de enfoque de audio. Reutiliza OemCarAudioVolumeRequest introducido en el servicio de volumen de automóviles OEM y contiene la información relevante para tomar la decisión sobre qué atributos evitar. La lista de atributos de audio que se deben eliminar de la API se compara con el estado de audio actual:
Atributo de audio actualmente desactivado:
- En la lista, sigue siendo esquivado
- No en la lista, agacharse desactivado
Atributo de audio no atenuado actualmente:
- En la lista, agachado
- No en la lista, agacharse desactivado
Luego, el servicio de audio para 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 no atenuados, respectivamente. En última instancia, esto se envía al AudioControl HAL para realizar la reducción requerida a nivel de hardware.
La siguiente figura muestra un diagrama de secuencia simplificado del control de reducción de audio para una solicitud de enfoque cuando se utiliza el servicio de reducción de OEM:
La secuencia comienza cuando una aplicación solicita Administrar el foco de audio a través de las API públicas del administrador de audio. La solicitud se enví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 devuelven los resultados de la API evaluateAttributesToDuck , se calculan los dispositivos de audio que se van a atenuar y, finalmente, la información se envía a AudioControl para aplicar la atenuación al hardware de audio.
Implementación de referencia del servicio de audio para automóvil 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 . Para este último, cada servicio utiliza un archivo 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 utiliza para evaluar la solicitud de enfoque cuando se llama a evaluateAudioFocusRequest .
Depuración de la aplicación de prueba de referencia
La aplicación de prueba de servicio de automóvil OEM es parte del código fuente de AOSP. Los OEM pueden realizar cambios según sus necesidades. Para la depuración, utilice la configuración config_oemCarService para habilitar la aplicación 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 el servicio de automóvil OEM, utilice el comando dump de servicio de automóvil para el servicio OEM:
adb shell dumpsys car_service --oem-service
Los resultados podrían ser similares al resultado 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 booleano en cada lote de información dump determina el estado de la característica 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.