Couche d'abstraction de la plate-forme HAR

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

HAR, également appelé 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 uniques.

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 à la 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 de 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 distinct, ce code gère la communication interprocessus (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 de nouveaux problèmes.

Terminologie

Les termes suivants sont utilisés sur cette page :

Application basée sur HAR

Application spécifique à un OEM ou à une fonction, créée avec le framework HAR. Les applications diffèrent selon 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 plates-formes, qui permet de vérifier que les implémentations de plates-formes sont compatibles avec le framework HAR sur une plate-forme donnée.

Hors du champ d'application

HAR ne traite pas les points suivants :

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

• Cas de test : cas 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 renvoyées, 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 cas de test.

Structure de crate de haut niveau pour l'abstraction de la plate-forme

Les projets Rust sont constitués de crates. La figure 1 présente la structure de crate 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 trait Rust) 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 le crate HAR sans implémentation de plate-forme spécifiée. Ceci 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 présentées dans ce schéma :

Figure 1. Crate HAR.

Structure générale dans display-safety

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

Figure 2. Modules d'abstraction.

Une suite de tests est structurellement semblable à une application, mais ne repose que sur un crate d'implémentation de plate-forme donné. La suite de tests doit faire référence aux traits et aux structures définis dans le framework HAR, mais ne doit pas faire référence à 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.

Conventions de dénomination et structures de framework

Ce tableau présente les noms et les structures suivants :

• Instances trait de sous-système attendues fournies par le framework HAR. Chaque trait représente un sous-système spécifique à la 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 attendent 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.

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. Sinon, 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 plates-formes 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 s'étend 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 spécifiques à la plate-forme des abstractions.

Compiler 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.