Les nouveaux services de plug-in OEM pour les voitures dans Android 14 permettent de configurer certains composants de la voiture. Pour l'audio en particulier, trois nouveaux services de plug-in sont introduits. Ils permettent aux OEM de configurer de manière flexible la gestion audio sur les appareils AAOS :
- Contrôle de la priorité audio
- Contrôle du volume et de la désactivation du son
- Contrôle de l'atténuation audio
Architecture du service de plug-in de voiture
La figure ci-dessous présente les services automobiles et leur relation avec le service automobile OEM. Comme les processus de service automobile et d'application, le processus de service automobile OEM occupe son propre espace de processus.
Le service automobile démarre le service automobile 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 remplacer 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();
}
Pour illustrer ce point, 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 automobile, il n'hérite pas automatiquement des autorisations disponibles pour le service audio automobile. 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 automobile avec architecture de service OEM
Dans AAOS, le service audio de la voiture gère les actions suivantes :
- Routage audio
- Priorité audio
- Atténuation audio
- Volume et désactivation du micro
Avant Android 14, ce comportement était largement statique et ne pouvait être modifié que par le biais des paramètres, mais pour un ensemble très limité de cas. Android 14 a introduit un mécanisme permettant au service audio automobile de communiquer avec un composant défini par l'OEM qui gère :
- Priorité audio
- Atténuation audio
- Volume et désactivation du micro
La figure ci-dessous présente une architecture simplifiée pour le service audio de la voiture et le service OEM de la voiture. Le service audio de la voiture définit différents hooks qui peuvent faire appel au service audio de l'OEM de la voiture pour gérer le comportement audio. Cette dernière ne se produit que si le composant de service audio automobile 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 OEM de la voiture sont toujours synchronisés, le service audio de la voiture transmet à chaque appel les parties requises de l'état actuel de la pile audio au service audio OEM de la voiture. Par exemple, lorsque le service audio de la voiture intercepte une requête d'évaluation de la mise au point audio, il transmet l'état actuel de la pile au service audio de l'OEM automobile. 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 le focus.
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 OEM de la voiture sont incomplètes. Par exemple, si un OEM remplace la gestion de la priorité audio dans le service automobile en enregistrant sa propre stratégie de priorité audio, le service audio automobile ne peut pas fournir d'informations complètes au service audio OEM automobile. Cela peut affecter la capacité du service audio OEM de la voiture à prendre des décisions, car il peut manquer d'informations non visibles par le service audio de la voiture.
Pour effectuer des actions, le service audio de la voiture appelle les services automobiles de l'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 de service audio de la voiture au service OEM sont bloquants, le service OEM ne doit pas appeler le service audio de la voiture lors des évaluations directes de l'API. Au lieu de cela, le service audio de la voiture fournit les informations nécessaires pour que les appels entre les deux processus ne se fassent que dans un seul sens.
Définitions des services audio de voiture OEM
Service de priorité audio OEM pour les voitures
Le service audio de la voiture gère les demandes de priorité audio des applications en enregistrant un écouteur de priorité de règle audio. Le service audio de la voiture dispose d'un mécanisme permettant de gérer le comportement de focus en fonction d'une matrice d'interaction statique. La matrice définit trois types d'interactions :
Interaction simultanée : Les titulaires de la mise au point peuvent maintenir la mise au point en même temps.
Interactions exclusives : Une demande de sélection entrante retire la sélection au détenteur actuel.
Refuser l'interaction La demande de sélection entrante a été refusée en fonction du détenteur actuel de la sélection.
Bien que cela suffise pour certains cas d'utilisation 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 par le service audio de la voiture chaque fois qu'une demande de focus audio doit être évaluée. Il s'agit d'une API bidirectionnelle qui bloque le retour 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 newFocusRequest par rapport aux détenteurs actuels du focus dans focusHolders et aux perdants actuels du focus 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 des informations sur les résultats de l'évaluation réelle dans audioFocusEvaluationResults, qui indique si la demande actuelle a été accordée, retardée ou a échoué. Toute modification apportée à la pile de mise au point actuelle doit être définie dans les entrées newLosers et newlyBlocked, en fonction de la nature de la modification de la pile.
Où newLosers contient des entrées qui étaient précédemment sélectionnées, mais qui devraient maintenant perdre la sélection, de manière permanente ou temporaire. Les perdants de focus permanent seront supprimés de la pile de focus audio, et les perdants de focus transitoires seront déplacés vers la pile des perdants de focus actuels jusqu'à ce qu'ils récupèrent le focus ou soient abandonnés par le demandeur de focus d'origine. Dans tous les cas, 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 focus, mais qui sont désormais bloquées par la nouvelle entrée. Le blocage peut être permanent ou temporaire. Si le blocage est permanent, l'entrée est supprimée de la pile et la perte de focus est envoyée aux écouteurs de focus. En cas de perte de focus transitoire, l'entrée restera dans la pile des perdants de focus, mais un nouveau bloqueur de focus sera ajouté à sa liste de bloqueurs. Aucune perte de focus ne sera envoyée, car une perte de focus a déjà été envoyée lors du blocage initial. 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 une API unidirectionnelle appelée à chaque demande ou abandon de focus audio. L'API est principalement utilisée pour informer le service OEM des changements de focus, qui peuvent affecter le comportement du service audio de la voiture OEM.
Consignes pour l'évaluation de la mise au point
Dans AAOS, la priorité audio est utilisée pour gérer la lecture audio et déterminer quelle application doit s'y conformer afin d'offrir une expérience optimale à l'utilisateur. Par conséquent, le service de plug-in OEM doit tenir compte des éléments suivants lors de la gestion d'une demande de focus audio :
En l'absence de priorité audio élevée (comme un appel téléphonique, une urgence ou un problème de sécurité), les applications doivent pouvoir obtenir le focus audio de manière transitoire ou permanente.
Lorsqu'une mise au point média est active, les applications qui demandent :
L'utilisation des appels doit être axée sur la possibilité de recevoir le focus simultanément ou exclusivement.
Le focus d'utilisation de la navigation doit pouvoir être reçu simultanément ou exclusivement.
L'utilisation de l'Assistant doit être axée sur la possibilité de recevoir le focus simultanément ou exclusivement.
Lorsque des applications avec une priorité audio élevée (comme un appel téléphonique, une alerte d'urgence ou une alerte de sécurité) sont actives, toute demande de priorité audio différée entrante doit être accordée ou différée selon les besoins.
Bien que les suggestions ci-dessus ne soient pas exhaustives, elles peuvent aider à garantir que les applications demandant la mise au point puissent l'obtenir lorsqu'il n'y a pas de sons actifs de haute priorité. Même lorsque des sons à priorité élevée sont actifs, les demandes de focus différées doivent toujours être respectées et doivent pouvoir obtenir le focus une fois que le son à priorité élevée s'arrête.
Service de volume de la voiture OEM
Le service audio de la voiture gère les événements de touche de volume en écoutant les ajustements de volume du système audio ou en écoutant directement les événements de touche de volume 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é du contexte audio.
Nous fournissons deux listes de priorité de volume. La première liste prend en compte 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 faible en bas. Par exemple, si l'audio de navigation et l'audio musical sont 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 touches de volume, le service audio de la voiture dispose d'une deuxième liste de priorité du 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 à l'aide d'événements clés. Les sons peu fréquents, peut-être de plus courte durée, ne peuvent être gérés que dans 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é dans 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 la voiture OEM comporte une seule méthode, qui prend 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 atténués. volumeGroupState indique 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 le groupe de volume à modifier. Les résultats doivent être renvoyés dans OemCarVolumeChangeInfo :
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
Le booléen change indique si un volume a changé. true indique qu'il y a un changement et que le groupe de volume 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 mis en sourdine, la valeur booléenne sera true et le groupe de volume renvoyé sera celui de la navigation.
Service de ducking automobile OEM
Le service audio de la voiture gère la diminution du volume audio en surveillant les changements de focus audio et en envoyant un signal à la couche d'abstraction matérielle AudioControl concernant les appareils audio à diminuer.
Lorsque le focus change, tous les détenteurs de focus actifs sont évalués pour déterminer lesquels doivent être atténués en fonction de cet ensemble de règles d'atténuation statiques :
- Les sons d'urgence réduisent le volume de tous les sons, sauf ceux des appels
- La sécurité désactive tout sauf les sons d'urgence
- La navigation réduit le volume de tout, sauf des sons de sécurité et d'urgence
- Désactiver le son de tout sauf les sons de sécurité, d'urgence et de navigation
- Le son de la sonnerie est atténué par la voix
- La musique et les annonces doivent être masquées par tout
Ces règles ne sont pas exhaustives. Il incombe toujours aux OEM de déterminer comment les sons doivent être atténués en fonction de ces consignes. Les OEM peuvent contrôler ces recommandations de manière plus active 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 lors des changements de focus audio. Il réutilise le OemCarAudioVolumeRequest introduit dans Service de volume de la voiture OEM et contient les informations pertinentes pour décider des attributs à baisser. La liste des attributs audio à baisser à partir de l'API est comparée à l'état audio actuel :
Attribut audio actuellement atténué :
- Sur la liste, le son continue d'être atténué
- Pas dans la liste, l'évitement est désactivé
Attribut audio non atténué actuellement :
- Dans la liste, son baissé
- Pas dans la liste, l'évitement est désactivé
Le service audio de la voiture détermine ensuite à quels périphériques de sortie audio appartiennent les attributs audio et les ajoute respectivement à la liste des périphériques de sortie audio avec réduction du volume ou à la liste des périphériques audio sans réduction du volume. Elle est finalement envoyée à AudioControl HAL pour effectuer l'atténuation requise au niveau matériel.
La figure ci-dessous présente un diagramme de séquence simplifié du contrôle de l'atténuation audio pour une demande de focus lorsque le service d'atténuation OEM est utilisé :
La séquence commence lorsqu'une application demande la gestion de la priorité audio via les API publiques du gestionnaire audio. La requête est transmise au service audio de la voiture pour déterminer les résultats. Lorsque la priorité audio est déterminée, le service audio de la voiture évalue l'atténuation audio en appelant OemCarAudioDuckingService pour déterminer quels attributs audio doivent être atténués. Une fois les résultats renvoyés par l'API evaluateAttributesToDuck, les périphériques audio à baisser sont calculés, puis les informations sont envoyées à AudioControl pour appliquer la baisse 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 est utilisée pour évaluer la demande de focus lorsque evaluateAudioFocusRequest est appelé.
Débogage de l'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 afin d'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" translatab>le="false"
com.android.car.oemcarservice.testapp</.OemCa>rServiceImpl
/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 l'est et false indique qu'il ne l'est pas.