Couche d'abstraction de la plate-forme HAR

Utilisez le moteur de rendu haute disponibilité (HAR) pour afficher les informations sur le véhicule qu'Android ne peut pas afficher. Cela peut être dû à des problèmes de démarrage, de disponibilité, de sécurité ou de réglementation. HAR est une application portable intégrée écrite en Rust.

Le framework HAR inclut le code que vous utilisez pour créer des applications. Une application créée avec HAR est une application basée sur HAR. Le framework HAR comporte des sections de code pour différentes plates-formes. Par exemple, sur un système Linux, vous utilisez des bibliothèques telles que tinyalsa pour les sons. QNX possède ses propres bibliothèques audio.

Une plate-forme inclut du matériel, un système d'exploitation, des bibliothèques système et d'autres facteurs. Le code spécifique à une plate-forme comporte des parties appelées sous-systèmes. Chaque sous-système gère une fonctionnalité de la plate-forme, telle que l'audio, les caméras EVS ou les données du véhicule. Pour prendre en charge une plate-forme, le framework HAR doit implémenter tous ses sous-systèmes.

Le code du sous-système spécifique à la plate-forme peut s'exécuter dans le même processus que l'application basée sur HAR ou dans un processus distinct. Lorsqu'il est séparé, ce code gère la communication inter-processus (IPC) pour vérifier que la plate-forme est compatible avec l'application. Les mécanismes IPC complexes doivent faire partie du code spécifique à la plate-forme.

La suite de tests HAR exécute des tests sur tous les sous-systèmes implémentés pour une plate-forme. Utilisez cette suite pour vérifier si les plates-formes répondent aux exigences HAR et pour identifier d'éventuels nouveaux problèmes.

Terminologie

Ces termes sont disponibles sur cette page :

Application basée sur HAR
Une application OEM ou spécifique à une fonction, créée avec le framework HAR. Les applications diffèrent par leur état et d'autres aspects personnalisables.
Framework HAR
Fournit un ensemble d'outils de base utilisés pour créer des applications.
Abstraction de la plate-forme HAR
Partie du framework HAR qui fournit une API connue que toutes les plates-formes cibles doivent implémenter.
Suite de tests HAR
Série de tests connus sur les implémentations de la plate-forme, permettant de vérifier que les implémentations de la plate-forme sont compatibles avec le framework HAR sur une plate-forme donnée.

Hors du champ d'application

HAR ne traite pas les problèmes suivants :

  • Implémentations individuelles pour toutes les cibles de plate-forme : implémentations pour les plates-formes cibles. Cette page décrit plutôt les interfaces que les implémentations de la plate-forme doivent respecter et qu'une suite de tests doit satisfaire.

  • Scénarios de test : scénarios de test spécifiques pour toutes les interfaces. Cette page décrit plutôt les fonctions individuelles des interfaces, y compris les arguments, les valeurs de retour, les comportements attendus et les effets secondaires attendus. Cette page décrit la suite de tests dans laquelle vous pouvez implémenter et exécuter des scénarios de test.

Structure de crate de haut niveau d'abstraction de plate-forme

Les projets Rust sont constitués de crates. La figure 1 montre la structure de la caisse pour la couche d'abstraction de la plate-forme HAR. La couche d'abstraction de la plate-forme affecte au moins deux crates Rust :

  • Les abstractions (descriptions Rust trait) se trouvent dans le crate du framework HAR.

  • Les implémentations pour une plate-forme sont effectuées par un crate har-platform-x distinct. Par exemple, har-platform-linux ou har-platform-android.

Vous ne pouvez pas compiler ni tester la caisse HAR sans une implémentation de plate-forme spécifiée. C'est intentionnel, car le framework HAR est un framework.

Une application qui spécifie une plate-forme doit être créée avec ce framework pour fonctionner et être testée. Les connexions entre le framework HAR et la plate-forme sont représentées dans ce schéma :

Caisse HAR

Figure 1. Caisse HAR.

Structure générale dans display-safety

Cette conception ajoute une série de nouvelles caisses au dépôt display_safety, comme illustré dans la figure 2 :

Crate, framework et application HAR

Figure 2. Modules d'abstraction

Une suite de tests est structurellement semblable à une application, mais elle ne repose que sur une caisse d'implémentation de plate-forme donnée. La suite de tests doit faire référence aux caractéristiques et aux structures définies dans le framework HAR, mais pas à des implémentations plus complexes.

Description générale de la couche d'abstraction de la plate-forme

Ce tableau décrit les sous-systèmes spécifiques à la plate-forme définis par la couche d'abstraction de la plate-forme HAR.

Nom de l'abstraction Fonction associée Description Remarques
OpenGL Rendu 2D Fournit des fonctionnalités de rendu OpenGLES 2.0/3.0 au crate du framework HAR.
Audio Rendu audio Fournit une interface de type Android SoundPool pour gérer et lire l'audio du système.
Camera Écran de la caméra du véhicule Fournit une interface de type HAL EVS pour gérer et afficher les informations de la caméra du véhicule.
Looper Boucle principale de l'application et configuration de l'affichage Fournit une interface de type Android Looper pour gérer les boucles principales de l'application et la configuration d'affichage spécifiques à la plate-forme.
UserInput Écran tactile, clavier, volant ou contrôleur rotatif, et autres entrées spécifiques à la plate-forme Fournit une interface permettant de fournir des entrées tactiles et au clavier aux applications basées sur HAR. Implémentation de référence basée sur Linux evdev dans har-user-input-evdev.
VehicleData Entrée de l'état du véhicule Fournit une interface permettant de fournir aux applications basées sur HAR un flux de données arbitraires sur le véhicule, telles que celles fournies par Android VHAL ou un bus CAN.
ResourceManager Document de conception mis en cache spécifique à l'application Fournit un cache en mémoire des ressources nécessaires au démarrage de HAR, telles que les images mises en cache et les documents de conception. Aucun cache du disque n'a encore été implémenté.
Logging Journalisation et télémétrie du système Fournit une compatibilité avec la journalisation spécifique à la plate-forme à l'aide du système de traçage. Cela permet de collecter les données de télémétrie requises par la plate-forme.
Tracing Traçage système Fournit une abstraction pour l'intégration aux systèmes de traçage et de profilage.
Monitoring Surveillance du système Kit d'outils permettant de surveiller les performances et les latences dans le framework HAR.
Commlib Données du véhicule Implémentation de référence utilisant la sérialisation protobuf. Obsolète : utilisez les API définies dans reference/harry-control-api et les implémentations harry-grpcio-server et harry-tonic-server (implémentation de référence).
TestSupport Tester les hooks de compatibilité Permet de configurer et de supprimer des scénarios de test, de générer des événements de test et de créer des artefacts de test. Par exemple, générer des événements tactiles simulés pour tester UserInput et générer des captures d'écran pour l'analyse. Cette fonctionnalité est verrouillée par Rust pour empêcher son inclusion dans les builds de production.

Conventions d'attribution de noms et structures de framework

Ce tableau présente ces noms et structures :

  • Instances de sous-système trait attendues fournies par le framework HAR. Chaque trait représente un sous-système spécifique à une plate-forme qui doit être implémenté.

  • Noms attendus des implémentations de sous-systèmes spécifiques à la plate-forme dans n'importe quel crate de plate-forme. Les applications basées sur HAR s'attendent à ce que ces noms spécifiques soient implémentés.

  • Instances enum et struct du framework HAR associées, généralement utilisées pour transmettre des informations des implémentations liées à la plate-forme au framework HAR.

Noms des caractéristiques Noms des implémentations Énumération et structures du framework HAR
GlContextFactory OpenGL trait harry::Renderer
harry::DisplayRotation
AudioApiFactory Audio harry::AudioApi
harry::AudioDevice
harry::VolumeMillibel
ICameraManager Camera harry::ICameraDevice
harry::CameraDescriptor
Looper Looper harry::LooperMessage
harry::LooperOptions
harry::DisplayId
PlatformVehicleData VehicleData harry::VehicleDataType
harry::VehicleDataListener
ResourceManager (Struct) ResourceManager harry::ResourceManagerMessage
harry::ResourceToken
harry::RawImageData
PlatformTracing Tracing N/A
HarPerformanceMonitor Monitoring harry::Renderer
harry::ResolveLatencyToken
PlatformTestSupport TestSupport harry::TestConfig
harry::TestDisplayConfig

Erreurs et traitement des erreurs

Les API proposées utilisent le type Rust Result<>. Rust vous oblige à vérifier les types Result qui comportent des erreurs. Si ce n'est pas le cas, le compilateur génère un avertissement ou une erreur. Une vérification au moment de la compilation applique la vérification des erreurs à partir du code spécifique à la plate-forme.

Les erreurs renvoyées par les implémentations de la plate-forme sont de type harry::error::Error. Pour vérifier que les types d'erreurs de la plate-forme ne sont pas divulgués dans le code de l'application, utilisez le type d'erreur standard fourni par le framework HAR.

Le type harry::error::Error se développe pour inclure des erreurs spécifiques pour tous les sous-systèmes :

// This is Rust
pub enum Error {
  Msg(String), // A generic message string
  // Legacy error type, likely to be removed or merged into Msg
  Audio(String),
}

Les erreurs irrécupérables sont principalement renvoyées via les interfaces et les rappels définis.

Conception détaillée de la suite de tests

Cette section décrit la conception de la suite de tests, qui vérifie les implémentations des abstractions spécifiques à la plate-forme.

Créer les tests de la suite de tests

Pour les builds Soong (définis par les fichiers Android.bp), les tests sont compilés dans le cadre du système de compilation de la plate-forme Android, et leur exécution est gérée par atest.

Exécuter la suite de tests

Pour tester une plate-forme individuelle, utilisez la commande atest avec la cible de test appropriée (par exemple, atest <module_name>). Cette commande déploie et exécute les tests sur un appareil ou un émulateur Android.