Les nouveaux services de plug-in OEM pour voitures d'Android 14 permettent de configurer certains composants de la voiture. Pour l'audio en particulier, trois nouveaux services de plug-in sont introduits, qui permettent aux OEM de configurer de manière flexible la gestion audio sur les appareils AAOS:
- Commande de priorité audio
- Contrôle du volume et de la désactivation du son
- Commande d'atténuation audio
Architecture du service de prise en charge des voitures électriques
L'illustration ci-dessous présente les services automobiles et leur relation avec le service automobile OEM. Comme les processus d'application et le processus de service automobile, le processus de service automobile OEM occupe son propre espace de processus.
Le service de voiture démarre le service de voiture OEM en recherchant le composant défini dans config_oemCarService. Si la configuration est vide, le service OEM n'existe pas et aucun service n'est démarré. Le composant doit étendre OemCarService.
Le service audio de la voiture doit écraser les API pour acquérir le service OEM audio de la voiture:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Par exemple, consultez l'application de test de référence définie dans packages/services/Car/tests/OemCarServiceTestApp.
Même si le service est démarré par le service de voiture, il n'hérite pas automatiquement des autorisations disponibles pour le service audio de la voiture. Par conséquent, toute autorisation requise par les services OEM doit être obtenue avec le mécanisme approprié. Pour obtenir un exemple, consultez packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml.
Service audio pour voitures avec architecture de service OEM
Dans AAOS, le service audio pour voitures gère les actions suivantes:
- Routage audio
- Priorité audio
- Atténuation audio
- Volume et désactivation du son
Avant Android 14, ce comportement était largement statique et ne pouvait être modifié que via les paramètres, mais dans un nombre très limité de cas. Android 14 a introduit un mécanisme permettant au service audio de la voiture de communiquer avec un composant défini par l'OEM qui gère les éléments suivants:
- Priorité audio
- Atténuation audio
- Volume et désactivation du son
La figure ci-dessous présente une architecture simplifiée du service audio de la voiture et du service OEM de la voiture. Le service audio de la voiture définit différents crochets pouvant appeler le service audio de l'OEM de la voiture pour gérer le comportement audio. Ce dernier ne se produit que si le composant de service audio de voiture OEM correspondant est défini. Sinon, le service audio de la voiture utilise le comportement par défaut.
Pour s'assurer que le service audio de la voiture et le service audio de l'OEM de la voiture sont toujours synchronisés, pour chaque appel, le service audio de la voiture transmet les parties requises de l'état actuel de la pile audio au service audio de l'OEM de la voiture. Par exemple, lorsque le service audio de la voiture intercepte une requête pour évaluer la sélection audio, il transmet l'état actuel de la pile au service audio de l'OEM de la voiture. L'état actuel inclut le détenteur actuel du focus et les perdants actuels du focus. Les perdants de focus sont des requêtes de focus qui font toujours partie de la pile, mais qui ont temporairement perdu la mise au point.
Le service audio de la voiture doit gérer toute l'activité audio dans la voiture. Si le service audio de la voiture ne gère pas certaines parties du comportement audio, les informations exposées au service audio de l'OEM de la voiture sont incomplètes. Par exemple, si un OEM écrase la gestion de la sélection audio dans le service de voiture en enregistrant sa propre stratégie de sélection audio, le service audio de la voiture ne peut pas fournir d'informations complètes au service audio de l'OEM de la voiture. Cela peut affecter la capacité du service audio OEM de la voiture à prendre des décisions, car il peut manquer d'informations qui ne sont pas visibles par le service audio de la voiture.
Pour effectuer des actions, le service audio de la voiture appelle les services automobiles OEM. Ces appels sont effectués entre les processus, ce qui nécessite une communication inter-processus (IPC). L'IPC ajoute de la latence à chaque appel. Il est important de minimiser la latence dans le service OEM.
Étant donné que les appels du service audio de la voiture au service OEM sont bloquants, le service OEM ne doit pas appeler le service audio de la voiture pour les évaluations d'API directes. À la place, le service audio de la voiture fournit les informations nécessaires pour que les appels entre les deux processus ne circulent que dans un seul sens.
Définitions des services audio OEM
Service de priorité audio pour les voitures OEM
Le service audio de la voiture gère les demandes de priorité audio provenant des applications en enregistrant un écouteur de priorité audio. Le service audio pour voitures dispose d'un mécanisme permettant de gérer le comportement de mise au point en fonction d'une matrice d'interaction statique. La matrice définit trois types d'interactions différents:
Interaction simultanée. Les détenteurs de la mise au point peuvent maintenir la mise au point en même temps.
Interactions exclusives La demande de sélection entrante supprime la sélection du détenteur actuel.
Refuser l'interaction. La requête de focus entrante a été refusée en fonction du détenteur actuel du focus.
Bien que cela suffise pour certains cas d'utilisation dans le secteur automobile, cela ne répond pas à tous les besoins d'interaction qui peuvent différer en raison des exigences des OEM. Pour ce faire, nous introduisons OemCarAudioFocusService:
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
L'API evaluateAudioFocusRequest est appelée à partir du service audio de la voiture chaque fois qu'une requête de mise au point audio doit être évaluée. Il s'agit d'une API à double sens qui bloque l'affichage des résultats. La requête contient des informations sur l'état actuel de la pile audio:
Ces informations peuvent être utilisées pour évaluer le newFocusRequest par rapport aux détenteurs actuels de l'attention dans focusHolders et aux perdants actuels de l'attention dans focusLosers. L'API doit renvoyer les résultats suivants:
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
Il contient les informations sur les résultats d'évaluation réels dans audioFocusEvaluationResults, qui indiquent si la requête en cours a été accordée, retardée ou échouée. Toute modification apportée à la pile de focus actuelle doit être définie dans les entrées newLosers et newlyBlocked, en fonction de la nature du changement de pile.
Lorsque newLosers contient des entrées qui maintenaient auparavant la sélection, mais qui doivent maintenant la perdre, de manière permanente ou temporaire. Les perdants de focus permanents seront supprimés de la pile de focus audio, et les perdants de focus temporaires seront déplacés vers la pile de perdants de focus actuelle jusqu'à ce qu'ils récupèrent le focus ou soient abandonnés par la demande de focus d'origine. Quoi qu'il en soit, l'écouteur de focus pour les requêtes recevra une perte de focus correspondante.
La liste newlyBlocked contient des entrées qui figuraient auparavant dans la liste des perdants de mise au point, mais qui sont maintenant bloquées par la nouvelle entrée. Le blocage peut être permanent ou temporaire. Pour un blocage permanent de la sélection, l'entrée est supprimée de la pile et la perte de sélection est envoyée aux écouteurs de sélection. En cas de perte de focus temporaire, l'entrée reste dans la pile des perdants de focus, mais un nouveau bloqueur de focus est ajouté à sa liste de bloqueurs. Aucune perte de focus n'est envoyée, car une en a déjà été envoyée lors du premier blocage. La requête sera finalement débloquée lorsque tous les bloqueurs actuels seront supprimés, ou elle sera supprimée de la pile si la mise au point est abandonnée.
La deuxième API, notifyAudioFocusChange, est à sens unique et est appelée à chaque requête ou abandon de mise au point audio. L'API est principalement utilisée pour informer le service OEM des modifications de mise au point, qui peuvent affecter le comportement du service audio de l'OEM.
Consignes pour l'évaluation de la focalisation
Dans AAOS, la sélection audio permet de gérer la lecture audio et de déterminer quelle application doit s'y conformer pour offrir une expérience optimale à l'utilisateur. Par conséquent, le service de plug-in OEM doit prendre en compte les éléments suivants lors de la gestion d'une requête de mise au point audio:
En l'absence de priorité audio permanente (comme un appel téléphonique, une urgence ou une situation de sécurité), les applications doivent pouvoir obtenir la priorité audio de manière temporaire ou permanente.
Lorsqu'un focus multimédia est actif, les applications qui demandent:
Le focus d'utilisation des appels doit pouvoir être sélectionné simultanément ou exclusivement.
Le focus d'utilisation de la navigation doit pouvoir être activé simultanément ou exclusivement.
Le focus d'utilisation de l'Assistant doit pouvoir être activé simultanément ou exclusivement.
Lorsque des applications de priorité audio élevée (telles qu'un appel téléphonique, une alerte d'urgence ou une alerte de sécurité) sont actives, toute demande entrante de mise au point audio différée doit être accordée ou retardée si nécessaire.
Bien que les suggestions ci-dessus ne soient pas exhaustives, elles peuvent aider à garantir que les applications qui demandent la sélection doivent pouvoir l'obtenir lorsqu'il n'y a pas de sons de priorité élevée actifs. Même lorsque des sons de priorité élevée sont actifs, les requêtes de mise au point différée doivent être respectées et doivent pouvoir être mises au point une fois que le son de priorité élevée s'arrête.
Service de réglage du volume de la voiture OEM
Le service audio de la voiture gère les événements de touche de volume en écoutant les réglages du volume du système audio ou en écoutant les événements de touche de volume directement à partir du service d'entrée de la voiture. Dans chaque cas, le comportement par défaut du service audio de la voiture consiste à déterminer le groupe de volume à modifier en fonction des lecteurs audio actifs et d'une liste de priorité de contexte audio.
Nous fournissons deux listes de priorité en fonction du volume. La première liste tient compte de tous les contextes audio dans cet ordre. La liste est présentée par ordre décroissant, la priorité la plus élevée en haut et la priorité la plus basse en bas. Par exemple, si l'audio de navigation et l'audio de la musique sont tous deux actifs en même temps, le volume de navigation est modifié lors d'un événement de touche de volume.
- Navigation
- Appeler
- Musique
- Annonce
- Commande vocale
- Sonnerie d'appel
- Son du système
- Sécurité
- Alarme
- Notification
- État du véhicule
- Urgence
Pour simplifier la gestion des événements de la touche de volume, le service audio pour voiture dispose d'une deuxième liste de priorité de contexte audio:
- Appeler
- Contenus multimédias
- Annonce
- Commande vocale
Cette liste est également présentée dans l'ordre décroissant. L'objectif de cette deuxième liste est de permettre de modifier les sons les plus courants via des événements clés. Les sons inhabituels, qui sont peut-être de courte durée, ne peuvent être gérés que via l'interface utilisateur des paramètres audio.
La version réelle du volume peut être définie avec la configuration audioVolumeAdjustmentContextsVersion. La configuration peut être définie sur 1 ou 2 (2 est la valeur par défaut).
Pour offrir plus de flexibilité à la gestion du volume, OemCarAudioVolumeService est introduit dans Android 14:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
Le service de volume audio de l'OEM dispose d'une seule méthode, qui prend en charge un volumeAdjustment et un OemCarAudioVolumeRequest:
class OemCarAudioVolumeRequest {
int audioZoneId;
int callState;
List<AudioAttributes> activePlaybackAttributes;
List<AudioAttributes> duckedAttributes;
List<CarVolumeGroupInfo> volumeGroupState;
}
Le activePlaybackAttributes de la requête contient les attributs audio actifs. Les duckedAttributes sont tous des attributs audio actuellement masqués. volumeGroupState contient l'état actuel du groupe de volumes. La requête représente l'état actuel de la pile audio et peut être utilisée pour déterminer quel groupe de volume doit être modifié. Les résultats doivent être renvoyés dans OemCarVolumeChangeInfo:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
La valeur booléenne change indique si un volume a changé. true indique qu'un changement a été effectué et que le groupe de volumes doit être mis à jour. volumeGroupChanged correspond au groupe de volumes à modifier. Ce groupe doit être modifié en fonction du paramètre volumeAdjustment d'origine transmis à l'API. Par exemple, si les résultats indiquent que le groupe de volume de navigation doit être coupé, la valeur booléenne est true et le groupe de volume renvoyé doit être celui de la navigation.
Service d'atténuation du son des voitures OEM
Le service audio de la voiture gère le masquage audio en surveillant les changements de focus audio et en envoyant un signal au HAL AudioControl sur les appareils audio à masquer.
Lorsque le focus change, tous les détenteurs de focus actifs sont évalués pour déterminer ceux qui doivent être masqués en fonction de cet ensemble de règles de masquage statique:
- Les alertes d'urgence éteignent tous les sons, sauf les sons d'appel.
- La sécurité coupe tout, sauf les sons d'urgence
- La navigation coupe tous les sons, sauf les sons de sécurité et d'urgence.
- Le mode Appel coupe tous les sons, sauf ceux de sécurité, d'urgence et de navigation.
- Voice coupe les sonneries des appels
- La musique et les annonces doivent être masquées par tout autre contenu.
Ces règles ne sont pas exhaustives, et les OEM restent responsables de déterminer comment les sons doivent être masqués en fonction de ces consignes. Les OEM peuvent contrôler ces recommandations plus activement en fonction des exigences disponibles. OemCarDuckingService est introduit dans Android 14:
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
Cette API est appelée à partir du service audio de la voiture en cas de modification de la sélection audio. Il réutilise OemCarAudioVolumeRequest introduit dans le service de volume de voitures OEM et contient les informations pertinentes pour décider des attributs à masquer. La liste des attributs audio à masquer à partir de l'API est comparée à l'état audio actuel:
Attribut audio actuellement masqué:
- Sur la liste, mais toujours ignoré
- Ne figure pas sur la liste, la suppression du son est désactivée
Attribut audio actuellement masqué:
- Dans la liste, masqué
- Ne figure pas sur la liste, la suppression du son est désactivée
Le service audio de la voiture détermine ensuite à quels appareils de sortie audio les attributs audio appartiennent et les ajoute à la liste des appareils de sortie audio masqués ou à la liste des appareils audio non masqués, respectivement. Il est finalement envoyé au HAL AudioControl pour effectuer le masquage requis au niveau matériel.
La figure ci-dessous montre un diagramme de séquence simplifié de la commande de masquage audio pour une requête de mise au point lorsque le service de masquage OEM est utilisé:
La séquence commence lorsqu'une application demande à gérer la priorité audio via les API de gestion audio publiques. La requête est transmise au service audio de la voiture pour déterminer les résultats. Lorsque la sélection audio est définie, le masquage audio est évalué par le service audio de la voiture qui appelle OemCarAudioDuckingService pour déterminer quels attributs audio doivent être masqués. Une fois les résultats renvoyés par l'API evaluateAttributesToDuck, les appareils audio à couper sont calculés, et les informations sont finalement envoyées à AudioControl pour appliquer le masquage au matériel audio.
Implémentation de référence du service audio automobile OEM
AAOS fournit une implémentation de référence du service automobile OEM dans packages/services/Car/tests/OemCarServiceTestApp, qui implémente OemCarService, ainsi que OemCarAudioFocusService, OemCarAudioDuckingService et OemCarAudioVolumeService. Pour ce dernier, chaque service utilise un fichier XML pour charger un comportement statique. Par exemple, OemCarAudioFocusServiceImp charge oem_focus_config.xml, qui contient une matrice d'interaction. La matrice permet d'évaluer la requête de mise au point lorsque evaluateAudioFocusRequest est appelé.
Déboguer une application de test de référence
L'application de test du service automobile OEM fait partie du code source AOSP. Les OEM peuvent apporter des modifications en fonction de leurs besoins. Pour le débogage, utilisez la configuration config_oemCarService pour activer l'application de test.
<!-- 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>
Pour vérifier que le service automobile OEM utilise la commande dump du service automobile pour le service OEM:
adb shell dumpsys car_service --oem-service
Les résultats peuvent ressembler à ce qui suit:
***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
Chaque valeur booléenne de chaque lot d'informations dump détermine l'état de la fonctionnalité et du service. Par exemple, les informations de vidage mIsOemServiceReady indiquent si le service est prêt à être utilisé, où true indique qu'il est prêt et false qu'il ne l'est pas.