Build Android dichiarative e pronte per gli agenti con Lightbuild

Ciao,

Mi chiamo Juan Sebastian Oviedo.

Sono un product manager del team Android Developer Experience.

Sono qui con Scott e oggi siamo felici di condividere con voi un'anteprima di Lightbuild, una nuova esperienza di build sperimentale per le app per Android.

Esaminerò il contesto di questo progetto, la filosofia alla base e il motivo per cui riteniamo che questo sia il momento giusto per ripensare alla configurazione dei progetti Android.

Inoltre, spiegherò in che modo questo nuovo approccio ci prepara per il futuro dello sviluppo di app per Android.

Iniziamo con un po' di contesto su come funzionano le cose oggi.

Gradle e gli script di build imperativi offrono agli sviluppatori la possibilità di definire in modo programmatico quasi tutto ciò che riguarda le loro build.

Ad esempio, puoi avere una logica che calcola dinamicamente i codici di versione in base alla cronologia Git o definire un'attività personalizzata che trasforma gli asset.

// 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"

    }

  }

}

Oltre a Gradle, esiste AGP o il plug-in Android per Gradle, che prende il motore per uso generico di Gradle e lo adatta alla toolchain Android.

Insieme, Gradle e AGP formano un sistema dinamico che supporta l'esperienza di configurazione di compilazione per milioni di app di produzione oggi.

A causa di questa flessibilità, i nostri strumenti per sviluppatori operano all'interno di un ciclo di vita dell'architettura specifico.

Quando apri un progetto, cambi branch o modifichi un file di build, l'IDE deve avere una mappa chiara, una comprensione chiara della configurazione del progetto, in modo da poter supportare funzionalità come il completamento del codice e la navigazione nel codice.

Poiché i file di build sono scritti in un linguaggio imperativo Turing-completo, l'unico modo generale per l'IDE di conoscere la configurazione è eseguire gli script di build.

Durante la sincronizzazione dell'IDE, il sistema di build passa attraverso una fase di configurazione.

Valuta gli script di build, esegue la logica dei plug-in e costruisce il modello del progetto.

In questo modo, la visualizzazione del progetto in Android Studio viene allineata alla configurazione effettiva del progetto.

In qualità di sviluppatori, ciò che vi interessa di più è offrire un'ottima app per Android e metterla a disposizione degli utenti.

Tuttavia, la gestione degli script di build, l'aggiornamento di AGP e la sincronizzazione del progetto con l'IDE richiedono tempo e impegno.

Sono in corso diverse iniziative sia in Google che nell'ecosistema più ampio per migliorare l'esperienza degli sviluppatori in questo ambito.

Iniziative come Declarative Gradle e la toolchain Kotlin mirano a sostituire gli script di build eseguibili con la configurazione di compilazione dichiarativa.

In Android Studio, abbiamo l'assistente per l'upgrade di AGP, che ti guida attraverso le modifiche necessarie per passare da una versione di AGP a un'altra.

Forniamo anche una skill di upgrade che gli agenti possono installare e seguire per eseguire l'upgrade di AGP.

Inoltre, stiamo investendo in aree come la sincronizzazione in fasi e la sincronizzazione resiliente, in modo che gli sviluppatori abbiano un'esperienza migliore durante la sincronizzazione e l'importazione dei loro progetti.

Ognuno di questi interventi mira a un pezzo del puzzle, in modo che gli sviluppatori possano dedicare più tempo alla creazione delle loro app e meno tempo alla creazione dei progetti, alla gestione dei file di build e alla sincronizzazione dei progetti.

Oltre a questi sforzi, ci siamo posti una domanda più ampia.

E se ripensassimo da zero il modo in cui vengono configurati i progetti?

Se osserviamo il modo in cui sono progettate le moderne app per Android, notiamo un importante cambiamento verso una forte modularizzazione.

Le codebase di grandi dimensioni spesso contengono decine o addirittura centinaia di moduli: moduli UI, moduli delle funzionalità, moduli di dominio e moduli di dati.

E mentre l'applicazione principale potrebbe occasionalmente richiedere un pacchetto personalizzato, la stragrande maggioranza di questi moduli di libreria segue un pattern ripetibile standardizzato.

Non è necessario che i file di build contengano codice eseguibile arbitrario.

Tutto ciò di cui hanno bisogno è un modo chiaro per dichiarare la loro struttura e le loro dipendenze.

Questa osservazione ci ha portato a creare Lightbuild.

Lightbuild si basa su due pilastri.

Innanzitutto, utilizza una sintassi dichiarativa per la configurazione, garantendo una chiara separazione tra la configurazione di compilazione e la logica.

In secondo luogo, offre un'esperienza di sincronizzazione dell'IDE rapida grazie alla risoluzione delle dipendenze in anticipo.

Esaminerò ciascuno di questi pilastri in dettaglio in modo che tu possa vedere come influiscono sul tuo flusso di lavoro quotidiano.

Iniziamo con il pilastro della configurazione di compilazione dichiarativa.

Dai un'occhiata al file sul lato sinistro dello schermo.

Rappresenta la configurazione di un modulo oggi.

// 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)
  ...

Poiché questo file è un codice eseguibile, può contenere definizioni di variabili locali, chiamate a funzioni helper personalizzate o plug-in di convenzione, istruzioni condizionali e definizioni di attività in linea.

Affinché l'IDE sappia a cosa si risolve questa configurazione, deve effettivamente eseguire lo script.

Ora dai un'occhiata al file sul lato destro dello schermo.

Questa è la configurazione Lightbuild per un modulo simile.

# 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

Questo file contiene dati puramente dichiarativi.

Non sono presenti definizioni di variabili locali, chiamate a funzioni helper personalizzate, istruzioni condizionali o definizioni di attività in linea.

Indica chiaramente il tipo di modulo, i suoi target SDK e le sue dipendenze.

Se un nuovo ingegnere si unisce al tuo team e apre questo file, non dovrà decifrare idiomi di build personalizzati e ogni modulo Lightbuild in ogni progetto Lightbuild utilizzerà lo stesso linguaggio immediatamente leggibile.

Sebbene la separazione tra configurazione e logica sia ottima per la leggibilità umana, è ancora più trasformativa per i workflow di Agent Assist.

Man mano che gli sviluppatori adottano gli agenti come parte del loro workflow, questi devono essere in grado di leggere e modificare la configurazione di compilazione.

Tuttavia, non hanno un modo per prevedere gli effetti collaterali di una modifica della configurazione se non creando effettivamente il progetto.

L'aggiunta di una singola riga a un file di configurazione potrebbe entrare in conflitto con una variabile calcolata dinamicamente in un'altra parte del progetto o con un plug-in di convenzione.

In Lightbuild, la configurazione del progetto è un grafico di dati statico e deterministico.

Ciò significa che gli agenti possono ispezionare il grafico, comprendere la topologia del modulo e modificarla utilizzando uno schema noto.

Un agente può visualizzare l'elenco dei moduli, l'elenco delle dipendenze e le relative versioni, aggiornare le dipendenze o persino aggiungere un modulo della funzionalità completamente nuovo semplicemente leggendo e scrivendo dati strutturati.

Rende la configurazione del progetto un elemento di primo piano per i workflow assistiti dagli agenti.

Un altro dettaglio che voglio sottolineare a questo punto è il fatto che Lightbuild non è un plug-in di un sistema di build, ma un'interfaccia per il motore di build.

La versione di Lightbuild, l'anteprima che rilasciamo oggi, utilizza Gradle come motore di esecuzione.

Tuttavia, l'approccio architetturale che abbiamo seguito con Lightbuild fa sì che Android Studio, l'IDE, veda e tratti il progetto come un progetto Lightbuild.

Ora passiamo al secondo pilastro, che riguarda la produttività e il flusso degli sviluppatori: la sincronizzazione rapida dell'IDE.

Anche se gli sviluppatori adottano gli agenti come parte del loro flusso di lavoro, Android Studio rimane uno strumento essenziale per le attività interattive, ad esempio per esaminare le anteprime della UI di Compose o per eseguire il codice nel debugger nell'ambito dell'analisi di un problema o per analizzare le prestazioni con il profiler.

Poiché la configurazione del progetto è un grafico di dati statico deterministico, l'IDE non deve passare attraverso una fase di valutazione dello script o eseguire il codice del plug-in per comprendere il progetto.

Che tu apra un progetto, modifichi un file di build o cambi branch, l'IDE può elaborare rapidamente queste informazioni e portarti direttamente ai tuoi strumenti.

Uno dei motivi per cui questa velocità e questa affidabilità sono possibili è il modo in cui Lightbuild gestisce le dipendenze.

Normalmente, quando dichiari una dipendenza, il sistema di build deve esaminare un albero di dipendenze transitive per raccogliere informazioni sulla versione e risolvere i conflitti.

In Lightbuild, ogni volta che le dipendenze cambiano, lo strumento calcola automaticamente le informazioni sulle dipendenze transitive e le scrive in un file resolved.deps all'interno di ogni directory del modulo.

In questo modo, quando il progetto viene riaperto in futuro o viene ricreato, né l'IDE né lo strumento di build devono ricalcolare le informazioni sulla dipendenza transitiva.

Ti consigliamo di archiviare questi file nel controllo del codice sorgente in modo che, quando invii le modifiche ai tuoi colleghi per la revisione, possano vedere se sono state apportate modifiche alle informazioni sulle dipendenze transitive e, inoltre, i loro computer non dovranno ricalcolare queste informazioni.

Inoltre, inserendo queste informazioni nel controllo del codice sorgente, tu, i tuoi colleghi e le tue pipeline CI/CD potete eseguire la build con le stesse versioni delle dipendenze ogni volta.

Siamo entusiasti di annunciare che Lightbuild è disponibile in anteprima in Android Studio Canary e anche tramite strumenti CLI autonomi.

Tieni presente che questa versione di Lightbuild è sperimentale, quindi non dispone di tutte le funzionalità necessarie per creare e gestire un'applicazione di produzione.

Continua a utilizzare AGP e Gradle per le tue applicazioni di produzione mentre provi Lightbuild in progetti demo e sperimentali.

Puoi iniziare oggi stesso visitando la pagina goo.gle/lightbuild. Non vediamo l'ora di ricevere il tuo feedback per aiutarci a dare forma al prodotto man mano che si evolve.

Ora passo la parola a Scott, che vi mostrerà Lightbuild in azione.

Grazie, Juan.

Mi chiamo Scott Myers.

Sono un Android Developer Relations Engineer. Lavoriamo a Lightbuild da un po' di tempo e siamo entusiasti di mostrarvi come potete provarlo e utilizzarlo oggi stesso.

Quindi, la prima cosa da fare è andare al link menzionato da Juan, goo.gle/lightbuild, o semplicemente cercare Lightbuild.

Dovresti visualizzare questa pagina della documentazione con tutti i passaggi necessari per iniziare, inclusa l'installazione di una versione Canary di Android Studio, perché ricorda che questa funzionalità è ancora in anteprima e non è ancora disponibile nella versione stabile di Android Studio.

Inoltre, puoi installare un'interfaccia a riga di comando di Lightbuild per sfruttare tutti i vantaggi dell'esperienza agentica con Lightbuild.

Una volta completata la configurazione, come ho fatto io qui sulla mia macchina, ho l'ultima versione di Android Studio Canary in esecuzione.

Ora ti mostrerò come creare un progetto Lightbuild dimostrativo e come puoi farlo anche oggi stesso.

Per prima cosa, vado alla procedura guidata Nuovo progetto.

Sceglierò l'attività vuota e farò clic su Avanti.

Ora vedrai che questa è la normale schermata dei dettagli del progetto, ma in basso è presente una nuova opzione.

In Linguaggio di configurazione di compilazione, puoi scegliere Lightbuild.

Inoltre, ti ricorderà che si tratta di una funzionalità sperimentale prima di fare clic su Fine.

Vedrai che il nostro progetto viene sincronizzato immediatamente con l'IDE ed è pronto per essere utilizzato.

Ora diamo un'occhiata alla struttura di un tipico progetto Lightbuild.

Questo è solo il modello Android predefinito che ottieni quando crei una nuova applicazione.

Dice solo "Hello, world!"

È un modo semplice per iniziare.

Vedrai che a livello di root del nostro progetto qui abbiamo un file chiamato project.lightbuild.yaml.

In questo modo, otteniamo le impostazioni globali per l'intero progetto.

Puoi quindi assegnare un nome al progetto, elencare tutti i moduli del progetto, indicare i repository esterni da cui estrarre le dipendenze e infine le versioni applicate a livello globale alle diverse parti del progetto.

Come vedi, qui abbiamo due moduli: app e app-core.

Questo perché tutti i progetti Lightbuild hanno almeno due moduli.

Questo perché è necessario avere almeno un modulo dell'app e almeno un modulo della libreria.

Tra un attimo spiegherò il motivo.

Per prima cosa, diamo un'occhiata a questo modulo dell'app.

Se lo espando qui, puoi vedere che al livello principale del modulo è presente un file lightbuild.yaml, che ogni modulo avrà.

Qui sono riportate alcune informazioni di base.

Stiamo lavorando sulla piattaforma Android, ovviamente.

Questo modulo è di tipo applicazione.

Puoi elencare le versioni target dell'SDK, l'ID applicazione e così via, quindi elencare tutti i moduli da cui dipende questo modulo dell'applicazione.

La particolarità di questo modulo dell'applicazione, che lo differenzia dal modello Android standard, è che la cartella di origine è vuota.

Pertanto, in Lightbuild, i moduli dell'applicazione non contengono codice sorgente.

Questo perché il modulo dell'app non cambierà molto spesso, ma richiede un po' di tempo per la creazione.

Quindi, se mantieni tutto il codice dell'applicazione all'interno dei moduli della libreria, ogni build verrà eseguita più velocemente perché non dovrà ricalcolare e ricompilare tutto nel modulo dell'app.

Ora diamo un'occhiata al modulo app-core, ovvero il modulo della libreria da cui dipende questo modulo dell'applicazione.

Come puoi vedere, questo modulo contiene effettivamente del codice sorgente.

Contiene la nostra logica principale.

Dice solo "Hello, world!"

Se do un'occhiata al file lightbuild.yaml in questo modulo, puoi vedere che è di tipo libreria.

Qui vengono anche impostati alcuni numeri di versione dell'SDK, ma vengono elencate tutte le dipendenze esterne che abbiamo all'interno di questo modulo.

Inoltre, dichiara i nostri test di unità e di instrumentazione.

Ora diamo un'occhiata a un altro file che potresti aver notato qui, di cui Juan ha parlato un po': c'è un file resolved.deps all'interno di ogni modulo.

Questo file viene generato automaticamente da Lightbuild.

Ciò significa che non devi modificarlo manualmente, ma conterrà un elenco di tutte le dipendenze risolte all'interno di questo modulo.

Quindi, tutte le tue dipendenze e dipendenze transitive sono già qui.

Ciò significa che quando l'applicazione viene aperta nell'IDE o quando crei una build, non devi preoccuparti di questo aspetto, perché è già stato risolto in anticipo e controllato nel progetto.

Ora diamo un'occhiata a un esempio di come Lightbuild migliora effettivamente l'esperienza degli sviluppatori con la sincronizzazione dei progetti.

Ora sono tornato al livello principale project.lightbuild.yaml, alle impostazioni globali che elencano tutti i moduli della mia applicazione.

In genere, quando modifichi i file di configurazione o di configurazione di compilazione, noterai che viene visualizzato un pulsante di sincronizzazione che richiede un po' di tempo per elaborare tutti i file a causa dei processi descritti da Juan, in cui deve eseguire una compilazione parziale eseguendo tutti gli script di compilazione e poi sincronizzando il modello con l'IDE.

Quindi, apportiamo una modifica piuttosto importante a questo piccolo progetto.

Elimineremo uno dei moduli.

E puoi vedere che questo modulo, prima di premere il pulsante Salva, viene riconosciuto dall'IDE perché puoi vedere che è in grassetto qui.

Ha riconosciuto la directory di origine e le directory di test.

Non appena ho salvato, dopo aver apportato la modifica, puoi vedere che questo modulo è scomparso immediatamente dal progetto.

Se annullo di nuovo la modifica e salvo, il testo torna come prima altrettanto rapidamente.

Questo è un esempio della sincronizzazione rapida dell'IDE che Lightbuild offre ai tuoi progetti.

Inoltre, puoi eseguire tutti i normali comandi che utilizzi abitualmente in Android Studio.

Puoi premere il pulsante Esegui.

La tua app verrà compilata ed eseguita qui.

Questa particolare app demo non è molto grande, ma aumenterò lo zoom per mostrare che dice "Hello Android".

Puoi eseguire i test come faresti normalmente andando nel file di test ed eseguendolo dal margine, in questo modo.

In realtà, dietro le quinte viene richiamato Lightbuild per eseguire questi test.

Quindi, tutto funziona come previsto.

Ora voglio mostrare come utilizzare Lightbuild se non sei in Android Studio, se utilizzi un altro flusso agentico.

Per questo, abbiamo la riga di comando.

Quindi, nell'interfaccia a riga di comando di Lightbuild, eseguirò il comando di base per la guida.

E sì, tutti i refusi che vedi oggi in questo progetto sono miei.

Lightbuild avrà diversi comandi integrati, ad esempio Oh, scusa, sto eseguendo questo comando al di fuori di un progetto.

Continua a dirmelo.

Sì, demo dal vivo.

Quindi, prima di eseguire qualsiasi comando Lightbuild, creo un progetto Lightbuild.

Per farlo, utilizzerò android create, che è il nostro strumento a riga di comando standard per la creazione di nuovi modelli di progetto.

Utilizzerò il modello empty-activity-lightbuild, assegnerò all'app il nome Lightbuild Demo e la inserirò nella directory di output della demo.

Ora, se accedo alla directory e digito lightbuild -h, vedrò tutti i diversi comandi disponibili per Lightbuild.

Abbiamo quindi molte cose che ti aspetteresti: build, clean, test.

Ma ce ne sono alcune nuove.

C'è un comando di risoluzione, che esegue effettivamente le dipendenze del progetto e genera i file resolved.deps che ho mostrato in precedenza.

Inoltre, è disponibile un comando di query che consente a te e ai tuoi agenti di comprendere meglio la struttura del progetto.

Per prima cosa, perché non mostro il nuovo comando di query?

Quindi, se guardo la struttura di questo progetto utilizzando la riga di comando, è la stessa che avevo nella demo di Android Studio.

Ma questo non mi dice molto su come è strutturato il mio progetto.

Quindi, se eseguo una query Lightbuild e do un'occhiata, ad esempio, a questo modulo dell'app, utilizzerò questa sintassi speciale per dire: "Mostrami tutto ciò che si trova in questo modulo dell'app".

Inoltre, mi fornisce questa bella tabella di diversi target che posso creare all'interno del modulo dell'app.

Pertanto, contiene gli APK e gli AAB per i file binari di debug e di release.

Se eseguo solo la destinazione dell'app, verrà creato tutto.

Inoltre, è possibile specificare l'output in formato JSON.

In questo modo… Oh, scusa.

Anche in questo caso, tutti i miei errori di battitura sono reali oggi.

Utilizzo la guida interattiva di Lightbuild per assicurarmi di eseguire l'operazione correttamente.

Uh…

Sì, dovrebbe funzionare.

Okay.

Beh, se qualcuno può dirmi cosa sto sbagliando, parliamone dopo questo intervento.

In ogni caso, anziché questa tabella, puoi anche generare i comandi Lightbuild come JSON, il che è più semplice per i tuoi agenti.

--format json…

Oh, format.

Oh, scusa.

Grazie.

Questo è un feedback in tempo reale degli sviluppatori.

Grazie.

Ok, sì, e c'è anche il comando di output che posso mostrare, magari con il tuo aiuto.

Quindi, se genero i file anziché i target, verranno visualizzate le posizioni di tutti i diversi binari all'interno della mia build.

In questo modo, tu e i tuoi agenti potete esplorare e comprendere meglio il progetto dalla riga di comando utilizzando Lightbuild.

Poi, ovviamente, c'è il comando lightbuild resolve che ho menzionato prima, che genererà tutti i file resolved.deps.

Anche questo ha alcune funzionalità aggiuntive.

Ad esempio, esiste questo parametro delle dipendenze bloccate e, con questo, invece di generare semplicemente questi file, confronterà i contenuti dei file con le dipendenze dichiarate nella configurazione di build.

Se ci sono differenze, ti avviserà e la build non andrà a buon fine.

In questo modo, questi file delle dipendenze risolte possono fungere da file di blocco, ad esempio se stai creando la tua app in un sistema CI/CD per la produzione, ti consigliamo di sapere se le dipendenze cambiano durante la build.

Inoltre, Lightbuild ha una funzionalità di test integrata e puoi anche eseguire tutti i test in questo modulo della libreria, ad esempio direttamente dalla riga di comando.

C'è un'altra cosa che voglio mostrare.

Inoltre, è disponibile la guida che ti fornirà un elenco molto completo di tutti i parametri e i sottocomandi che puoi utilizzare.

che è disponibile per l'agente, quindi questo è l'output per l'agente.

Okay.

Ora che abbiamo visto alcuni progetti semplici con Lightbuild, voglio mostrare un progetto un po' più ambizioso.

Abbiamo un'app di esempio resa disponibile dal team di Android, chiamata Now in Android, che offre alcune delle funzionalità più recenti di Android, mostra come utilizzarle e presenta alcune best practice.

È un'applicazione altamente modulare.

È suddiviso in circa 32 moduli diversi.

Ecco come appare in GitHub.

Ma tornerò ad Android Studio, dove ho già utilizzato il mio agente in anticipo.

Stavo usando Gemini Argon per convertire il progetto Now in Android in Lightbuild.

Quindi, non si tratta di qualcosa che abbiamo pubblicato, ma di qualcosa che ho fatto per conto mio.

E puoi vedere che, anche se questo progetto nel mio project.lightbuild.yaml ha tutti questi moduli diversi, si è comunque aperto in modo incredibilmente rapido e si è sincronizzato con questo IDE in modo molto veloce.

Un'altra cosa che noterai di questo particolare progetto è che utilizzava alcuni build flavor o configurazioni di build speciali per avere sia una build demo che una build di produzione, ognuna delle quali aveva un modo leggermente diverso di presentare l'app.

La versione demo utilizzerebbe origini dati integrate, mentre la versione di produzione si connette alla rete e recupera i dati.

Per farlo con Lightbuild, il modo in cui gestisce elementi come diverse configurazioni di compilazione o versioni prodotto è che vai nel modulo dell'applicazione e specifichi che questo modulo dell'applicazione è, ad esempio, l'applicazione demo.

Pertanto, si baserà su tutti i componenti principali, ma estrarrà anche impostazioni speciali solo per la versione demo dell'app.

In questo modo, puoi avere più moduli dell'applicazione.

Ognuno può rappresentare, ad esempio, una versione a pagamento o senza costi della tua app.

Inoltre, puoi comunque usufruire dei vantaggi del modulo dell'applicazione, che è un contenitore vuoto senza codice, che viene creato molto più velocemente e, ogni volta che le librerie cambiano, solo queste devono essere ricompilate per creare nuovamente l'app.

Diamo un'occhiata per vedere se questa app per Android Now in Android viene creata correttamente con Lightbuild con tutti i suoi 32 moduli diversi.

Sì, eccolo.

Voglio sottolineare che un'altra cosa che abbiamo imparato da esperimenti come questo è che Lightbuild non supporta sempre tutte le funzionalità di build di cui potresti avere bisogno.

Ad esempio, l'app per Android Now in Android si basa su un plug-in Hilt per utilizzare Hilt e Lightbuild non supporta ancora questo tipo di funzionalità.

Quindi, il mio agente è riuscito a trovare una soluzione alternativa e a ottenere il supporto di Hilt senza modificare molto il codice del progetto stesso.

Ad esempio, tutto il codice di tutti questi moduli è lo stesso del repository originale.

Ma è qualcosa da tenere assolutamente presente quando sperimenti e provi Lightbuild in prima persona: non tutto nel tuo progetto attuale sarà supportato in termini di configurazione di compilazione.

Ecco perché Lightbuild è ancora in anteprima, ancora in Android Studio Canary.

A questo punto, vorrei tornare alle slide.

E sì, per riassumere tutto ciò di cui abbiamo parlato qui, ricorda che Lightbuild è una nuova piattaforma di build per Android, attualmente sperimentale.

Ha una configurazione di compilazione dichiarativa, quindi non esegui alcun codice eseguibile nelle configurazioni di compilazione e questo sblocca molte funzionalità interessanti con una sincronizzazione rapida dell'IDE e build più efficienti.

Offre un supporto di prim'ordine per gli agenti AI, alla riga di comando, ha tutte le funzionalità che mi hai aiutato a mostrare oggi.

Ti invitiamo quindi a provarlo e a utilizzarlo per progetti sperimentali e dimostrativi.

Inoltre, io, Juan e alcuni ingegneri del team saremo allo stand dell'AI agentica per rispondere a qualsiasi domanda.

Quindi, grazie mille.