À partir de 2026, pour nous aligner sur notre modèle de développement stable et garantir la stabilité de la plate-forme pour l'écosystème, nous publierons le code source sur AOSP au deuxième et au quatrième trimestre. Pour créer et contribuer dans AOSP, utilisez android-latest-release. La branche de fichier manifeste android-latest-release fera toujours référence à la version la plus récente envoyée à AOSP. Pour en savoir plus, consultez Modifications apportées à AOSP.

Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

Mises à jour automatiques du catalogue et intégration des LSP

La plate-forme de véhicule défini par logiciel (SDV) contient de nombreux catalogues VSIDL dans la base de code. Le fichier CATALOG_UPDATE fournit une configuration centralisée pour chaque catalogue, ce qui permet à la fois les mises à jour automatiques et l'intégration de l'IDE.

Rôle du fichier CATALOG_UPDATE

Le fichier CATALOG_UPDATE a deux objectifs principaux :

Mises à jour automatiques : le fichier permet à l'outil regenerator de trouver et de recompiler tous les catalogues du système lorsque le compilateur ou les dépendances changent.
Prise en charge du protocole LSP (Language Server Protocol) : le serveur de langage VSIDL utilise ce fichier pour découvrir la racine du catalogue et résoudre les dépendances. Cela permet d'activer des fonctionnalités telles que "Accéder à la définition", la saisie semi-automatique et la validation en temps réel pour les types définis dans d'autres catalogues.

Configurer un catalogue

Pour activer les mises à jour automatiques et la prise en charge du protocole LSP pour un catalogue VSIDL, créez un fichier CATALOG_UPDATE dans le répertoire racine du catalogue. Il s'agit d'un fichier protobuf texte.

Champs de configuration du catalogue

output_path (chaîne, facultatif) : chemin d'accès relatif de la racine du catalogue au répertoire dans lequel le code middleware généré doit être placé.
dependency_catalog_paths (chaîne répétée) : liste des chemins d'accès relatifs aux autres répertoires de catalogue. Le serveur LSP utilise ces chemins d'accès pour résoudre les types externes.
vsidlc_gen_args (chaîne, facultatif) : arguments transmis à vsidlc. Le serveur LSP les inspecte pour appliquer les règles de validation appropriées (par exemple, "--apex").
prebuilts_output_path (chaîne, facultatif) : chemin d'accès aux précompilés de configuration d'exécution générés.
prebuilts_filegroup (chaîne, facultatif) : nom Soong filegroup pour les précompilés.

Exemple de configuration

# proto-file: //system/software_defined_vehicle/tools/regenerator/proto/catalog.proto
# proto-message: Catalog

output_path: ".."
dependency_catalog_paths: "../../../../../automotive_services/diagnostics/vsidl/v1"
vsidlc_gen_args: "--apex"

Pourquoi les mises à jour automatiques sont-elles nécessaires ?

La maintenance manuelle du code généré pour chaque catalogue est problématique pour plusieurs raisons :

Mises à jour du compilateur : lorsque le compilateur est mis à jour avec des corrections de bugs ou de nouvelles fonctionnalités, tous les codes et fichiers générés qui ne sont pas couverts par une genrule dans un fichier Android.bp doivent être actualisés pour maintenir la cohérence.
Gestion des dépendances : les modifications apportées à un catalogue de base nécessitent souvent la régénération des catalogues en aval.
Précision : les mises à jour automatiques réduisent le risque d'erreur humaine lors de la spécification des chemins d'accès et des dépendances.

Exécuter l'outil regenerator

L'outil regenerator parcourt l'arborescence des répertoires à partir de la racine SDV et recherche les fichiers nommés exactement CATALOG_UPDATE.

Pour mettre à jour tous les catalogues configurés :

Créez l'outil :
```
m regenerator
```
Exécutez l'outil :
```
regenerator
```
Vous pouvez également l'exécuter de manière récursive pour un répertoire spécifique : console regenerator --root /path/to/directory

L'outil met à jour les fichiers générés et effectue une compilation complète (m droid) pour vérifier que les modifications sont compatibles avec le reste du système.