Builds declarativos do Android prontos para agentes com o Lightbuild

Olá!

Meu nome é Juan Sebastian Oviedo.

Sou gerente de produtos na equipe de experiência do desenvolvedor Android.

Estou aqui com o Scott, e hoje vamos mostrar em primeira mão o Lightbuild, uma nova experiência experimental de build para apps Android.

Vou explicar o contexto desse projeto, a filosofia por trás dele e por que acreditamos que agora é o momento certo para repensar como os projetos do Android são configurados.

Também vou explicar como essa nova abordagem nos prepara para o futuro do desenvolvimento de apps Android.

Vamos começar com um contexto sobre como as coisas funcionam hoje.

O Gradle e os scripts de build imperativos permitem que os desenvolvedores definam de forma programática quase tudo sobre os builds.

Por exemplo, é possível ter uma lógica que calcula dinamicamente os códigos de versão com base no histórico do Git ou definir uma tarefa personalizada que transforma 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"

    }

  }

}

Além do Gradle, há o AGP ou o Plug-in do Android para Gradle, que usa o mecanismo de uso geral do Gradle e o adapta ao conjunto de ferramentas do Android.

Juntos, o Gradle e o AGP formam um sistema dinâmico que possibilita a experiência de configuração de build para milhões de apps de produção atualmente.

Devido a essa flexibilidade, nossas ferramentas para desenvolvedores operam em um ciclo de vida arquitetônico específico.

Quando você abre um projeto, troca de ramificação ou edita um arquivo de build, o ambiente de desenvolvimento integrado precisa ter um mapa claro, uma compreensão clara da configuração do projeto, para que possa oferecer recursos como preenchimento automático e navegação de código.

Como os arquivos de build são escritos em uma linguagem imperativa e Turing-completa, a única maneira geral de o ambiente de desenvolvimento integrado saber qual é a configuração é executar os scripts de build.

Durante a sincronização do ambiente de desenvolvimento integrado, o sistema de build passa por uma fase de configuração.

Ele avalia os scripts de build, executa a lógica do plug-in e constrói o modelo do projeto.

Isso alinha a visualização do projeto no Android Studio com a configuração real do projeto.

Como desenvolvedor, o mais importante para você é oferecer um ótimo app Android e disponibilizá-lo para os usuários.

No entanto, gerenciar scripts de build, manter o AGP atualizado e manter o projeto sincronizado com o ambiente de desenvolvimento integrado exige tempo e esforço.

Há várias iniciativas no Google e no ecossistema em geral para melhorar a experiência do desenvolvedor nessa área.

Iniciativas como o Declarative Gradle e o conjunto de ferramentas do Kotlin têm como objetivo substituir scripts de build executáveis por configurações de build declarativas.

No Android Studio, temos o Assistente de Upgrade do AGP, que orienta você nas mudanças necessárias para passar de uma versão do AGP para outra.

Também oferecemos uma skill de upgrade que os agentes podem instalar e seguir para fazer upgrade do AGP.

Além disso, estamos investindo em áreas como sincronização em fases e sincronização resiliente, para que os desenvolvedores tenham uma experiência melhor ao sincronizar e importar os projetos.

Cada um desses esforços visa uma peça do quebra-cabeça para que os desenvolvedores possam passar mais tempo criando apps e menos tempo criando projetos, gerenciando arquivos de build e sincronizando projetos.

Além disso, nos fizemos uma pergunta mais ampla.

E se reimaginássemos a forma como os projetos são configurados do zero?

Ao analisarmos a arquitetura dos apps Android modernos, vemos uma grande mudança em direção à modularização pesada.

As bases de código grandes geralmente têm dezenas ou até centenas de módulos: de interface, módulos de recurso, de domínio e de dados.

Embora o aplicativo raiz possa, às vezes, precisar de um empacotamento personalizado, a grande maioria desses módulos de biblioteca segue um padrão padronizado e repetível.

Eles não precisam ter um código executável arbitrário nos arquivos de build.

Eles só precisam de uma maneira clara de declarar a estrutura e as dependências.

Essa observação nos levou a criar o Lightbuild.

O Lightbuild se baseia em dois pilares.

Primeiro, ele usa uma sintaxe declarativa para configuração, o que permite uma separação clara entre a configuração do build e a lógica.

Em segundo lugar, ele oferece uma experiência rápida de sincronização do ambiente de desenvolvimento integrado com a resolução de dependências antecipada.

Vou explicar cada um desses pilares em detalhes para que você entenda como eles afetam seu fluxo de trabalho diário.

Vamos começar com o pilar da configuração do build declarativa.

Confira o arquivo no lado esquerdo da tela.

Isso representa a configuração de um módulo hoje.

// 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 esse arquivo é um código executável, ele pode ter definições de variáveis locais, chamadas para funções auxiliares personalizadas ou plug-ins de convenção, instruções condicionais e definições de tarefas inline.

Para que o ambiente de desenvolvimento integrado saiba o que essa configuração resolve, ele precisa executar o script.

Agora, confira o arquivo no lado direito da tela.

Esta é a configuração do Lightbuild para um módulo semelhante.

# 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

Esse arquivo é composto apenas por dados declarativos.

Não há definições de variáveis locais, chamadas para funções auxiliares personalizadas, instruções condicionais ou definições de tarefas inline.

Ele indica claramente o tipo do módulo, as metas do SDK e as dependências.

Se um novo engenheiro entrar na sua equipe e abrir esse arquivo, ele não terá que decifrar idiomas de build personalizados, e todos os módulos do Lightbuild em todos os projetos do Lightbuild vão usar a mesma linguagem de leitura imediata.

Embora a separação entre configuração e lógica seja ótima para a legibilidade humana, ela é ainda mais transformadora para fluxos de trabalho assistidos por agentes.

À medida que os desenvolvedores adotam agentes como parte do fluxo de trabalho, esses agentes precisam ser capazes de ler e modificar a configuração do build.

No entanto, não há como prever os efeitos colaterais de uma mudança de configuração sem criar o projeto.

Adicionar uma única linha a um arquivo de configuração pode entrar em conflito com uma variável calculada dinamicamente em outro lugar do projeto ou com um plug-in de convenção.

No Lightbuild, a configuração do projeto é um gráfico de dados estático e determinista.

Isso significa que os agentes podem inspecionar esse gráfico, entender a topologia do módulo e modificá-lo usando um esquema conhecido.

Um agente pode ver a lista de módulos, a lista de dependências e as versões delas, atualizar dependências ou até mesmo adicionar um módulo de recurso totalmente novo simplesmente lendo e gravando dados estruturados.

Ele torna a configuração do seu projeto um cidadão de primeira classe para fluxos de trabalho assistidos por agentes.

Outro detalhe que quero destacar é que o Lightbuild não é um plug-in para um sistema de build, mas uma interface para o mecanismo de build.

A versão do Lightbuild, o pré-lançamento que estamos lançando hoje, usa o Gradle como mecanismo de execução.

No entanto, a abordagem arquitetônica que seguimos com o Lightbuild faz com que o Android Studio, o ambiente de desenvolvimento integrado, veja e trate o projeto como um projeto do Lightbuild.

Agora vamos falar sobre o segundo pilar, que é sobre a produtividade e o fluxo do desenvolvedor: a sincronização rápida do ambiente de desenvolvimento integrado.

Mesmo que os desenvolvedores adotem agentes como parte do fluxo de trabalho, o Android Studio continua sendo uma ferramenta essencial para tarefas interativas, por exemplo, para revisar prévias da interface do Compose, analisar o código no depurador como parte da investigação de um problema ou analisar o desempenho com o criador de perfil.

Como a configuração do projeto é um gráfico de dados estático e determinista, o ambiente de desenvolvimento integrado não precisa passar por uma fase de avaliação de script nem executar o código do plug-in para entender o projeto.

Seja para abrir um projeto, editar um arquivo de build ou trocar de ramificação, o ambiente de desenvolvimento integrado pode processar essas informações rapidamente e levar você direto para as ferramentas.

Um dos motivos para essa velocidade e confiabilidade é a maneira como o Lightbuild lida com as dependências.

Normalmente, quando você declara uma dependência, o sistema de build precisa passar por uma árvore de dependências transitivas para coletar informações de versão e resolver conflitos.

No Lightbuild, sempre que as dependências mudam, a ferramenta calcula automaticamente as informações de dependência transitiva e as grava em um arquivo resolved.deps dentro de cada diretório de módulo.

Isso faz com que, quando o projeto for aberto novamente no futuro ou recriado, nem o ambiente de desenvolvimento integrado nem a ferramenta de build precisem recalcular as informações de dependência transitiva.

Recomendamos que você verifique esses arquivos no controle de origem para que, ao enviar mudanças para revisão, seus colegas de equipe possam ver se houve alguma mudança nas informações de dependência transitiva e as máquinas deles não precisem recalcular essas informações.

Além disso, ao verificar essas informações no controle de origem, você, seus colegas de equipe e seus pipelines de CI/CD podem criar com as mesmas versões de dependência sempre.

Temos o prazer de anunciar que o Lightbuild está disponível como um pré-lançamento no Android Studio Canary e também em ferramentas de CLI independentes.

Essa versão do Lightbuild é experimental, então não tem todos os recursos necessários para criar e manter um aplicativo de produção.

Continue usando o AGP e o Gradle para seus aplicativos de produção enquanto testa o Lightbuild em projetos de demonstração e experimentais.

Para começar, acesse goo.gle/lightbuild. Queremos muito receber seu feedback para que você nos ajude a moldar o produto conforme ele evolui.

Agora, vou passar a apresentação para o Scott, que vai mostrar o Lightbuild em ação.

Obrigado, Juan.

Meu nome é Scott Myers.

Sou engenheiro de relações com desenvolvedores Android. Estamos trabalhando no Lightbuild há algum tempo e queremos mostrar como você pode começar a usar e testar essa ferramenta hoje mesmo.

Então, a primeira coisa a fazer é acessar o link que o Juan mencionou, goo.gle/lightbuild, ou pesquisar por Lightbuild.

Isso vai levar você a esta página de documentação, que tem todas as etapas necessárias para começar, incluindo a instalação de uma versão Canary do Android Studio. Lembre-se de que esse recurso ainda está em pré-lançamento e não está na versão estável do Android Studio.

Além disso, há uma CLI do Lightbuild que pode ser instalada para aproveitar todos os benefícios da experiência agêntica com o Lightbuild.

Depois de configurar isso, como fiz na minha máquina, tenho a versão mais recente do Android Studio Canary em execução.

Agora, vou mostrar como criar um projeto de demonstração do Lightbuild e como você pode fazer isso hoje mesmo.

Primeiro, vou acessar o assistente de novo projeto.

Vou escolher "Empty Activity" e clicar em "Next".

Agora você verá que esta é a tela normal de detalhes do projeto, mas na parte de baixo há uma nova opção.

Em "Linguagem de configuração do build", escolha "Lightbuild".

E vai lembrar que esse é um recurso experimental antes de você clicar em "Concluir".

Você vai notar que o projeto é sincronizado com o ambiente de desenvolvimento integrado e está pronto para ser usado.

Agora vamos analisar a estrutura de um projeto típico do Lightbuild.

Esse é o modelo padrão do Android que você recebe ao criar um novo aplicativo.

Ele só diz "Hello, world!"

É uma maneira simples de começar.

No nível raiz do projeto, temos um arquivo chamado project.lightbuild.yaml.

Isso nos dá as configurações globais de todo o projeto.

Assim, você pode dar um nome ao projeto, listar todos os módulos dele, dizer de quais repositórios externos você extrai as dependências e, em seguida, as versões que são aplicadas globalmente às diferentes partes do projeto.

Temos dois módulos aqui: app e app-core.

Isso ocorre porque todos os projetos do Lightbuild têm pelo menos dois módulos.

Isso ocorre porque é necessário ter pelo menos um módulo de app e pelo menos um módulo de biblioteca.

Vou explicar o motivo em um segundo.

Primeiro, vamos dar uma olhada no módulo do app.

Se eu expandir aqui, você vai ver que, no nível raiz do módulo, há um arquivo lightbuild.yaml, que todos os módulos têm.

Aqui, há algumas informações básicas.

Estamos trabalhando na plataforma Android, é claro.

E esse módulo é do tipo aplicativo.

Você pode listar as versões de destino do SDK, o ID do aplicativo etc. e, em seguida, listar todos os módulos de que esse módulo de aplicativo depende.

O que é interessante sobre esse módulo de aplicativo, que é um pouco diferente do modelo padrão do Android, é que não há nada na pasta de origem.

Portanto, no Lightbuild, os módulos de aplicativo não contêm código-fonte.

Isso acontece porque esse módulo do app não vai mudar com frequência, mas leva algum tempo para ser criado.

Portanto, se você mantiver todo o código do aplicativo nos módulos de biblioteca, cada build vai acontecer mais rápido, porque não será necessário recalcular e reempacotar tudo no módulo do app.

Em seguida, vamos analisar o módulo app-core, que é o módulo de biblioteca de que esse módulo de aplicativo depende.

E você pode ver que esse módulo realmente tem código-fonte.

Ele tem nossa lógica principal aqui.

Ele só diz "Hello, world!"

E se eu der uma olhada no arquivo lightbuild.yaml neste módulo, você pode ver que ele é do tipo biblioteca.

Aqui, ele também define alguns números de versão do SDK, mas lista todas as dependências externas que temos nesse módulo.

Ele também declara nossos testes de unidade e de instrumentação.

Agora, vamos dar uma olhada em outro arquivo que você pode ter notado aqui, e o Juan falou um pouco sobre isso, há um arquivo resolved.deps dentro de cada módulo.

Esse arquivo é gerado automaticamente pelo Lightbuild.

Isso significa que você não deve editá-lo manualmente, mas ele vai conter uma lista de todas as dependências resolvidas nesse módulo.

Portanto, todas as suas dependências e dependências transitivas já estão aqui.

Isso significa que, quando o aplicativo é aberto no ambiente de desenvolvimento integrado ou quando você vai criar um build, não é necessário descobrir isso, porque já foi descoberto com antecedência e verificado no projeto.

Agora vamos conferir um exemplo de como o Lightbuild melhora a experiência do desenvolvedor com a sincronização de projetos.

Agora, voltei para o project.lightbuild.yaml no nível raiz, as configurações globais que listam todos os módulos do meu aplicativo.

E, normalmente, ao editar arquivos de configuração ou de configuração do build, você vai notar que um botão de sincronização aparece e leva algum tempo para processar tudo isso devido aos processos que o Juan estava descrevendo, em que é necessário fazer um build parcial executando todos os scripts de build e, em seguida, sincronizar esse modelo com o ambiente de desenvolvimento integrado.

Então, vamos fazer uma mudança bem grande para esse pequeno projeto.

Vamos excluir um dos módulos.

E você pode ver que esse módulo, antes de eu clicar no botão de salvar, é reconhecido pelo ambiente de desenvolvimento integrado porque está em negrito aqui.

Ele reconheceu o diretório de origem e os diretórios de teste.

Assim que eu salvar, depois de fazer essa mudança, você vai notar que esse módulo desaparece instantaneamente do projeto.

E se eu desfizer essa mudança novamente e clicar em "Salvar", ela vai voltar com a mesma rapidez.

Esse é o exemplo da sincronização rápida do ambiente de desenvolvimento integrado que o Lightbuild traz para seus projetos.

Além disso, você pode usar todos os comandos normais que já conhece no Android Studio.

Clique no botão de execução.

Ele vai compilar e executar o app aqui.

Este app de demonstração não é muito grande, mas vou aumentar o zoom para mostrar que ele está dizendo "Hello Android".

Você pode executar os testes normalmente acessando o arquivo de teste e executando-o na medianiz, assim.

E ele está invocando o Lightbuild aqui nos bastidores para executar esses testes.

Então, tudo isso funciona como esperado.

Mas agora quero mostrar como usar o Lightbuild se você não estiver no Android Studio, se estiver usando outro fluxo de agentes.

Para isso, temos a linha de comando.

Então, na CLI do Lightbuild, vou executar o comando de ajuda básico.

E sim, todos os erros de digitação que você vê neste projeto hoje são meus.

O Lightbuild vai ter vários comandos diferentes integrados, como… Ah, desculpe, estou executando isso fora de um projeto.

Ele continua me dizendo isso.

Sim, demonstração ao vivo.

Então, antes de executar qualquer comando do Lightbuild, vou criar um projeto do Lightbuild.

Para isso, vou usar o android create, que é nossa ferramenta de linha de comando padrão para criar novos modelos de projeto.

Vou usar o modelo empty-activity-lightbuild, nomear meu app como Lightbuild Demo e colocá-lo no diretório de saída de demonstração.

Agora, se eu entrar nesse diretório e digitar lightbuild -h, vou ver todos os comandos disponíveis no Lightbuild.

Temos muitas coisas que você espera: build, clean, test.

Mas há algumas novas.

Há um comando de resolução, que analisa as dependências do projeto e gera os arquivos resolved.deps que mostrei anteriormente.

E há um comando de consulta, que permite que você e seus agentes entendam melhor a estrutura do projeto.

Primeiro, que tal mostrar o novo comando de consulta?

Se eu analisar a estrutura desse projeto usando a linha de comando, ela é a mesma que eu tinha na demonstração do Android Studio.

Mas isso não me diz muito sobre como meu projeto está organizado.

Então, se eu fizer uma consulta do Lightbuild e analisar, por exemplo, este módulo de app, vou usar essa sintaxe especial para dizer: "Mostre tudo o que está nesse módulo de app".

E ela me dá essa tabela de diferentes destinos que posso criar no módulo do app.

Portanto, ele tem os APKs e AABs para os binários de depuração e de lançamento.

Se eu executar apenas o destino do app, ele vai criar tudo.

Também é possível especificar a saída como JSON.

Assim, ah, desculpe.

Hoje estou errando tudo.

Vou usar a ajuda interativa do Lightbuild para garantir que estou fazendo isso corretamente.

Hum…

Sim, deveria estar funcionando.

Certo.

Se alguém puder me dizer o que estou fazendo de errado, fale comigo depois desta palestra.

Mas, em vez dessa tabela, você também pode gerar os comandos do Lightbuild como JSON, o que é mais fácil para os agentes.

--format json…

Ah, formato.

Ah, desculpa.

Nossa equipe agradece.

Esse é um feedback em tempo real do desenvolvedor.

Nossa equipe agradece.

Certo, sim, e também há o comando de saída que posso demonstrar, talvez com sua ajuda.

Se eu gerar os arquivos em vez dos destinos, vou ver os locais de todos os binários diferentes no meu build.

Essa é uma maneira de você e seus agentes explorarem e entenderem melhor o projeto na linha de comando usando o Lightbuild.

Depois, é claro, há o comando lightbuild resolve que mencionei anteriormente, que vai gerar todos os arquivos resolved.deps.

Esse também tem alguns recursos extras.

Por exemplo, há esse parâmetro de dependências bloqueadas. Com ele, em vez de apenas gerar esses arquivos, o sistema vai comparar o conteúdo deles com as dependências declaradas na configuração do build.

Se houver diferenças, ele vai informar você e falhar no build.

Dessa forma, esses arquivos de dependências resolvidas podem funcionar como arquivos de bloqueio. Por exemplo, se você estiver criando seu app em um sistema de CI/CD para produção, vai querer saber se alguma dependência está mudando durante esse build.

Além disso, o Lightbuild tem um recurso de teste integrado, e você também pode executar todos os testes nesse módulo de biblioteca, por exemplo, diretamente na linha de comando.

E tem mais uma coisa que quero mostrar.

A ajuda disponível também oferece uma lista completa de todos os parâmetros e subcomandos que você pode usar.

que está disponível para o agente. Essa é a saída para o agente.

Certo.

Agora que vimos alguns projetos simples com o Lightbuild, quero mostrar como é um projeto um pouco mais ambicioso.

Temos um app de exemplo disponibilizado pela equipe do Android chamado Now in Android, que oferece alguns dos recursos mais recentes do Android, mostra como usá-los e apresenta algumas práticas recomendadas.

É um aplicativo altamente modular.

Ele é dividido em cerca de 32 módulos diferentes.

É assim que ele aparece no GitHub.

Mas vou voltar para o Android Studio, onde já usei meu agente com antecedência.

Eu estava usando o Gemini Argon para converter o projeto Agora no Android para o Lightbuild.

Não é algo que publicamos, mas que fiz por conta própria.

E você pode ver que, mesmo que este projeto no meu project.lightbuild.yaml tenha todos esses módulos diferentes, ele ainda é aberto de forma incrivelmente rápida e sincronizado com este ambiente de desenvolvimento integrado de maneira muito rápida.

Outra coisa que você vai notar sobre esse projeto específico é que ele usava algumas variações de build, ou configurações de build especiais, para ter um build de demonstração e um de produção, cada um com uma maneira ligeiramente diferente de apresentar o app.

A de demonstração usaria fontes de dados integradas, e a de produção acessaria a rede e extrairia dados.

Para fazer isso com o Lightbuild, que lida com diferentes configurações de build ou variações de produtos, você acessa o módulo do aplicativo e especifica que ele é, por exemplo, o aplicativo de demonstração.

Assim, ele vai usar todos os componentes principais, mas também vai extrair configurações especiais apenas para a versão de demonstração do app.

Assim, é possível ter vários módulos de aplicativo.

Cada uma pode representar, por exemplo, uma versão paga ou sem custo financeiro do app.

E você ainda tem os benefícios de o módulo do aplicativo ser um shell vazio sem código, que é criado muito mais rápido. Sempre que as bibliotecas mudam, apenas elas precisam ser recompiladas para criar o app novamente.

Vamos conferir se o app Agora no Android está sendo criado com o Lightbuild e todos os 32 módulos diferentes.

Sim, aí está.

E quero destacar que, com experimentos como esse, aprendemos que o Lightbuild nem sempre é compatível com todos os recursos de build que você pode precisar.

Por exemplo, o app Now in Android depende de um plug-in do Hilt para usar o Hilt, e o Lightbuild ainda não oferece suporte para esse tipo de coisa.

Então, meu agente conseguiu encontrar uma solução alternativa e ainda receber o suporte do Hilt sem mudar muito o código do projeto em si.

Todo o código em todos esses módulos é igual ao do repositório original.

Mas é importante lembrar que, ao testar e demonstrar o Lightbuild, nem tudo no seu projeto atual será compatível em termos de configuração do build.

Por isso, o Lightbuild ainda está em pré-lançamento, no Android Studio Canary.

Agora, vamos voltar aos slides.

E, para resumir tudo o que falamos aqui, lembre-se do Lightbuild, uma nova plataforma de build para Android, que está em fase experimental.

Ele tem uma configuração de build declarativa, então você não executa nenhum código executável nas configurações de build, o que desbloqueia muitos recursos excelentes com sincronização rápida do ambiente de desenvolvimento integrado e builds mais eficientes.

Ele tem suporte de primeira classe para agentes de IA, na linha de comando, tem todos os recursos que você me ajudou a demonstrar hoje.

Por isso, convidamos você a testar e usar o Gemini em projetos de demonstração e experimentais.

Além disso, eu, o Juan e alguns engenheiros da equipe vamos estar no estande de IA agêntica para responder às suas perguntas.

Então, muito obrigada.