Cette page a été traduite par l'API Cloud Translation.

Service de plug-ins audio pour voiture

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.