Compilaciones de Android declarativas y listas para agentes con Lightbuild

Hola a todos.

Mi nombre es Juan Sebastián Oviedo.

Soy gerente de producto en el equipo de Experiencia de desarrolladores de Android.

Estoy aquí con Scott y hoy nos complace compartir con ustedes un adelanto de Lightbuild, una nueva experiencia experimental de compilación para apps para Android.

Repasaré el contexto de este proyecto, la filosofía detrás de él y por qué creemos que ahora es el momento adecuado para repensar cómo se configuran los proyectos de Android.

También explicaré cómo este nuevo enfoque nos prepara para el futuro del desarrollo de apps para Android.

Comencemos con un poco de contexto sobre cómo funcionan las cosas hoy en día.

Gradle y las secuencias de comandos de compilación imperativas les brindan a los desarrolladores la capacidad de definir de manera programática casi cualquier aspecto de sus compilaciones.

Por ejemplo, puedes tener una lógica que calcule de forma dinámica los códigos de versión según el historial de Git o definir una tarea personalizada que transforme los recursos.

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

    }

  }

}

Junto con Gradle, está el AGP o complemento de Android para Gradle, que toma el motor de uso general de Gradle y lo adapta a la cadena de herramientas de Android.

Juntos, Gradle y el AGP forman un sistema dinámico que potencia la experiencia de configuración de compilación para millones de apps de producción en la actualidad.

Debido a esta flexibilidad, nuestras herramientas para desarrolladores operan dentro de un ciclo de vida de arquitectura específico.

Cuando abres un proyecto, cambias de rama o editas un archivo de compilación, el IDE necesita tener un mapa claro, una comprensión clara de la configuración de tu proyecto, para poder potenciar funciones como la finalización de código y la navegación por el código.

Debido a que los archivos de compilación se escriben en un lenguaje imperativo y completo de Turing, la única forma general de que el IDE sepa cuál es la configuración es que ejecute las secuencias de comandos de compilación.

Durante la sincronización del IDE, el sistema de compilación pasa por una fase de configuración.

Evalúa tus secuencias de comandos de compilación, ejecuta la lógica de los complementos y construye el modelo del proyecto.

Esto alinea la vista de Android Studio de tu proyecto con la configuración real del proyecto.

Como desarrolladores, lo que más les importa es ofrecer una excelente app para Android y hacer que llegue a los usuarios.

Sin embargo, administrar las secuencias de comandos de compilación, mantener actualizado el AGP y mantener el proyecto sincronizado con el IDE requiere tiempo y esfuerzo.

Existen varias iniciativas en Google y en el ecosistema más amplio que buscan mejorar la experiencia de los desarrolladores en esta área.

Las iniciativas como Declarative Gradle y la cadena de herramientas de Kotlin tienen como objetivo reemplazar las secuencias de comandos de compilación ejecutables por una configuración de compilación declarativa.

En Android Studio, tenemos el Asistente de actualización del AGP, que te guía por los cambios necesarios para pasar de una versión del AGP a otra.

También proporcionamos una habilidad de actualización que los agentes pueden instalar y seguir para actualizar el AGP.

Además, estamos invirtiendo en áreas como la sincronización por fases y la sincronización resiliente, para que los desarrolladores tengan una mejor experiencia cuando sincronicen e importen sus proyectos.

Cada uno de estos esfuerzos se enfoca en una pieza del rompecabezas para que los desarrolladores puedan dedicar más tiempo a crear sus apps y menos a compilar sus proyectos, administrar sus archivos de compilación y sincronizar sus proyectos.

Junto con estos esfuerzos, nos hicimos una pregunta más amplia.

¿Qué pasaría si reinventáramos la forma en que se configuran los proyectos desde cero?

Cuando observamos la forma en que se diseñan las apps para Android modernas, vemos un cambio importante hacia una modularización intensa.

Las bases de código grandes suelen tener decenas o incluso cientos de módulos: módulos de IU, de funciones, de dominio y de datos.

Y, si bien la aplicación raíz puede necesitar un empaquetado personalizado de vez en cuando, la gran mayoría de esos módulos de biblioteca siguen un patrón repetible estandarizado.

En realidad, no necesitan tener código ejecutable arbitrario en sus archivos de compilación.

Solo necesitan una forma clara de indicar su estructura y sus dependencias.

Esa observación nos llevó a crear Lightbuild.

Lightbuild se basa en dos pilares.

En primer lugar, usa una sintaxis declarativa para la configuración, lo que proporciona una separación clara entre la configuración de compilación y la lógica.

En segundo lugar, ofrece una experiencia de sincronización rápida del IDE a través de la resolución de dependencias anticipada.

Analizaré cada uno de estos pilares en detalle para que puedas ver cómo afectan tu flujo de trabajo diario.

Comencemos con el pilar de la configuración de compilación declarativa.

Observa el archivo que se encuentra en el lado izquierdo de la pantalla.

Esto representa la configuración de un módulo en la actualidad.

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

Como este archivo es código ejecutable, puede tener definiciones de variables locales, llamadas a funciones auxiliares personalizadas o complementos de convenciones, declaraciones condicionales y definiciones de tareas intercaladas.

Para que el IDE sepa qué resuelve esta configuración, debe ejecutar la secuencia de comandos.

Ahora, observa el archivo que se encuentra en el lado derecho de la pantalla.

Esta es la configuración de Lightbuild para un módulo similar.

# 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

Este archivo contiene datos puramente declarativos.

No hay definiciones de variables locales, llamadas a funciones auxiliares personalizadas, declaraciones condicionales ni definiciones de tareas intercaladas.

Indica claramente el tipo de módulo, sus destinos de SDK y sus dependencias.

Si un ingeniero nuevo se une a tu equipo y abre este archivo, no tendrá que descifrar expresiones de compilación personalizadas, y cada módulo de Lightbuild en cada proyecto de Lightbuild usará el mismo lenguaje legible de inmediato.

Si bien la separación entre la configuración y la lógica es excelente para la legibilidad humana, es aún más transformadora para los flujos de trabajo de Agent Assist.

A medida que los desarrolladores adoptan agentes como parte de su flujo de trabajo, esos agentes deben poder leer y modificar la configuración de compilación.

Sin embargo, no tienen forma de predecir los efectos secundarios de un cambio de configuración, excepto si compilan el proyecto.

Agregar una sola línea a un archivo de configuración podría generar un conflicto con una variable calculada de forma dinámica en otra parte del proyecto o con un complemento de convención.

En Lightbuild, la configuración de tu proyecto es un grafo de datos estático y determinista.

Esto significa que los agentes pueden inspeccionar ese gráfico, comprender la topología del módulo y modificarla con un esquema conocido.

Un agente puede ver la lista de módulos, la lista de dependencias y sus versiones, actualizar dependencias o incluso agregar un módulo de funciones completamente nuevo con solo leer y escribir datos estructurados.

Hace que la configuración de tu proyecto sea un elemento de primera clase para los flujos de trabajo asistidos por agentes.

Otro detalle que quiero destacar en este punto es que Lightbuild no es un complemento de un sistema de compilación, sino una interfaz para el motor de compilación.

La versión de Lightbuild, la versión preliminar que lanzamos hoy, usa Gradle de forma interna como su motor de ejecución.

Sin embargo, el enfoque de arquitectura que seguimos con Lightbuild hace que Android Studio, el IDE, vea y trate el proyecto como un proyecto de Lightbuild.

Ahora, analicemos el segundo pilar, que se centra en la productividad y el flujo de los desarrolladores: la sincronización rápida del IDE.

Incluso cuando los desarrolladores adoptan agentes como parte de su flujo de trabajo, Android Studio sigue siendo una herramienta esencial para las tareas interactivas, por ejemplo, para revisar las vistas previas de la IU de Compose o para recorrer el código en el depurador como parte de la investigación de un problema, o bien para analizar un rendimiento con el generador de perfiles.

Como la configuración de tu proyecto es un grafo de datos estático y determinista, el IDE no necesita pasar por una fase de evaluación de secuencias de comandos ni ejecutar código de complemento para comprender tu proyecto.

Ya sea que abras un proyecto, edites un archivo de compilación o cambies de rama, el IDE puede procesar esa información rápidamente y llevarte directamente a tus herramientas.

Uno de los motivos por los que esta velocidad y confiabilidad son posibles es la forma en que Lightbuild maneja las dependencias.

Normalmente, cuando declaras una dependencia, el sistema de compilación debe recorrer un árbol de dependencias transitivas para recopilar información de la versión y resolver conflictos.

En Lightbuild, cada vez que cambian tus dependencias, la herramienta calcula automáticamente la información de las dependencias transitivas y la escribe en un archivo resolved.deps dentro del directorio de cada módulo.

Esto hace que, cuando se vuelva a abrir el proyecto en el futuro o se vuelva a compilar, ni el IDE ni la herramienta de compilación necesiten volver a calcular esa información de dependencia transitiva.

Te recomendamos que verifiques estos archivos en el control de código fuente para que, cuando envíes cambios a tus compañeros de equipo para que los revisen, puedan ver si hubo cambios en la información de dependencia transitiva y, además, sus máquinas no necesiten volver a calcular esa información de dependencia transitiva.

Además, si registras esta información en el control de código fuente, tú, tus compañeros de equipo y tus canalizaciones de CI/CD podrán compilar con las mismas versiones de dependencias cada vez.

Nos complace anunciar que Lightbuild está disponible como versión preliminar anticipada en Android Studio Canary y también a través de herramientas de CLI independientes.

Ten en cuenta que esta versión de Lightbuild es experimental, por lo que no tiene todas las funciones que necesitas para compilar y mantener una aplicación de producción.

Sigue usando AGP y Gradle para tus aplicaciones de producción mientras pruebas Lightbuild en proyectos experimentales y de demostración.

Puedes comenzar hoy mismo en goo.gle/lightbuild. Esperamos recibir tus comentarios para que nos ayudes a definir el producto a medida que evoluciona.

Ahora, le pasaré la presentación a Scott para que les muestre Lightbuild en acción.

Gracias, Juan.

Me llamo Scott Myers.

Soy ingeniero de relaciones con desarrolladores de Android. Estuvimos trabajando en Lightbuild durante un tiempo y nos complace mostrarte cómo puedes usarlo y probarlo hoy mismo.

Por lo tanto, lo primero que debes hacer es ir al vínculo que mencionó Juan, goo.gle/lightbuild, o simplemente buscar Lightbuild.

Y debería llevarte a esta página de documentación que tendrá todos los pasos que necesitas para comenzar, incluida la instalación de una versión Canary de Android Studio, porque recuerda que esto todavía está en versión preliminar, aún no está en la versión estable de Android Studio.

Además, hay una CLI de Lightbuild que puedes instalar para obtener todos los beneficios de la experiencia de agentes con Lightbuild.

Una vez que lo configures, como hice yo en mi máquina, tendrás la versión más reciente de Android Studio Canary en ejecución.

Ahora, voy a crear un proyecto de demostración de Lightbuild y te mostraré cómo puedes hacerlo hoy mismo.

Primero, iré al asistente de New Project.

Elegiré Empty Activity y haré clic en Next.

Ahora verás que esta es la pantalla normal de detalles del proyecto, pero en la parte inferior, hay una opción nueva.

En el lenguaje de configuración de compilación, puedes elegir Lightbuild.

Y te recordará que se trata de una función experimental antes de que presiones Finalizar.

Verás que, de inmediato, nuestro proyecto se sincroniza con el IDE y se ejecuta, listo para que trabajemos con él.

Ahora, veamos la estructura de un proyecto típico de Lightbuild.

Esta es la plantilla predeterminada de Android que obtienes cuando creas una aplicación nueva.

Solo dice "Hello, world!".

Por lo tanto, es una forma sencilla de comenzar.

Verás que, en el nivel raíz de nuestro proyecto, tenemos un archivo llamado project.lightbuild.yaml.

Esto nos brinda la configuración global para todo nuestro proyecto.

Por lo tanto, puedes asignarle un nombre a tu proyecto, enumerar todos los módulos que contiene, indicar de qué repositorios externos extraes las dependencias y, luego, las versiones que se aplican de forma global a las diferentes partes del proyecto aquí.

Vemos que tenemos dos módulos aquí: app y app-core.

Esto se debe a que todos los proyectos de Lightbuild tienen, al menos, dos módulos.

Esto se debe a que se requiere tener al menos un módulo de app y al menos un módulo de biblioteca.

En un momento, explicaré por qué.

Primero, veamos este módulo de la app.

Si lo expando aquí, verás que, en el nivel raíz del módulo, hay un archivo lightbuild.yaml, que tendrán todos los módulos.

Aquí, tiene información básica.

Obviamente, estamos trabajando en la plataforma de Android.

Y este módulo es de tipo aplicación.

Puedes enumerar las versiones de destino del SDK, el ID de aplicación, etcétera, y, luego, todos los módulos de los que depende este módulo de aplicación.

Ahora, lo interesante de este módulo de aplicación, que es un poco diferente de la plantilla estándar de Android, es que no hay nada en la carpeta de origen.

Por lo tanto, en Lightbuild, los módulos de aplicación no contienen ningún código fuente.

Esto se debe a que este módulo de la app no cambiará con mucha frecuencia, pero lleva un tiempo compilarlo.

Por lo tanto, si mantienes todo el código de la aplicación dentro de los módulos de biblioteca, cada compilación se realizará más rápido, ya que no tendrá que volver a calcular ni empaquetar todo en el módulo de la app.

A continuación, veamos el módulo app-core, que es el módulo de biblioteca del que depende este módulo de aplicación.

Y puedes ver que este módulo tiene código fuente.

Aquí tiene nuestra lógica principal.

Solo dice "Hello, world!".

Si observo el archivo lightbuild.yaml de este módulo, puedo ver que es de tipo biblioteca.

Y aquí también se configuran algunos números de versión del SDK, pero se enumeran todas las dependencias externas que tenemos dentro de este módulo.

También declara nuestras pruebas de unidades y de instrumentación.

A continuación, veamos otro archivo que tal vez hayas notado aquí, y Juan habló un poco sobre esto, hay un archivo resolved.deps dentro de cada módulo.

Este es un archivo que Lightbuild genera automáticamente.

Esto significa que no debes editarlo de forma manual, pero contendrá una lista de todas las dependencias resueltas dentro de este módulo.

Por lo tanto, todas tus dependencias y dependencias transitivas ya están aquí.

Esto significa que, cuando se abre la aplicación en el IDE o cuando vas a realizar una compilación, no tienes que resolver esto en ese momento, ya que se resolvió con anticipación y se verificó en tu proyecto.

A continuación, veamos un ejemplo de cómo Lightbuild mejora la experiencia de los desarrolladores con la sincronización de proyectos.

Ahora, volví a mi project.lightbuild.yaml de nivel raíz, la configuración global que enumera todos los módulos de mi aplicación.

Normalmente, cuando editas archivos de configuración o de configuración de compilación, notarás que aparece un botón de sincronización que tarda un poco en procesar todo debido a los procesos que Juan describía, en los que se debe realizar una compilación parcial ejecutando todas las secuencias de comandos de compilación y, luego, sincronizando ese modelo con el IDE.

Hagamos un cambio bastante importante para este pequeño proyecto.

Solo borraremos uno de los módulos.

Y puedes ver que este módulo, antes de que presione el botón de guardar, el IDE lo reconoce porque puedes ver que está en negrita aquí.

Reconoció el directorio del código fuente y los directorios de prueba.

En cuanto guarde el cambio, verás que este módulo desaparece de inmediato del proyecto.

Y si deshago ese cambio de nuevo y presiono Guardar, vuelve a aparecer con la misma rapidez.

Este es un ejemplo de la sincronización rápida del IDE que Lightbuild aporta a tus proyectos.

Además, puedes ejecutar todos los comandos normales que sueles usar en Android Studio.

Puedes presionar el botón de ejecución.

Compilará tu app y la ejecutará aquí.

Esta app de demostración en particular no es muy grande, pero acercaré la imagen para mostrar que dice "Hello Android".

Puedes ejecutar las pruebas como lo harías normalmente. Para ello, ve al archivo de prueba y ejecútalo desde el margen, de la siguiente manera.

En realidad, está invocando Lightbuild tras bambalinas para ejecutar estas pruebas.

Por lo tanto, todo esto funciona como se espera.

Pero, a continuación, quiero mostrarte cómo usar Lightbuild si no estás en Android Studio, si usas algún otro flujo de agentes.

Y para eso, tenemos la línea de comandos.

Por lo tanto, en la CLI de Lightbuild, solo ejecutaré el comando de ayuda básico.

Y sí, todos los errores tipográficos que ves en este proyecto hoy son míos.

Lightbuild tendrá varios comandos diferentes integrados, como… Oh, lo siento, estoy ejecutando esto fuera de un proyecto.

Me sigue diciendo eso.

Sí, una demostración en vivo.

Primero, antes de ejecutar cualquier comando de Lightbuild, crearé un proyecto de Lightbuild.

Para eso, usaré android create, que es nuestra herramienta de línea de comandos estándar para crear nuevas plantillas de proyectos.

Usaré la plantilla empty-activity-lightbuild, asignaré el nombre Lightbuild Demo a mi app y la colocaré en el directorio de resultados de la demostración.

Ahora, si ingreso a ese directorio y escribo lightbuild -h, veré todos los comandos que Lightbuild tiene disponibles.

Tenemos muchas cosas que esperarías: compilar, limpiar, probar.

Pero hay algunas nuevas.

Existe un comando de resolución, que, de hecho, se ejecuta a través de las dependencias de tu proyecto y genera esos archivos resolved.deps que mostré antes.

Y hay un comando de consulta que te permite a ti y a tus agentes comprender mejor la estructura de tu proyecto.

Primero, ¿por qué no muestro ese nuevo comando de consulta?

Si observo la estructura de este proyecto con la línea de comandos, es la misma que tenía en la demostración de Android Studio.

Pero esto no me dice mucho sobre cómo está estructurado mi proyecto.

Entonces, si hago una consulta de Lightbuild y observo, por ejemplo, este módulo de la app, usaré esta sintaxis especial para decir: "Muéstrame todo lo que hay en este módulo de la app".

Y me da esta bonita tabla de diferentes destinos que puedo compilar dentro del módulo de la app.

Por lo tanto, tiene los APK y AAB para los objetos binarios de depuración y de lanzamiento.

Si solo ejecuto el destino de la app, se compilará todo.

También hay una forma de especificar el resultado como JSON.

Y de esa manera… Oh, lo siento.

De nuevo, todos mis errores de escritura son reales hoy.

Aquí, usaré la ayuda interactiva de Lightbuild para asegurarme de que lo estoy haciendo correctamente.

Mmm…

Sí, debería funcionar.

Bien.

Bueno, si alguien puede decirme qué estoy haciendo mal, que hable conmigo después de esta charla.

Pero, de todos modos, en lugar de esta tabla, también puedes generar tus comandos de Lightbuild como JSON, lo que es más fácil para tus agentes.

--format json…

Ah, el formato.

Perdón.

Gracias.

Estos son comentarios en vivo de los desarrolladores.

Gracias.

Sí, y también está ese comando de salida que también puedo mostrar, tal vez con tu ayuda.

Por lo tanto, si genero los archivos en lugar de los destinos, se mostrarán las ubicaciones de todos los objetos binarios diferentes dentro de mi compilación.

Esta es solo una forma de que tú y tus agentes puedan explorar y comprender mejor tu proyecto desde la línea de comandos con Lightbuild.

Luego, por supuesto, está el comando lightbuild resolve que mencioné antes, que generará todos tus archivos resolved.deps.

Esa también tiene algunas funciones adicionales.

Por ejemplo, existe este parámetro de dependencias bloqueadas y, con eso, en lugar de solo generar estos archivos, en realidad comparará el contenido de los archivos con las dependencias que declaraste en tu configuración de compilación.

Si hay alguna diferencia, te lo informará y fallará la compilación.

De esta manera, estos archivos de dependencias resueltas pueden actuar como archivos de bloqueo. Por ejemplo, si estás compilando tu app en un sistema de CI/CD para producción, querrás saber si alguna dependencia cambia durante esa compilación.

Además, Lightbuild tiene una función de prueba integrada, y también puedes ejecutar todas las pruebas de este módulo de biblioteca, por ejemplo, directamente desde la línea de comandos.

Y hay algo más que quiero mostrarte.

Solo que también tiene la ayuda disponible que te dará una lista muy completa de toda la compilación de todos los parámetros y subcomandos que puedes usar.

Eso está disponible para tu agente, por lo que este es el resultado para el agente.

Bien.

Ahora que vimos algunos proyectos simples con Lightbuild, quiero mostrarles cómo se ve un proyecto un poco más ambicioso.

Tenemos una app de ejemplo que el equipo de Android puso a disposición, llamada Now in Android, que te ofrece algunas de las funciones más recientes de Android, te muestra cómo usarlas y te muestra algunas prácticas recomendadas.

Es una aplicación altamente modular.

Está dividido en, creo, 32 módulos diferentes.

Así es como se ve en GitHub.

Pero volveré a Android Studio, donde ya usé mi agente con anticipación.

Estaba usando Gemini Argon para convertir el proyecto Now in Android a Lightbuild.

Esto no es algo que hayamos publicado, sino algo que hice por mi cuenta.

Y puedes ver que, aunque este proyecto en mi project.lightbuild.yaml tiene todos estos módulos diferentes, se abrió de forma increíblemente rápida y se sincronizó con este IDE de una manera muy rápida.

Otra cosa que querrás notar sobre este proyecto en particular es que usaba algunas variantes de compilación o configuraciones de compilación especiales para tener una compilación de demostración y una de producción, cada una con una forma ligeramente diferente de presentar la app.

La versión de demostración usaría fuentes de datos integradas, y la versión de producción realmente se conecta a la red y extrae datos.

Para hacerlo con Lightbuild, la forma en que maneja elementos como diferentes configuraciones de compilación o variantes de productos es que ingresas a tu módulo de aplicación y especificas que este módulo de aplicación es, por ejemplo, la aplicación de demostración.

Por lo tanto, dependerá de todos los componentes principales, pero también extraerá parámetros de configuración especiales solo para la versión de demostración de la app.

De esta manera, puedes tener varios módulos de aplicación.

Cada una puede representar, por ejemplo, una versión pagada o gratuita de tu app.

Y aún obtienes los beneficios de que el módulo de la aplicación sea un shell vacío sin código que se compila mucho más rápido y, cada vez que cambian tus bibliotecas, solo esas deben volver a compilarse para volver a compilar tu app.

Veamos si esta app para Android de Now in Android se está compilando correctamente con Lightbuild con sus 32 módulos diferentes.

Sí, ahí está.

Y quiero señalar que, gracias a experimentos como este, aprendimos que Lightbuild no siempre admite todas las funciones de compilación que podrías necesitar.

Por ejemplo, la app para Android de Now in Android depende de un complemento de Hilt para usar Hilt, y Lightbuild aún no admite ese tipo de cosas.

Por lo tanto, mi agente pudo encontrar una solución alternativa y, aun así, obtener la compatibilidad con Hilt sin cambiar mucho el código del proyecto.

Todo el código de estos módulos es el mismo que el del repositorio original.

Pero eso es algo que definitivamente debes tener en cuenta cuando experimentes y pruebes Lightbuild por tu cuenta: no todo en tu proyecto actual será compatible en términos de configuración de compilación.

Por eso, Lightbuild aún está en versión preliminar, en Android Studio Canary.

Y con eso, me gustaría volver a las diapositivas.

Y sí, para resumir todo lo que hablamos aquí, recuerda que Lightbuild es una nueva plataforma de compilación para Android, que actualmente es experimental.

Tiene una configuración de compilación declarativa, por lo que no ejecutas ningún código ejecutable en tus parámetros de configuración de compilación, y eso desbloquea muchas funciones excelentes con una sincronización rápida del IDE y compilaciones más eficientes.

Tiene compatibilidad de primer nivel con agentes de IA, en la línea de comandos, tiene todas esas funciones que me ayudaste a mostrar hoy.

Por lo tanto, te invitamos a probarlo y usarlo para proyectos experimentales y de demostración.

Además, Juan y yo, junto con algunos de los ingenieros del equipo, estaremos en el stand de IA agéntica para responder cualquier pregunta que tengan.

Muchas gracias.