Les nouveaux services de plug-in OEM de voiture dans Android 14 permettent de configurer certains composants de la voiture. Pour l'audio spécifiquement, 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 :
- Contrôle de la mise au point audio
- Contrôle du volume audio et de la sourdine
- Contrôle du ducking audio
Architecture de service de plugin de voiture
La figure ci-dessous donne un aperçu des services de voiture et de leur relation avec le service de voiture OEM. Semblable aux processus d'application et au 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 trouvant 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 voiture doit écraser les API pour acquérir le service OEM audio de 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 automobile, il n'hérite pas automatiquement des autorisations disponibles pour le service audio de la voiture. En tant que tel, toute autorisation requise par les services OEM doit être obtenue avec le mécanisme approprié. Par exemple, consultez packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml .
Service audio de voiture avec architecture de service OEM
Dans AAOS, le service audio de voiture gère ces actions :
- Routage audio
- Focus audio
- Ducking audio
- Volume et sourdine
Avant Android 14, ce comportement était en grande partie statique et ne pouvait être modifié que via les paramètres, bien que dans un nombre de cas très limité. Android 14 a introduit un mécanisme permettant au service audio de voiture de communiquer avec un composant défini par l'OEM qui gère :
- Focus audio
- Ducking audio
- Volume et sourdine
La figure ci-dessous montre une architecture simplifiée pour le service audio de voiture et le service OEM de voiture. Le service audio de la voiture définit différents hooks qui peuvent faire appel au service audio OEM de la voiture pour gérer le comportement audio. Ce dernier cas 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 garantir que le service audio de la voiture et le service audio 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 OEM de la voiture. Par exemple, lorsque le service audio de la voiture intercepte une demande d'évaluation du focus audio, il transmet l'état actuel de la pile au service audio 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 demandes de focus qui font toujours partie de la pile mais qui ont temporairement perdu leur focus.
Le service audio de la voiture doit gérer toutes les activités 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 alors incomplètes. Par exemple, si un OEM écrase la gestion de la focalisation audio dans le service de voiture en enregistrant sa propre politique de focalisation audio, le service audio de la voiture ne peut pas fournir des informations complètes au service audio du 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 non visibles par le service audio de la voiture.
Pour prendre des mesures, 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). 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 voiture au service OEM sont bloqués, le service OEM ne doit pas appeler le service audio de voiture lors d'évaluations API directes. Au lieu de cela, le service audio de voiture fournit les informations nécessaires pour que les appels entre les deux processus ne soient transmis que dans une seule direction.
Définitions des services audio de voiture OEM
Service de mise au point audio de voiture OEM
Le service audio de voiture gère les demandes de focus audio des applications en enregistrant un auditeur de focus de politique audio. Le service audio automobile dispose d'un mécanisme pour gérer le comportement de mise au point basé sur une matrice d'interaction statique. La matrice définit trois types d'interactions différents :
Interaction simultanée. Les détenteurs de concentration peuvent maintenir leur concentration en même temps.
Interactions exclusives. La demande de focus entrante prend le focus du détenteur du focus actuel.
Rejetez l’interaction. Demande de focus entrante rejetée en fonction du détenteur de focus actuel.
Bien que cela soit suffisant 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 constructeurs OEM. Pour cela nous introduisons le OemCarAudioFocusService :
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
L'API evaluateAudioFocusRequest est appelée depuis 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 le newFocusRequest par rapport aux détenteurs de focus actuels dans focusHolders et aux perdants de focus actuels dans focusLosers . L'API doit renvoyer les résultats :
class OemCarAudioFocusResult {
int audioZoneId;
int audioFocusEvaluationResults;
AudioFocusEntry focusResult;
List<AudioFocusEntry> newLosers;
List<AudioFocusEntry> newlyBlocked;
}
Celui-ci contient les informations sur les résultats réels de l'évaluation dans audioFocusEvaluationResults , qui indiquent si la demande actuelle a été accordée, retardée ou si elle a échoué. 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.
Où newLosers contient des entrées qui étaient auparavant actives mais qui devraient maintenant perdre le focus, de manière permanente ou transitoire. Les perdants de focus permanents seront davantage retirés de la pile de focus audio, et les perdants de focus transitoires seront déplacés vers la pile de perdants de focus actuels jusqu'à ce qu'ils retrouvent le focus ou soient abandonnés du demandeur de focus d'origine. Quoi qu’il en soit, l’auditeur de focus pour les demandes recevra un focus correspondant perdu.
La liste newlyBlocked contient des entrées qui figuraient auparavant dans la liste des perdants du focus mais qui sont désormais bloquées par la nouvelle entrée. Le blocage peut être permanent ou transitoire. En cas de blocage permanent, l'entrée sera supprimée de la pile et la perte de focus sera envoyée aux auditeurs 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 comme celle qui avait été envoyée précédemment lors de son 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 le focus est abandonné.
La deuxième API, notifyAudioFocusChange , est une méthode unique qui est 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 voiture OEM.
Lignes directrices pour l’évaluation ciblée
Dans AAOS, la focalisation audio est utilisée pour gérer la lecture audio et pour déterminer quelle application doit adhérer pour offrir une expérience optimale à l'utilisateur. En tant que tel, le service de plugin OEM doit prendre en compte les éléments suivants lors de la gestion d’une demande de focus audio :
Sans aucune priorité audio permanente (telle qu'un appel téléphonique, une urgence ou une sécurité), les applications devraient pouvoir obtenir une concentration audio de manière transitoire ou permanente.
Lorsqu'un focus média est actif, les applications demandant :
Le focus sur l'utilisation des appels doit pouvoir recevoir le focus simultanément ou exclusivement.
Le focus sur l'utilisation de la navigation doit pouvoir recevoir le focus simultanément ou exclusivement.
Le focus sur l'utilisation de l'assistant doit pouvoir recevoir le focus simultanément ou exclusivement.
Lorsque les applications de mise au point audio haute priorité (telles qu'un appel téléphonique, une alerte d'urgence ou une alerte de sécurité) sont actives, toute demande de mise au point audio retardée entrante doit être soit accordée, soit retardée selon les besoins.
Bien que les suggestions ci-dessus ne soient pas exhaustives, elles peuvent contribuer à garantir que les applications demandant le focus puissent obtenir le focus lorsqu'il n'y a pas de sons actifs de haute priorité. Même si les sons de haute priorité sont actifs, les demandes de mise au point différées doivent toujours être respectées et doivent pouvoir se concentrer une fois que le son de haute priorité s'arrête.
Service de volume de voiture OEM
Le service audio de la voiture gère les événements liés aux touches de volume soit en écoutant les réglages de volume du système audio, soit en écoutant les événements liés aux touches de volume directement depuis le service d'entrée de la voiture. Dans chaque cas, le comportement par défaut du service audio de voiture consiste à déterminer quel groupe de volumes modifier en fonction des lecteurs audio actifs et d'une liste de priorités de contexte audio.
Nous fournissons deux listes de priorités de volume. La première liste considère 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 musique sont tous deux actifs en même temps, le volume de navigation est modifié lors d'un événement de touche de volume.
- La navigation
- Appel
- Musique
- Annonce
- Commande vocale
- Sonnerie d'appel
- Son du système
- Sécurité
- Alarme
- Notification
- Statut du véhicule
- Urgence
Pour rendre la gestion des événements liés aux touches de volume moins complexe, le service audio de voiture dispose d'une deuxième liste prioritaire de contexte audio :
- Appel
- Médias
- Annonce
- Commande vocale
Cette liste est également présentée par ordre décroissant. Le but de cette deuxième liste est de permettre de modifier des sons plus courants via des événements clés. Les sons peu courants, peut-être d'une durée plus courte, peuvent être gérés uniquement 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é dans la gestion des volumes, OemCarAudioVolumeService est introduit dans Android 14 :
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
Le service de volume audio de voiture OEM a une méthode unique, qui prend en compte un volumeAdjustment et un OemCarAudioVolumeRequest :
class OemCarAudioVolumeRequest {
int audioZoneId;
int callState;
List<AudioAttributes> activePlaybackAttributes;
List<AudioAttributes> duckedAttributes;
List<CarVolumeGroupInfo> volumeGroupState;
}
L' activePlaybackAttributes de la requête possède les attributs audio actifs. Les duckedAttributes sont tous des attributs audio actuellement esquivés. Le volumeGroupState a 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 volumes doit être modifié. Les résultats doivent être renvoyés dans OemCarVolumeChangeInfo :
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
Le change booléen indique si un volume a changé, true indique qu'il y a un changement et que le groupe de volumes doit être mis à jour. Le volumeGroupChanged est le groupe de volumes réel qui doit être modifié. 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 volumes de navigation doit être mis en sourdine, alors le booléen sera true et le groupe de volumes renvoyé devra être celui de la navigation.
Service d'esquivement de voiture OEM
Le service audio de voiture gère l'atténuation audio en surveillant les changements de focalisation audio et en envoyant un signal à AudioControl HAL concernant les appareils audio à esquiver. Lorsque le focus change, tous les détenteurs de focus actifs sont évalués pour déterminer lesquels doivent être esquivés en fonction de cet ensemble de règles d'esquive statique :
- Les sons d'urgence évitent tout sauf les sons d'appel
- La sécurité évite tout sauf les sons d'urgence
- La navigation évite tout sauf les sons de sécurité et d'urgence
- Appelez les canards à l'exception des sons de sécurité, d'urgence et de navigation.
- Les canards vocaux appellent les sons de la sonnerie
- La musique et les annonces doivent être évitées par tout
Ces règles ne sont pas exhaustives et les constructeurs OEM restent responsables de la détermination de la manière dont les sons doivent être atténués en fonction de ces directives. Les OEM peuvent contrôler ces recommandations plus activement en fonction des exigences disponibles. L' OemCarDuckingService est introduit dans Android 14 :
class OemCarAudioDuckingService {
List<AudioAttributes> evaluateAttributesToDuck(
OemCarAudioVolumeRequest request);
}
Cette API est appelée depuis le service audio de la voiture lors des changements de focus audio. Il réutilise l' OemCarAudioVolumeRequest introduit dans le service de volume de voiture OEM et contient les informations pertinentes pour prendre la décision concernant les attributs à ignorer. La liste des attributs audio à ignorer depuis l'API est comparée à l'état audio actuel :
Attribut audio actuellement ignoré :
- Sur la liste, continue d'être esquivé
- Pas sur la liste, l'esquive est désactivée
Attribut audio non actuellement ignoré :
- Sur la liste, esquivé
- Pas sur la liste, l'esquive est désactivée
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 esquivés ou à la liste des périphériques audio non atténuations. Ceci est finalement envoyé à AudioControl HAL pour effectuer le ducking requis au niveau matériel.
La figure ci-dessous montre un diagramme de séquence simplifié du contrôle de ducking audio pour une demande de focus lorsque le service de ducking OEM est utilisé :
La séquence démarre lorsqu'une application demande le focus Gérer l'audio via les API publiques du gestionnaire audio. La demande est transmise au service audio automobile pour déterminer les résultats. Lorsque la focalisation audio est décidée, l'atténuation audio est évaluée par le service audio de la voiture appelant OemCarAudioDuckingService pour évaluer quels attributs audio doivent être esquivés. Une fois les résultats renvoyés par l'API evaluateAttributesToDuck , les périphériques audio à esquiver sont calculés, et enfin les informations sont envoyées à AudioControl pour appliquer l'esquive au matériel audio.
Implémentation de référence du service audio de voiture OEM
AAOS fournit une implémentation de référence du service de voiture 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 le 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 de 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 le service de voiture OEM, utilisez la commande car service dump pour le service OEM :
adb shell dumpsys car_service --oem-service
Les résultats pourraient être similaires au résultat ci-dessous :
***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 booléen de chaque lot d'informations dump détermine l'état de la fonctionnalité et du service. Par exemple, les informations de vidage mIsOemServiceReady spécifient si le service est prêt à être utilisé, où true indique qu'il est prêt et false indique qu'il ne l'est pas.