Android Automotive 26Q2

Cette page décrit les fonctionnalités et améliorations de la version 26Q2 d'Android Automotive OS (AAOS) (niveau d'API 37), qui inclut huit nouvelles fonctionnalités et résout 180 problèmes.

Framework AAOS

Gestion des utilisateurs

  • Activation de la notification ManagedServices pour les utilisateurs visibles en arrière-plan.

  • Ajout de la prise en charge de DocumentsUI pour les utilisateurs visibles en arrière-plan.

Audio et radio

  • Application du focus audio : activation de l'application du focus audio dans AAOS, ce qui est essentiel pour la sécurité des utilisateurs.

  • Rappel de gain audio : ce rappel permet au matériel audio de communiquer les modifications de volume aux composants logiciels, y compris les applications, et permet à l'ensemble du système de détecter de manière cohérente les niveaux audio actuels. Les OEM peuvent ajouter de nouveaux événements au rappel de gain audio et personnaliser le comportement dans le service OEM.

Framework de voiture

  • Disponibilité des propriétés du véhicule : permet aux OEM d'activer et de désactiver dynamiquement les propriétés du véhicule, avec des états supplémentaires pour les propriétés définies par le fournisseur ou non disponibles.

Sécurité de l'écran

La suite AAOS Display Safety introduit une architecture graphique isolée et renforcée pour la sécurité de la nouvelle plate-forme SDV, offrant une expérience de cockpit unifiée et réactive. Display Safety comprend les composants suivants :

  • Moteur de rendu à haute disponibilité (HAR) : moteur à faible latence qui fonctionne indépendamment du système d'infodivertissement principal pour garantir un affichage déterministe des données critiques du véhicule, telles que le rapport engagé, la vitesse et les témoins. Il utilise une boucle de rendu isolée pour la sécurité et la composition pour un mélange efficace.

  • Chaîne d'outils de compilation et de surveillance de la conception de sécurité : ensemble d'utilitaires automatisés permettant de vérifier que les éléments visuels essentiels à la sécurité sont conformes aux normes de mise en page de l'écran. Il applique un rendu parfait au pixel près et utilise la segmentation des différences pour la conformité visuelle.

  • Application de cluster Android (DriverUI) : application interactive qui se synchronise sur des canaux AAOS SDV résilients pour composer le contenu d'infodivertissement avec les couches de sécurité HAR sur l'écran du cluster.

Connectivité

  • Messagerie avec plusieurs appareils : correction d'une régression dans la pile de téléphonie qui empêchait le système de stocker les messages provenant de plusieurs appareils connectés.

  • Intégration PANS-and-Play (PnP) : mise à jour de Google Play pour qu'il soit compatible avec PANS afin d'améliorer l'expérience utilisateur.

UI du système et expériences

  • UI du système évolutive : extension du framework d'UI évolutive en définissant une API qui permet aux OEM de personnaliser les composants d'UI du système au niveau du système. Cela unifie le workflow et permet d'appliquer de manière cohérente l'identité de la marque.

  • Référence multi-utilisateur et multi-écran (MUMD) : fourniture d'un exemple de configuration multi-écran qui utilise des utilisateurs en arrière-plan simultanés avec une interface utilisateur évolutive.

  • Notifications prioritaires (HUN) pour l'interface utilisateur évolutive : rationalisation de la personnalisation par les OEM et réduction des coûts en modularisant les composants de l'UI du système tels que le système de chauffage, ventilation et climatisation (HVAC) et l'UI du système de la voiture. Les principales fonctionnalités incluent un mécanisme de traduction HUNPanel dédié pour les animations définies par l'état et une nouvelle classe HUNWindow pour une gestion optimisée du cycle de vie des fenêtres.

  • Modularisation de l'UI du système de la voiture : déconstruction de l'UI du système Android monolithique en composants modulaires indépendants pour réduire les coûts des OEM et éviter les problèmes de compatibilité.

Applications principales

  • API AppFunction : permet aux agents de se connecter aux applications.

Appareil photo

  • Obsolescence du système de vision étendue (EVS) : obsolescence des API EVS pour réduire la fragmentation et unifier la surface de l'API de l'appareil photo. Les OEM doivent plutôt utiliser les API Camera2. Pour en savoir plus, consultez la section Migrer vers Camera2.

Véhicule défini par logiciel (SDV)

  • Véhicules définis par logiciel : extension des fonctionnalités d'Android au-delà de l'écran d'infodivertissement pour alimenter plusieurs domaines de la voiture avec une architecture orientée services (SOA) évolutive et une intégration transparente avec l'IVI. Inclut HAR pour les combinés d'instruments, ce qui permet des itérations rapides de conception et de développement pour une solution de cockpit complète.

Conformité

Pour valider votre implémentation AAOS, utilisez les suites de tests suivantes :

Problèmes de test connus

La version 26Q2 d'AAOS inclut les problèmes connus suivants liés aux tests :

  • CtsSurfaceControlTests[secondary_user_on_secondary_display]
    • #testImeVisible
    • #testImeVisibleWithZBelowRequest
    • #testImeZOrderedAboveEmbeddedWindowInChildWindow
    • #testImeVisibleWithZBelowTouch
  • CtsGraphicsTestCases
    • FrameRateOverrideTest#testAppDisplayModeGetRefreshRateDisplayModeReturnsPhysicalRefreshRateEnabled
    • FrameRateOverrideTest#testAppBackpressure
  • FrameRateOverrideTest#testAppDisplayGetRefreshRate
    • FrameRateOverrideTest#testAppChoreographer

Test automatisé nécessitant une validation manuelle

Le module suivant échoue aux tests automatisés (CTS) dans des configurations multi-utilisateurs ou multi-écrans spécifiques : CtsMediaAudioTestCases[secondary_user_on_secondary_display]. Vérifiez la fonctionnalité associée à l'aide de tests manuels.