Builds Android déclaratifs et prêts pour les agents avec Lightbuild

Bonjour !

Je m'appelle Juan Sebastian Oviedo.

Je suis responsable produit dans l'équipe Expérience développeur Android.

Je suis ici avec Scott, et aujourd'hui, nous sommes ravis de vous présenter un aperçu de Lightbuild, une nouvelle expérience de compilation expérimentale pour les applications Android.

Je vais vous présenter le contexte de ce projet, la philosophie qui le sous-tend et les raisons pour lesquelles nous pensons que le moment est venu de repenser la configuration des projets Android.

Je vous expliquerai également comment cette nouvelle approche nous prépare à l'avenir du développement d'applications Android.

Commençons par un peu de contexte sur le fonctionnement actuel.

Gradle et les scripts de compilation impératifs permettent aux développeurs de définir de manière programmatique presque tous les aspects de leurs compilations.

Par exemple, vous pouvez utiliser une logique qui calcule de manière dynamique les codes de version en fonction de l'historique Git, ou définir une tâche personnalisée qui transforme les éléments.

// build.gradle.kts
android {

  compileSdk = 37

  buildTypes {

    debug {

      // Custom logic in build script
      val commit = providers.exec {
        commandLine("git", "rev-parse",
                    "--short", "HEAD")
      }.standardOutput.asText.get()
       .trim()

      versionNameSuffix = "-$commit"

    }

  }

}

En plus de Gradle, il existe AGP (le plug-in Android Gradle), qui prend le moteur polyvalent de Gradle et l'adapte à la chaîne d'outils Android.

Ensemble, Gradle et AGP forment un système dynamique qui permet de configurer la compilation de millions d'applications de production aujourd'hui.

En raison de cette flexibilité, nos outils de développement fonctionnent selon un cycle de vie architectural spécifique.

Lorsque vous ouvrez un projet, changez de branche ou modifiez un fichier de compilation, l'IDE doit disposer d'une carte claire et d'une compréhension précise de la configuration de votre projet. Cela lui permet d'alimenter des fonctionnalités telles que la complétion de code et la navigation dans le code.

Comme les fichiers de compilation sont écrits dans un langage impératif et Turing-complet, la seule façon pour l'IDE de connaître la configuration est d'exécuter les scripts de compilation.

Lors de la synchronisation de l'IDE, le système de compilation passe par une phase de configuration.

Il évalue vos scripts de compilation, exécute la logique du plug-in et construit le modèle de projet.

Cela permet d'aligner la vue de votre projet dans Android Studio avec la configuration réelle de votre projet.

En tant que développeurs, votre priorité est de proposer une application Android de qualité et de la mettre à la disposition de vos utilisateurs.

Toutefois, la gestion des scripts de compilation, la mise à jour d'AGP et la synchronisation du projet avec l'IDE prennent du temps et demandent des efforts.

Plusieurs initiatives sont en cours chez Google et dans l'écosystème au sens large pour améliorer l'expérience des développeurs dans ce domaine.

Des initiatives telles que Declarative Gradle et la chaîne d'outils Kotlin visent à remplacer les scripts de compilation exécutables par une configuration de compilation déclarative.

Dans Android Studio, l'assistant de mise à niveau AGP vous guide pour effectuer les modifications nécessaires pour passer d'une version d'AGP à une autre.

Nous fournissons également une compétence de mise à niveau que les agents peuvent installer et suivre pour mettre à niveau AGP.

De plus, nous investissons dans des domaines tels que la synchronisation progressive et la synchronisation résiliente, afin que les développeurs bénéficient d'une meilleure expérience lors de la synchronisation et de l'importation de leurs projets.

Chacun de ces efforts cible une partie du puzzle afin que les développeurs puissent passer plus de temps à créer leurs applications et moins de temps à créer leurs projets, à gérer leurs fichiers de compilation et à synchroniser leurs projets.

En parallèle, nous nous sommes posé une question plus générale.

Et si nous repensions entièrement la façon dont les projets sont configurés ?

Lorsque nous examinons l'architecture des applications Android modernes aujourd'hui, nous constatons une évolution majeure vers une modularisation importante.

Les grandes bases de code comportent souvent des dizaines, voire des centaines de modules : modules d'interface utilisateur, modules de fonctionnalités, modules de domaine et modules de données.

Bien que l'application racine puisse parfois nécessiter un empaquetage personnalisé, la grande majorité de ces modules de bibliothèque suivent un modèle reproductible standardisé.

Ils n'ont pas besoin d'avoir du code exécutable arbitraire dans leurs fichiers de compilation.

Il leur suffit d'un moyen clair d'indiquer leur structure et leurs dépendances.

Cette observation nous a amenés à créer Lightbuild.

Lightbuild repose sur deux piliers.

Tout d'abord, il utilise une syntaxe déclarative pour la configuration, ce qui permet de séparer clairement la configuration de compilation et la logique.

Deuxièmement, il offre une expérience de synchronisation rapide de l'IDE grâce à la résolution anticipée des dépendances.

Je vais examiner chacun de ces piliers en détail pour que vous puissiez voir comment ils impactent votre workflow quotidien.

Commençons par le pilier de la configuration de compilation déclarative.

Examinez le fichier sur le côté gauche de l'écran.

Il s'agit de la configuration d'un module aujourd'hui.

// build.gradle.kts

plugins {
   alias(libs.plugins.android.library)
   alias(libs.plugins.kotlin.compose)
}

val gitCommit = providers.exec {
   commandLine("git", "rev-parse", "--short", "HEAD")
}.standardOutput.asText.get().trim()

android {
   namespace = "com.example.app"
   compileSdk = 37

   defaultConfig {
       minSdk = 24
       buildConfigField("String", "GIT_COMMIT",
                        "\"$gitCommit\"")
   }
   buildFeatures {
        compose = true
        buildConfig = true
   }
}

dependencies {
  implementation(platform(libs.androidx.compose.bom))
  implementation(libs.androidx.compose.ui)
  implementation(libs.androidx.compose.ui.graphics)
  ...

Comme ce fichier est un code exécutable, il peut contenir des définitions de variables locales, des appels à des fonctions d'assistance personnalisées ou à des plug-ins de convention, des instructions conditionnelles et des définitions de tâches intégrées.

Pour que l'IDE sache à quoi correspond cette configuration, il doit exécuter le script.

Maintenant, examinez le fichier sur le côté droit de l'écran.

Il s'agit de la configuration Lightbuild pour un module similaire.

# lightbuild.yaml

group: "com.example"
version: "1.0.0"

platform: android
type: library

android:
 namespace: "com.example.app"
 compileSdk:
   version:
     release:
       apiLevel: 37
 minSdk:
   version:
     release:
       apiLevel: 24
 dependencies:
   maven:
     - androidx.core:core-ktx:1.10.1
     - androidx.lifecycle:lifecycle-runtime-ktx:2.6.1
     - androidx.activity:activity-compose:1.8.0

Ce fichier contient uniquement des données déclaratives.

Il n'y a pas de définitions de variables locales, d'appels de fonctions d'assistance personnalisées, d'instructions conditionnelles ni de définitions de tâches intégrées.

Il indique clairement le type du module, ses cibles de SDK et ses dépendances.

Si un nouvel ingénieur rejoint votre équipe et ouvre ce fichier, il n'aura pas à déchiffrer d'idiomes de compilation personnalisés, et chaque module Lightbuild de chaque projet Lightbuild utilisera le même langage immédiatement lisible.

La séparation entre la configuration et la logique est idéale pour la lisibilité humaine, mais elle est encore plus révolutionnaire pour les workflows assistés par des agents.

À mesure que les développeurs adoptent des agents dans leur workflow, ces agents doivent pouvoir lire et modifier la configuration de compilation.

Cependant, ils n'ont aucun moyen de prédire les effets secondaires d'une modification de configuration, si ce n'est en compilant le projet.

L'ajout d'une seule ligne à un fichier de configuration peut entrer en conflit avec une variable calculée de manière dynamique ailleurs dans le projet ou avec un plug-in de convention.

Dans Lightbuild, la configuration de votre projet est un graphe de données statique déterministe.

Cela signifie que les agents peuvent inspecter ce graphique, comprendre la topologie du module et la modifier à l'aide d'un schéma connu.

Un agent peut voir la liste des modules, la liste des dépendances et leurs versions, mettre à jour les dépendances ou même ajouter un tout nouveau module de fonctionnalité simplement en lisant et en écrivant des données structurées.

Elle fait de la configuration de votre projet un élément de premier ordre pour les workflows assistés par un agent.

Je tiens également à souligner que Lightbuild n'est pas un plug-in pour un système de compilation, mais une interface pour le moteur de compilation.

La version de Lightbuild que nous publions aujourd'hui en preview utilise Gradle comme moteur d'exécution.

Cependant, l'approche architecturale que nous avons adoptée avec Lightbuild permet à Android Studio, l'IDE, de voir et de traiter le projet comme un projet Lightbuild.

Passons maintenant au deuxième pilier, qui concerne la productivité et le flux des développeurs : la synchronisation rapide de l'IDE.

Même si les développeurs adoptent des agents dans leur workflow, Android Studio reste un outil essentiel pour les tâches interactives, par exemple pour examiner les aperçus de l'UI Compose, parcourir le code dans le débogueur pour examiner un problème ou analyser les performances avec le profileur.

La configuration de votre projet étant un graphe de données statique déterministe, l'IDE n'a pas besoin de passer par une phase d'évaluation de script ni d'exécuter le code du plug-in pour comprendre votre projet.

Que vous ouvriez un projet, modifiiez un fichier de compilation ou changiez de branche, l'IDE peut traiter ces informations rapidement et vous donner directement accès à vos outils.

Cette rapidité et cette fiabilité sont notamment possibles grâce à la façon dont Lightbuild gère les dépendances.

Normalement, lorsque vous déclarez une dépendance, le système de compilation doit parcourir une arborescence de dépendances transitives pour collecter des informations sur la version et résoudre les conflits.

Dans Lightbuild, chaque fois que vos dépendances changent, l'outil calcule automatiquement les informations de dépendance transitive et les écrit dans un fichier resolved.deps dans chaque répertoire de module.

Ainsi, lorsque le projet est rouvert ou recompilé, ni l'IDE, ni l'outil de compilation n'ont besoin de recalculer ces informations de dépendance transitive.

Nous vous recommandons d'intégrer ces fichiers au contrôle de code source. Ainsi, lorsque vous envoyez des modifications à vos collègues pour examen, ils peuvent voir si des modifications ont été apportées aux informations de dépendance transitive, et leurs machines n'ont pas besoin de recalculer ces informations.

De plus, en intégrant ces informations au contrôle de code source, vous vous assurez que vous, vos coéquipiers et vos pipelines de CI/CD pouvez effectuer des compilations avec les mêmes versions de dépendances à chaque fois.

Nous sommes ravis d'annoncer que Lightbuild est disponible en preview anticipée dans Android Studio Canary et via des outils CLI autonomes.

Veuillez noter que cette version de Lightbuild est expérimentale. Elle ne dispose donc pas de toutes les fonctionnalités dont vous avez besoin pour créer et gérer une application de production.

Veuillez continuer à utiliser AGP et Gradle pour vos applications de production tout en essayant Lightbuild dans des projets de démonstration et expérimentaux.

Vous pouvez commencer dès aujourd'hui en accédant à goo.gle/lightbuild. Nous avons hâte de recevoir vos commentaires pour nous aider à façonner le produit au fil de son évolution.

Je vais maintenant laisser la parole à Scott, qui va vous montrer Lightbuild en action.

Merci, Juan.

Je m'appelle Scott Myers.

Je suis ingénieur Developer Relations Android. Nous travaillons sur Lightbuild depuis un certain temps et nous sommes ravis de vous montrer comment vous pouvez l'utiliser dès aujourd'hui.

La première chose à faire est donc d'accéder au lien mentionné par Juan, goo.gle/lightbuild, ou de rechercher "Lightbuild".

Vous devriez être redirigé vers cette page de documentation, qui contient toutes les étapes à suivre pour commencer, y compris l'installation d'une version Canary d'Android Studio. En effet, n'oubliez pas que cette fonctionnalité est encore en version preview et qu'elle n'est pas encore disponible dans la version stable d'Android Studio.

Vous pouvez également installer la CLI Lightbuild pour profiter pleinement de l'expérience agentique avec Lightbuild.

Une fois que vous l'avez configuré, comme je l'ai fait sur mon ordinateur, la dernière version d'Android Studio Canary est en cours d'exécution.

Je vais maintenant vous expliquer comment créer un projet Lightbuild de démonstration et vous montrer comment vous pouvez le faire, dès aujourd'hui.

Je vais d'abord accéder à l'assistant "New Project" (Nouveau projet).

Je vais choisir "Empty Activity" (Activité vide), puis cliquer sur "Next" (Suivant).

Vous voyez maintenant l'écran standard des détails du projet, mais une nouvelle option est disponible en bas.

Sous "Langage de configuration de compilation", vous pouvez choisir Lightbuild.

Il vous rappellera également qu'il s'agit d'une fonctionnalité expérimentale avant que vous ne cliquiez sur "Terminer".

Vous verrez que notre projet est immédiatement synchronisé avec l'IDE, et qu'il est prêt à être utilisé.

Examinons maintenant la structure d'un projet Lightbuild standard.

Il s'agit du modèle Android par défaut que vous obtenez lorsque vous créez une application.

Il indique simplement "Hello, world!".

C'est donc un moyen simple de commencer.

Vous verrez qu'au niveau racine de notre projet, nous avons un fichier appelé project.lightbuild.yaml.

Cela nous donne les paramètres globaux pour l'ensemble de notre projet.

Vous pouvez donc donner un nom à votre projet, lister tous les modules qu'il contient, indiquer les dépôts externes d'où vous extrayez vos dépendances, puis les versions qui sont appliquées globalement aux différentes parties de votre projet.

Nous voyons ici que nous avons deux modules : app et app-core.

En effet, tous les projets Lightbuild comportent au moins deux modules.

En effet, il doit comporter au moins un module d'application et au moins un module de bibliothèque.

Je vous expliquerai pourquoi dans un instant.

Commençons par examiner ce module d'application.

Si je le développe ici, vous pouvez voir qu'au niveau racine du module, il y a un fichier lightbuild.yaml, que chaque module va avoir.

Il contient des informations de base.

Nous travaillons sur la plate-forme Android, bien sûr.

Ce module est de type "application".

Vous pouvez lister les versions cibles de votre SDK, votre ID d'application, etc., puis lister tous les modules dont dépend ce module d'application.

Ce qui est intéressant avec ce module d'application, qui est un peu différent du modèle Android standard, c'est qu'il n'y a rien dans le dossier source.

Ainsi, dans Lightbuild, les modules d'application ne contiennent aucun code source.

En effet, ce module d'application ne changera pas très souvent, mais sa compilation prend un certain temps.

Si vous conservez tout le code de votre application dans vos modules de bibliothèque, chaque compilation sera plus rapide, car il ne sera pas nécessaire de tout recalculer et de tout reconditionner dans le module d'application.

Examinons maintenant le module app-core, qui est le module de bibliothèque dont dépend ce module d'application.

Comme vous pouvez le voir, ce module contient du code source.

Il contient notre logique principale.

Il indique simplement "Hello, world!".

Si je regarde le fichier lightbuild.yaml de ce module, vous pouvez voir qu'il est de type bibliothèque.

Ici, il définit également certains numéros de version du SDK, mais il liste toutes les dépendances externes que nous avons dans ce module.

Il déclare également nos tests unitaires et d'instrumentation.

Examinons maintenant un autre fichier que vous avez peut-être remarqué ici et dont Juan a un peu parlé : il y a un fichier resolved.deps dans chaque module.

Il s'agit d'un fichier généré automatiquement par Lightbuild.

Cela signifie que vous ne devez pas le modifier manuellement, mais qu'il contiendra une liste de toutes les dépendances résolues dans ce module.

Toutes vos dépendances et dépendances transitives sont donc déjà présentes.

Cela signifie que lorsque votre application est ouverte dans l'IDE ou lorsque vous effectuez un build, vous n'avez pas besoin de vous en soucier à ce moment-là, car cela a déjà été fait en amont et vérifié dans votre projet.

Voyons maintenant un exemple de la façon dont Lightbuild améliore l'expérience des développeurs avec la synchronisation des projets.

Je suis maintenant de retour dans mon fichier project.lightbuild.yaml au niveau racine, qui contient les paramètres globaux et liste tous les modules de mon application.

Normalement, lorsque vous modifiez des fichiers de configuration ou de configuration de compilation, vous remarquerez qu'un bouton de synchronisation s'affiche. Le traitement de tous ces fichiers prend un certain temps en raison des processus décrits par Juan, où il doit effectuer une compilation partielle en exécutant tous vos scripts de compilation, puis en synchronisant ce modèle avec l'IDE.

Apportons donc une modification assez importante à ce petit projet.

Nous allons simplement supprimer l'un des modules.

Vous pouvez voir que ce module, avant que je ne clique sur le bouton d'enregistrement, est reconnu par l'IDE, car il est en gras ici.

Il a reconnu le répertoire source et les répertoires de test.

Dès que j'enregistre après avoir effectué cette modification, vous pouvez voir que ce module disparaît instantanément du projet.

Si j'annule à nouveau cette modification et que j'enregistre, elle est rétablie tout aussi rapidement.

Voici un exemple de la synchronisation rapide de l'IDE que Lightbuild apporte à vos projets.

Vous pouvez également utiliser toutes les commandes habituelles d'Android Studio.

Vous pouvez cliquer sur le bouton d'exécution.

Il compilera votre application et l'exécutera ici.

Cette application de démonstration n'est pas très grande, mais je vais zoomer pour montrer qu'elle affiche "Hello Android".

Vous pouvez exécuter vos tests comme vous le feriez normalement en accédant à votre fichier de test et en l'exécutant depuis la marge, comme ceci.

En arrière-plan, il appelle Lightbuild pour exécuter ces tests.

Tout fonctionne donc comme prévu.

Mais je veux maintenant vous montrer comment utiliser Lightbuild si vous n'êtes pas dans Android Studio, si vous utilisez un autre flux d'agents.

Pour cela, nous avons la ligne de commande.

Dans la CLI pour Lightbuild, je vais donc simplement exécuter la commande d'aide de base.

Et oui, toutes les fautes de frappe que vous voyez dans ce projet aujourd'hui sont les miennes.

Lightbuild va donc intégrer plusieurs commandes différentes, comme… Oh, désolé, j'exécute cette commande en dehors d'un projet.

Il me dit toujours ça.

Oui, démonstration en direct.

Avant d'exécuter des commandes Lightbuild, je vais créer un projet Lightbuild.

Pour cela, je vais utiliser android create, notre outil de ligne de commande standard pour créer des modèles de projet.

Je vais utiliser le modèle empty-activity-lightbuild, nommer mon application "Lightbuild Demo" et la placer dans le répertoire de sortie de la démo.

Maintenant, si j'accède à ce répertoire et que je saisis "lightbuild -h", je vois toutes les commandes disponibles dans Lightbuild.

Nous avons donc beaucoup de choses auxquelles vous vous attendez : build, clean, test.

Mais il y en a quelques nouveaux.

La commande "resolve" parcourt les dépendances de votre projet et génère les fichiers resolved.deps que j'ai montrés précédemment.

La commande de requête vous permet, à vous et à vos agents, de mieux comprendre la structure de votre projet.

Tout d'abord, je vais vous montrer cette nouvelle commande de requête.

Si je regarde la structure de ce projet à l'aide de la ligne de commande, elle est identique à celle de la démo Android Studio.

Mais cela ne me dit pas grand-chose sur la façon dont mon projet est organisé.

Si j'exécute une requête Lightbuild et que je regarde, par exemple, ce module d'application, j'utiliserai cette syntaxe spéciale pour dire "Montre-moi tout ce qui se trouve sous ce module d'application".

et j'obtiens ce tableau des différentes cibles que je peux compiler dans le module d'application.

Il contient donc les APK et les AAB pour les binaires de débogage et de publication.

Si j'exécute simplement la cible de l'application, tout sera compilé.

Il est également possible de spécifier la sortie au format JSON.

Et de cette façon… Oh, désolé.

Encore une fois, toutes mes fautes de frappe sont réelles aujourd'hui.

Je vais utiliser l'aide interactive de Lightbuild pour m'assurer que je procède correctement.

Hein…

Oui, ça devrait fonctionner.

Très bien.

Si quelqu'un peut me dire ce que je fais de mal, qu'il vienne me voir après cette présentation.

Mais de toute façon, au lieu de ce tableau, vous pouvez également afficher vos commandes Lightbuild au format JSON, ce qui est plus facile pour vos agents.

--format json…

Oh, le format.

Oh, désolé.

Merci.

Il s'agit de commentaires de développeurs en direct.

Merci.

D'accord, oui, et il y a aussi cette commande de sortie que je peux également présenter, peut-être avec votre aide.

Si j'affiche les fichiers au lieu des cibles, je verrai l'emplacement de tous les binaires de mon build.

C'est donc un moyen pour vous et vos agents d'explorer et de mieux comprendre votre projet à partir de la ligne de commande à l'aide de Lightbuild.

Ensuite, il y a évidemment la commande lightbuild resolve que j'ai mentionnée plus tôt, qui générera tous vos fichiers resolved.deps.

Il comporte également des fonctionnalités supplémentaires.

Par exemple, il existe un paramètre de dépendances verrouillées. Ainsi, au lieu de simplement générer ces fichiers, il compare le contenu des fichiers aux dépendances que vous avez déclarées dans votre configuration de compilation.

S'il y a des différences, il vous en informera et la compilation échouera.

Ainsi, ces fichiers de dépendances résolues peuvent agir comme des fichiers de verrouillage. Par exemple, si vous créez votre application dans un système CI/CD pour la production, vous voudrez savoir si des dépendances changent pendant cette compilation.

Voyons aussi : Lightbuild dispose d'une fonctionnalité de test intégrée, et vous pouvez également exécuter tous les tests de ce module de bibliothèque, par exemple, directement depuis la ligne de commande.

Il y a encore une chose que je veux vous montrer.

Sachez simplement que l'aide est également disponible et qu'elle vous fournira une liste très complète de tous les paramètres et sous-commandes que vous pouvez utiliser.

qui est disponible pour votre agent. Voici donc le résultat pour l'agent.

Très bien.

Maintenant que nous avons vu quelques projets simples avec Lightbuild, je voudrais vous montrer à quoi ressemble un projet un peu plus ambitieux.

L'équipe Android propose une application exemple appelée Now in Android, qui vous présente certaines des dernières fonctionnalités Android, vous montre comment les utiliser et vous donne quelques bonnes pratiques.

Il s'agit d'une application hautement modulaire.

Il est divisé en 32 modules différents, je crois.

Voici à quoi cela ressemble dans GitHub.

Mais je vais revenir à Android Studio, où j'ai déjà utilisé mon agent.

J'utilisais Gemini Argon pour convertir le projet Now in Android en Lightbuild.

Nous n'avons pas publié ces résultats, je les ai juste obtenus de mon côté.

Comme vous pouvez le voir, même si ce projet dans mon project.lightbuild.yaml comporte tous ces différents modules, il s'est ouvert incroyablement vite et s'est synchronisé avec cet IDE très rapidement.

Vous remarquerez également que ce projet utilisait des types de compilation ou des configurations de compilation spéciales pour disposer à la fois d'une compilation de démonstration et d'une compilation de production, chacune présentant l'application d'une manière légèrement différente.

La version de démonstration utiliserait des sources de données intégrées, tandis que la version de production se connecterait au réseau pour extraire les données.

Pour ce faire, Lightbuild gère les différentes configurations de compilation ou types de produit en vous permettant d'accéder à votre module d'application et de spécifier qu'il s'agit, par exemple, de l'application de démonstration.

Il s'appuiera donc sur tous les composants principaux, mais il extraira également des paramètres spéciaux uniquement pour la version de démonstration de l'application.

Vous pouvez ainsi avoir plusieurs modules d'application.

Chacune peut représenter, par exemple, une version payante ou sans frais de votre application.

Vous bénéficiez toujours des avantages d'un module d'application vide, sans code, qui se compile beaucoup plus rapidement. De plus, lorsque vos bibliothèques changent, seules celles-ci doivent être recompilées pour créer à nouveau votre application.

Voyons maintenant si l'application Now in Android est bien compilée avec Lightbuild et ses 32 modules différents.

Oui, voilà.

Je tiens à souligner que d'autres enseignements tirés de ces tests ont montré que Lightbuild n'est pas toujours compatible avec toutes les fonctionnalités de compilation dont vous pourriez avoir besoin.

Par exemple, l'application Now in Android s'appuie sur un plug-in Hilt pour utiliser Hilt, et Lightbuild n'est pas encore compatible avec ce type de plug-in.

Mon agent a donc pu trouver une solution de contournement et intégrer la compatibilité avec Hilt sans vraiment modifier le code du projet.

Le code de tous ces modules est identique à celui du dépôt d'origine.

Mais c'est quelque chose à garder à l'esprit lorsque vous testez et faites des démonstrations de Lightbuild : tous les éléments de votre projet actuel ne seront pas compatibles en termes de configuration de compilation.

C'est pourquoi Lightbuild est toujours en version preview, dans Android Studio Canary.

Je vais maintenant revenir aux diapositives.

Pour résumer tout ce que nous avons vu, Lightbuild est une nouvelle plate-forme de compilation pour Android, actuellement en phase expérimentale.

Il dispose d'une configuration de compilation déclarative. Vous n'exécutez donc aucun code exécutable dans vos configurations de compilation, ce qui débloque de nombreuses fonctionnalités intéressantes, comme une synchronisation rapide de l'IDE et des compilations plus efficaces.

Il offre une compatibilité de premier ordre avec les agents IA, en ligne de commande, et toutes les fonctionnalités que vous m'avez aidé à présenter aujourd'hui.

Nous vous invitons donc à l'essayer et à l'utiliser pour des projets de démonstration et d'expérimentation.

Juan et moi, ainsi que certains ingénieurs de l'équipe, serons également présents sur le stand de l'IA agentive pour répondre à toutes vos questions.

Merci beaucoup.