Activation des nouveaux services de plug-ins OEM automobiles sous Android 14 certains composants de la voiture à configurer. Concernant l'audio, trois nouveaux Des services de plug-ins sont introduits, ce qui permet 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 et coupe le son
- Contrôle de la diminution du volume
Architecture du service de plug-ins pour voitures
La figure ci-dessous présente les services automobiles et leur relation. au service automobile OEM. À l'instar des processus de l'application et du processus d'entretien automobile, le processus d'entretien automobile OEM occupe son propre espace de processus.
L'entretien 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 obtenir l'OEM du système audio de la voiture.
service:
public final class OemCarServiceImp extends OemCarService {
@Override
public OemCarAudioFocusService getOemAudioFocusService();
@Override
public OemCarAudioDuckingService getOemAudioDuckingService();
@Override
public OemCarAudioVolumeService getOemAudioVolumeService();
}
Pour
exemple, voir
l'application de test de référence définie
packages/services/Car/tests/OemCarServiceTestApp
Même si le service est lancé par un service automobile, il ne se déclenche pas automatiquement
héritent des autorisations disponibles
pour le service audio automobile. À ce titre, toute
les autorisations requises par les services OEM doivent être acquises
sur le mécanisme d'attention. Par exemple, consultez
packages/services/Car/data/etc/com.android.car.oemcarservice.testapp.xml
Service audio pour voiture avec architecture de service OEM
Dans AAOS, le service audio pour voiture gère ces actions:
- Routage audio
- Priorité audio
- Diminution du volume
- Volume et coupure du son
Avant Android 14, ce comportement était essentiellement statique et ne pouvait être modifié que via les paramètres, mais pour un nombre très limité de cas. Android 14 introduit un mécanisme pour l'audio des voitures pour communiquer avec un composant défini par l'OEM qui gère:
- Priorité audio
- Diminution du volume
- Volume et coupure du son
La figure ci-dessous illustre une architecture simplifiée pour le service audio d'une voiture et d'OEM automobile. Le service audio pour voiture définit différents hooks pouvant appeler au service audio OEM de la voiture pour gérer le comportement audio. Le second ne se produit que si le composant de service audio pour voiture correspondant est défini. Dans le cas contraire, le service audio pour 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 en mode Pour chaque appel, le service audio transmet les parties requises 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 d'évaluation de la priorité audio, il transmet l'état actuel de la pile au service audio de l'OEM de la voiture. L'état actuel inclut le conteneur de ciblage actuel et les perdants actuels. Concentrez-vous sur les personnes en baisse Requêtes de focus qui font toujours partie de la pile, mais qui ont été temporairement perdues le focus.
Le service audio de la voiture doit gérer toute l'activité audio dans la voiture. Si la voiture ne gère pas certaines parties du comportement audio, les informations communiquées au service audio de l'OEM de la voiture sont incomplètes. Par exemple, si un OEM écrase la gestion de la priorité audio dans le service automobile en enregistrant sa propre règle de ciblage audio, le service audio de la voiture ne peut pas fournir au service audio de l'OEM de la voiture. Cela peut affecter la capacité de la voiture Service audio OEM pour prendre des décisions, car il peut manquer d'informations non visibles au service audio de la voiture.
Pour effectuer des actions, le service audio de la voiture appelle les services automobiles OEM. Ces appels sont effectuées 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 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 lors des évaluations directes de l'API. L'élément service audio pour voiture fournit les informations nécessaires pour que les appels entre deux processus n'ont besoin que d'aller dans une direction.
Définitions des services audio pour voiture OEM
Service de focalisation audio pour voiture OEM
Le service audio automobile gère les requêtes de ciblage audio des applications en enregistrant un écouteur de ciblage des règles audio. Le service audio automobile dispose d'un mécanisme permettant de gérer de mise au point sur la base d'une Matrice d'interaction. La matrice définit trois types d'interactions différents:
Interaction simultanée : Les personnes concernées peuvent conserver la même concentration en temps réel.
Interactions exclusives. La requête de sélection entrante est sélectionnée le conteneur de sélection actuel.
Refuser l'interaction. Demande de sélection entrante refusée sur la base de le conteneur de sélection actuel.
Bien que cette méthode soit suffisante pour certains cas d'utilisation dans le secteur automobile, elle ne répond pas à tous les critères
des besoins d'interaction pouvant différer en fonction des exigences de l'OEM. Pour cela, nous
présentez OemCarAudioFocusService
:
public interface OEmCarAudioFocusService {
OemCarAuddioFocusResults evaluateAudioFocusRequest(
OemCarAudioFocusEvaluationRequest request);
void notifyAudioFocusChange(
List<AudioFocusEntry> holder,
List<AudioFocusEntry> losers, int zoneId);
}
L'API evaluateAudioFocusRequest
est appelée à tout moment depuis le service audio de la voiture.
qu'une demande concernant la priorité audio doit être évaluée.
API 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 newFocusRequest
par rapport aux
les détenteurs d'une priorité actuelle dans focusHolders
et les perdants actuels 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
réels de l'évaluation dans
audioFocusEvaluationResults
, qui indique si la requête actuelle a
été accordé, retardé ou a échoué. Toute modification apportée à la pile de sélection actuelle
doit être défini dans les entrées newLosers
et newlyBlocked
, selon la nature
du changement de pile.
Où newLosers
contient les entrées qui étaient auparavant actives, mais qui
devraient maintenant perdre leur focus, de façon permanente ou temporaire. Perdre la focalisation permanente
sera encore supprimé de la pile de ciblage audio, et les perdants de focus temporaires
sera déplacé vers la pile actuelle des perdants de sélection jusqu'à ce qu'ils le récupèrent ou qu'ils soient
sont abandonnés par le demandeur d'origine. Quoi qu'il en soit, l'auditeur de la concentration
les requêtes recevront un focus
correspondant perdu.
La liste newlyBlocked
contient les entrées qui se trouvaient auparavant dans le perdant de sélection
mais sont désormais bloquées par la nouvelle entrée. Le blocage peut être définitif
transitoire, pour une mise au point permanente bloquée, l'entrée est supprimée de la pile
et la perte de mise au point sont envoyées aux écouteurs. Pour la perte de focalisation temporaire,
l'entrée restera dans la pile des perdants de sélection, mais un nouveau bloqueur de focus sera
ajouté à sa liste de blocage, aucune perte de focus n'est envoyée comme c'était le cas auparavant
envoyé lors de son blocage initial. La demande sera enfin débloquée
les blocages actuels sont supprimés, ou il est supprimé de la pile si le curseur est
sont abandonnés.
La deuxième API, notifyAudioFocusChange
, est une méthode à sens unique appelée sur chaque
ou abandonne la requête de focus audio. L'API est principalement utilisée pour informer le service OEM
sur les changements de focus, qui peuvent affecter le comportement du service audio de la voiture OEM.
Consignes pour l'évaluation des priorités
Dans AAOS, la priorité audio permet de gérer la lecture audio et de déterminer application doit respecter afin d'offrir une expérience optimale à l'utilisateur. À ce titre, Le service du plug-in OEM doit tenir compte des éléments suivants lors de la gestion Requête de focus audio:
Sans priorité audio haute priorité debout (comme un appel téléphonique, les applications d'urgence ou de sécurité) doivent pouvoir mettre l'accent de manière temporaire ou permanente.
Lorsqu'un ciblage multimédia est actif, les applications qui demandent:
Priorité à l'utilisation des appels : doit pouvoir recevoir le focus simultanément ou exclusivement.
Objectif d'utilisation de la navigation : il doit pouvoir être sélectionné soit simultanément ou exclusivement.
Priorité à l'utilisation de l'Assistant, devrait pouvoir la recevoir simultanément ou exclusivement.
Lorsque vous êtes en position debout, priorité à l'audio de haute priorité (comme un appel téléphonique, un appel d'urgence ou alerte de sécurité) sont actives, les signaux audio entrants sont prioritaires. doit être soit accordée, soit retardée selon les besoins.
Bien que les suggestions ci-dessus ne soient pas exhaustives, elles peuvent garantir que les applications demandant le focus doivent pouvoir l'être lorsqu'il n'y a les sons prioritaires. Même si les sons à priorité élevée sont actifs, la mise au point est décalée doivent toujours être respectées et être mises en avant une fois le son à priorité élevée s'arrête.
OEM (service de volume de voitures)
Le service audio de la voiture gère les événements des touches de volume en écoutant le volume des réglages depuis le système audio ou en écoutant directement les événements liés aux touches de volume à partir du service d'entrée de la voiture. Dans chaque cas, le comportement par défaut de la voiture du service audio consiste à déterminer le groupe de volumes à modifier en fonction des lecteurs audio et une liste de priorités pour le contexte audio.
Nous proposons deux listes de priorités pour les volumes. La première liste concerne tous les types de fichiers contextes dans cet ordre. La liste est présentée dans l'ordre décroissant : la priorité la plus élevée en haut et la priorité la plus basse en bas. Par exemple, si navigation audio et audio sont tous deux actifs en même temps, puis le volume de la 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 rendre la gestion des événements de touches de volume moins complexe, le service audio pour voiture dispose d'un liste de la deuxième priorité de contexte audio:
- Appeler
- Contenus multimédias
- Annonce
- Commande vocale
Cette liste est également présentée par ordre décroissant. L'objectif de cette deuxième liste est de permettre aux sons plus courants d'être modifiés par le biais d'événements de touches. Peu fréquent, éventuellement d'une durée plus courte, à gérer dans les paramètres audio Interface utilisateur uniquement.
La version réelle du volume peut être définie à l'aide du
Configuration de audioVolumeAdjustmentContextsVersion
. La configuration peut être
définie sur 1
ou 2
(2
est la valeur par défaut).
Pour gérer les volumes de façon plus flexible,
OemCarAudioVolumeService
est introduit dans Android 14:
public interface OemCarAudioVolumeService {
OemCarvolumeChangeInfo getSuggestedGroupForVolumeChange(
OemCarAudioVolumeRequest request, int volumeAdjustment);
}
Le service de volume audio de la voiture OEM dispose d'une seule méthode, qui prend une
volumeAdjustment
et OemCarAudioVolumeRequest
:
class OemCarAudioVolumeRequest {
int audioZoneId;
int callState;
List<AudioAttributes> activePlaybackAttributes;
List<AudioAttributes> duckedAttributes;
List<CarVolumeGroupInfo> volumeGroupState;
}
L'élément activePlaybackAttributes
de la requête comporte les attributs audio actifs. La
Les duckedAttributes
correspondent à tous les attributs audio actuellement atténués. La
volumeGroupState
indique l'état actuel du groupe de volumes. La demande
représente l'état actuel de la pile audio et peut servir à déterminer
le groupe de volumes à modifier. Les résultats doivent être renvoyés au format
OemCarVolumeChangeInfo
:
class OemCarVolumeChangeInfo {
boolean change;
CarVolumeGroupInfo volumeGroupChanged;
}
La valeur booléenne change
indique si un volume a été modifié, true
indique que
un changement se produit
et le groupe de volumes doit être mis à jour. La
volumeGroupChanged
est le groupe de volumes réel à modifier. Ce
doit être modifié conformément au paramètre volumeAdjustment
d'origine
transmis à l'API. Par exemple, si les résultats indiquent que la navigation
le groupe de volumes doit être coupé, la valeur booléenne serait true
, et la valeur renvoyée
pour la navigation.
Service d'atténuation des véhicules OEM
Le service audio automobile gère la diminution du volume audio en surveillant les changements de ciblage audio et
envoi d'un signal au HAL AudioControl
concernant les appareils audio à ignorer.
Lorsque l'élément principal change, tous les conteneurs actifs sont évalués pour déterminer
qui devrait être abaissé en fonction de cet ensemble d'atténuation statique
rules:
- Les alertes d'urgence laissent tomber tout le monde, sauf les sons d'appel
- La sécurité passe inaperçue, sauf les alertes d'urgence
- La navigation masque tout, sauf les alertes de sécurité et d'urgence
- Appel pour éviter tout, sauf les sons de sécurité, d'urgence et de navigation
- La voix réduit les sonneries d'appel
- La musique et les annonces ne doivent pas être remarquées
Ces règles ne sont pas exhaustives, et les OEM restent chargés de déterminer
comment les sons doivent être atténués
par rapport à ces directives. Les OEM peuvent contrôler
recommandations plus activement
en fonction des exigences disponibles. La
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 ciblage audio. Il réutilise
le OemCarAudioVolumeRequest
introduit dans
OEM (service de volume de voitures), et contient les informations
pour décider des attributs à exclure. La liste des
attributs audio à partir de l'API est comparé à l'état audio actuel:
Attribut audio actuellement baissé:
- Dans la liste, elle est toujours baissée
- Pas dans la liste, diminution de la diminution désactivée
L'attribut audio n'est pas abaissé pour le moment:
- Dans la liste, baissé
- Pas dans la liste, diminution de la diminution désactivée
Le service audio de la voiture détermine ensuite les périphériques de sortie audio appartiennent et les ajoute à la liste des périphériques de sortie audio baissés ou des appareils audio non dupliqués, respectivement. Ce numéro est finalement envoyé AudioControl HAL pour effectuer les actions suivantes : la diminution nécessaire au niveau du matériel.
La figure ci-dessous montre un diagramme séquentiel simplifié de la diminution du volume du son. pour une requête de focus lorsque le service de diminution OEM est utilisé:
La séquence commence lorsqu'une application demande
Gérer la priorité audio
via les API publiques Audio Manager. La requête est transmise à l'audio de la voiture.
pour déterminer les résultats. Une fois l'audio défini, la diminution du volume
est évaluée par le service audio de la voiture qui appelle OemCarAudioDuckingService
pour
et d'évaluer quels attributs audio doivent être abaissés. Une fois les résultats renvoyés
à partir de l'API evaluateAttributesToDuck
, les appareils audio à canard sont calculés,
Enfin, les informations sont envoyées à AudioControl
pour appliquer la diminution
au matériel audio.
Mise en œuvre de référence OEM pour le service audio pour voiture
AAOS fournit une implémentation de référence du service automobile OEM dans
packages/services/Car/tests/OemCarServiceTestApp
, qui implémente la
OemCarService
, avec OemCarAudioFocusService
,
OemCarAudioDuckingService
et OemCarAudioVolumeService
. Dans le second cas,
et 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 demande de mise au point
lorsque evaluateAudioFocusRequest
est appelé.
Débogage d'applications de test de référence
L'application de test d'entretien automobile OEM fait partie du code source AOSP. les OEM peuvent apporter
en fonction de leurs besoins. Pour le débogage, utilisez 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
de service automobile pour
Service OEM:
adb shell dumpsys car_service --oem-service
Les résultats peuvent ressembler à la sortie 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 valeur booléenne de chaque lot d'informations dump
détermine l'état de l'élément géographique
et de service. Par exemple, les informations de vidage mIsOemServiceReady
indiquent si le
Le service est prêt à être utilisé, où true
indique qu'il est prêt et false
indique qu'il n'est pas prêt.