Deklarative, KI-Agenten-fähige Android-Builds mit Lightbuild

Hallo zusammen.

Ich heiße Juan Sebastian Oviedo.

Ich bin Produktmanager im Android Developer Experience-Team.

Ich bin hier mit Scott und wir freuen uns, Ihnen heute einen ersten Einblick in Lightbuild zu geben, eine neue experimentelle Build-Umgebung für Android-Apps.

Ich werde den Kontext für dieses Projekt, die Philosophie dahinter und die Gründe erläutern, warum wir glauben, dass jetzt der richtige Zeitpunkt ist, die Konfiguration von Android-Projekten zu überdenken.

Außerdem werde ich darauf eingehen, wie dieser neue Ansatz uns auf die Zukunft der Android-App-Entwicklung vorbereitet.

Beginnen wir mit einigen Informationen dazu, wie die Dinge heute funktionieren.

Mit Gradle und imperativen Build-Scripts können Entwickler fast alles in ihren Builds programmatisch definieren.

Sie können beispielsweise eine Logik verwenden, die Versionscodes dynamisch anhand des Git-Verlaufs berechnet, oder eine benutzerdefinierte Aufgabe definieren, die Assets transformiert.

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

    }

  }

}

Neben Gradle gibt es das AGP oder Android Gradle-Plug-in, das die allgemeine Engine von Gradle an die Android-Toolchain anpasst.

Zusammen bilden Gradle und das AGP ein dynamisches System, das die Build-Konfiguration für Millionen von Produktions-Apps ermöglicht.

Aufgrund dieser Flexibilität unterliegen unsere Entwicklungstools einem bestimmten Architekturlebenszyklus.

Wenn Sie ein Projekt öffnen, Branches wechseln oder eine Build-Datei bearbeiten, benötigt die IDE eine klare Übersicht und ein klares Verständnis Ihrer Projektkonfiguration, um Funktionen wie Codevervollständigung und Codenavigation zu ermöglichen.

Da Build-Dateien in einer imperativen, Turing-vollständigen Sprache geschrieben sind, kann die IDE die Konfiguration nur durch Ausführen der Build-Skripts ermitteln.

Während der IDE-Synchronisierung durchläuft das Build-System eine Konfigurationsphase.

Es wertet Ihre Build-Scripts aus, führt die Plug-in-Logik aus und erstellt das Projektmodell.

Dadurch wird die Ansicht Ihres Projekts in Android Studio an die tatsächliche Projektkonfiguration angepasst.

Als Entwickler ist es Ihnen am wichtigsten, eine hochwertige Android-App zu entwickeln und sie Ihren Nutzern zur Verfügung zu stellen.

Das Verwalten von Build-Scripts, das Aktualisieren des AGP und das Synchronisieren des Projekts mit der IDE erfordern jedoch Zeit und Aufwand.

Sowohl bei Google als auch im gesamten Ökosystem gibt es mehrere Initiativen, die darauf abzielen, die Entwicklererfahrung in diesem Bereich zu verbessern.

Initiativen wie Declarative Gradle und die Kotlin-Toolchain zielen darauf ab, ausführbare Build-Skripts durch deklarative Build-Konfigurationen zu ersetzen.

In Android Studio gibt es den AGP-Upgrade-Assistenten, der Sie durch die Änderungen führt, die für den Wechsel von einer AGP-Version zu einer anderen erforderlich sind.

Wir bieten auch einen Upgrade-Skill, den Kundenservicemitarbeiter installieren und befolgen können, um ein Upgrade für AGP durchzuführen.

Außerdem investieren wir in Bereiche wie die phasenweise und die resiliente Synchronisierung, um Entwicklern die Synchronisierung und den Import ihrer Projekte zu erleichtern.

Jede dieser Maßnahmen zielt auf einen Teil des Puzzles ab, damit Entwickler mehr Zeit für die Erstellung ihrer Apps und weniger Zeit für die Erstellung ihrer Projekte, die Verwaltung ihrer Build-Dateien und die Synchronisierung ihrer Projekte aufwenden müssen.

Neben diesen Bemühungen haben wir uns eine umfassendere Frage gestellt.

Was wäre, wenn wir die Art und Weise, wie Projekte konfiguriert werden, von Grund auf neu gestalten würden?

Wenn wir uns die Architektur moderner Android-Apps ansehen, stellen wir eine starke Tendenz zu einer starken Modularisierung fest.

Große Codebasen haben oft Dutzende oder sogar Hunderte von Modulen: UI-Module, Funktionsmodule, Domainmodule und Datenmodule.

Und während die Root-Anwendung gelegentlich ein benutzerdefiniertes Paket benötigt, folgt die überwiegende Mehrheit dieser Bibliotheksmodule einem standardisierten, wiederholbaren Muster.

Sie benötigen eigentlich keinen beliebigen ausführbaren Code in ihren Build-Dateien.

Sie benötigen lediglich eine klare Möglichkeit, ihre Struktur und ihre Abhängigkeiten anzugeben.

Diese Beobachtung hat uns dazu veranlasst, Lightbuild zu entwickeln.

Lightbuild basiert auf zwei Säulen.

Erstens wird eine deklarative Syntax für die Konfiguration verwendet, was eine klare Trennung zwischen Build-Konfiguration und Logik ermöglicht.

Zweitens wird durch die vorzeitige Abhängigkeitsauflösung eine schnelle IDE-Synchronisierung ermöglicht.

Ich werde auf jeden dieser Grundsätze im Detail eingehen, damit Sie sehen, wie sie sich auf Ihren täglichen Arbeitsablauf auswirken.

Beginnen wir mit der Säule der deklarativen Build-Konfiguration.

Sehen Sie sich die Datei auf der linken Seite des Bildschirms an.

Dies ist die aktuelle Konfiguration für ein Modul.

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

Da diese Datei ausführbarer Code ist, kann sie lokale Variablendefinitionen, Aufrufe von benutzerdefinierten Hilfsfunktionen oder Konventions-Plug-ins, bedingte Anweisungen und Inline-Aufgabendefinitionen enthalten.

Damit die IDE weiß, was diese Konfiguration auflöst, muss sie das Skript tatsächlich ausführen.

Sehen Sie sich nun die Datei auf der rechten Seite des Bildschirms an.

Dies ist die Lightbuild-Konfiguration für ein ähnliches Modul.

# 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

Diese Datei enthält rein deklarative Daten.

Es gibt keine lokalen Variablendefinitionen, keine Aufrufe benutzerdefinierter Hilfsfunktionen und keine bedingten Anweisungen oder Inline-Aufgabendefinitionen.

Darin werden der Typ des Moduls, seine SDK-Ziele und seine Abhängigkeiten klar angegeben.

Wenn ein neuer Entwickler Ihrem Team beitritt und diese Datei öffnet, muss er keine benutzerdefinierten Build-Idiome entschlüsseln. Jedes Lightbuild-Modul in jedem Lightbuild-Projekt verwendet dieselbe sofort lesbare Sprache.

Die Trennung von Konfiguration und Logik ist nicht nur für die Lesbarkeit durch Menschen von Vorteil, sondern auch für Agent Assist-gestützte Workflows.

Wenn Entwickler KI-Agenten in ihren Workflow einbinden, müssen diese Agenten die Build-Konfiguration lesen und ändern können.

Sie haben jedoch keine Möglichkeit, die Nebenwirkungen einer Konfigurationsänderung vorherzusagen, ohne das Projekt tatsächlich zu erstellen.

Das Hinzufügen einer einzelnen Zeile zu einer Konfigurationsdatei kann zu Konflikten mit einer dynamisch berechneten Variablen an anderer Stelle im Projekt oder mit einem Konventions-Plug-in führen.

In Lightbuild ist die Konfiguration Ihres Projekts ein deterministischer, statischer Datengraph.

Das bedeutet, dass KI-Agenten diesen Graphen prüfen, die Modultopologie verstehen und sie mithilfe eines bekannten Schemas ändern können.

Ein Agent kann die Liste der Module, die Liste der Abhängigkeiten und ihre Versionen sehen, Abhängigkeiten aktualisieren oder sogar ein brandneues Funktionsmodul hinzufügen, indem er einfach strukturierte Daten liest und schreibt.

Die Konfiguration Ihres Projekts wird zu einem erstklassigen Bestandteil von KI-Agenten-gestützten Workflows.

Ein weiteres Detail, das ich an dieser Stelle hervorheben möchte, ist, dass Lightbuild kein Plug-in für ein Build-System ist, sondern eine Schnittstelle zur Build-Engine.

Die Version von Lightbuild, die wir heute als Vorabversion veröffentlichen, verwendet Gradle als Ausführungs-Engine.

Der Architekturansatz, den wir mit Lightbuild verfolgt haben, sorgt jedoch dafür, dass Android Studio, die IDE, das Projekt als Lightbuild-Projekt erkennt und behandelt.

Sehen wir uns nun die zweite Säule an, bei der es um die Produktivität und den Flow von Entwicklern geht: die schnelle IDE-Synchronisierung.

Auch wenn Entwickler KI-Agenten in ihren Workflow einbinden, bleibt Android Studio ein wichtiges Tool für interaktive Aufgaben, z. B. um Compose-UI-Vorschauen zu prüfen, Code im Debugger durchzugehen, um ein Problem zu untersuchen, oder die Leistung mit dem Profiler zu analysieren.

Da die Konfiguration Ihres Projekts ein deterministischer, statischer Datengraph ist, muss die IDE keine Skriptbewertungsphase durchlaufen oder Plug-in-Code ausführen, um Ihr Projekt zu verstehen.

Egal, ob Sie ein Projekt öffnen, eine Build-Datei bearbeiten oder zwischen Branches wechseln – die IDE kann diese Informationen schnell verarbeiten und Sie direkt zu Ihren Tools weiterleiten.

Einer der Gründe für diese Geschwindigkeit und Zuverlässigkeit ist die Art und Weise, wie Lightbuild mit Abhängigkeiten umgeht.

Wenn Sie eine Abhängigkeit deklarieren, muss das Build-System normalerweise einen Baum transitiver Abhängigkeiten durchlaufen, um Versionsinformationen zu erfassen und Konflikte zu lösen.

Wenn sich Ihre Abhängigkeiten in Lightbuild ändern, berechnet das Tool automatisch die transitiven Abhängigkeitsinformationen und schreibt sie in eine resolved.deps-Datei in jedem Modulverzeichnis.

Wenn das Projekt in Zukunft wieder geöffnet oder neu erstellt wird, müssen weder die IDE noch das Build-Tool diese transitiven Abhängigkeitsinformationen neu berechnen.

Wir empfehlen, diese Dateien in die Versionsverwaltung einzuchecken. Wenn Sie Änderungen zur Überprüfung an Ihre Teammitglieder senden, können diese dann erstens sehen, ob es Änderungen an den Informationen zu transitiven Abhängigkeiten gab, und zweitens müssen ihre Computer diese Informationen nicht neu berechnen.

Wenn Sie diese Informationen in die Versionsverwaltung einchecken, können Sie, Ihre Teammitglieder und Ihre CI/CD-Pipelines außerdem jedes Mal mit denselben Abhängigkeitsversionen arbeiten.

Wir freuen uns, Ihnen mitteilen zu können, dass Lightbuild als frühe Vorabversion in Android Studio Canary und auch über eigenständige CLI-Tools verfügbar ist.

Bitte beachten Sie, dass diese Version von Lightbuild experimentell ist und nicht alle Funktionen enthält, die Sie zum Erstellen und Verwalten einer Produktionsanwendung benötigen.

Verwenden Sie weiterhin AGP und Gradle für Ihre Produktionsanwendungen, während Sie Lightbuild in Demo- und experimentellen Projekten ausprobieren.

Sie können noch heute unter goo.gle/lightbuild loslegen. Wir freuen uns auf Ihr Feedback, damit wir das Produkt weiter verbessern können.

Jetzt übergebe ich an Scott, der Ihnen Lightbuild in Aktion zeigen wird.

Vielen Dank, Juan.

Mein Name ist Scott Myers.

Ich bin Android Developer Relations Engineer. Wir arbeiten schon seit einiger Zeit an Lightbuild und freuen uns, Ihnen heute zu zeigen, wie Sie es ausprobieren können.

Als Erstes rufen Sie den Link auf, den Juan erwähnt hat: goo.gle/lightbuild. Alternativ können Sie auch nach „Lightbuild“ suchen.

Sie sollten auf diese Dokumentationsseite gelangen, auf der alle Schritte aufgeführt sind, die Sie für den Einstieg benötigen, einschließlich der Installation einer Canary-Version von Android Studio. Denken Sie daran, dass sich diese Funktion noch in der Vorabversion befindet und noch nicht in der stabilen Version von Android Studio verfügbar ist.

Außerdem können Sie die Lightbuild-Befehlszeile installieren, um die Vorteile der agentischen Funktionen von Lightbuild voll auszuschöpfen.

Sobald Sie das eingerichtet haben, wie ich hier auf meinem Computer, habe ich die neueste Android Studio Canary-Version laufen.

Jetzt zeige ich Ihnen, wie Sie ein Lightbuild-Demoprojekt erstellen können. Das können Sie sogar heute noch tun.

Zuerst öffne ich den Assistenten für neue Projekte.

Ich wähle „Empty Activity“ (Leere Aktivität) aus und klicke auf „Next“ (Weiter).

Jetzt sehen Sie den normalen Bildschirm mit den Projektdetails, aber unten gibt es eine neue Option.

Unter „Build-Konfigurationssprache“ können Sie „Lightbuild“ auswählen.

Bevor Sie auf „Fertig“ klicken, werden Sie daran erinnert, dass es sich um eine experimentelle Funktion handelt.

Sie sehen sofort, dass unser Projekt mit der IDE synchronisiert ist und wir damit arbeiten können.

Sehen wir uns nun die Projektstruktur eines typischen Lightbuild-Projekts an.

Das ist die Standard-Android-Vorlage, die Sie erhalten, wenn Sie eine neue Anwendung erstellen.

Dort steht nur „Hello, world!“.

Das ist also ein einfacher Einstieg.

Auf der Stammebene unseres Projekts befindet sich eine Datei namens project.lightbuild.yaml.

Dadurch erhalten wir die globalen Einstellungen für unser gesamtes Projekt.

Sie können Ihrem Projekt einen Namen geben, alle Module in Ihrem Projekt auflisten, angeben, aus welchen externen Repositories Sie Ihre Abhängigkeiten beziehen, und dann die Versionen, die global auf die verschiedenen Teile Ihres Projekts angewendet werden.

Wir sehen, dass wir hier zwei Module haben: „app“ und „app-core“.

Das liegt daran, dass alle Lightbuild-Projekte mindestens zwei Module haben.

Das liegt daran, dass mindestens ein App-Modul und mindestens ein Bibliotheksmodul erforderlich sind.

Warum das so ist, erkläre ich gleich.

Sehen wir uns zuerst dieses App-Modul an.

Wenn ich es hier erweitere, sehen Sie, dass sich auf der Stammebene des Moduls eine lightbuild.yaml-Datei befindet, die jedes Modul hat.

Hier finden Sie einige grundlegende Informationen.

Wir arbeiten natürlich an der Android-Plattform.

Und dieses Modul ist vom Typ „application“.

Sie können Ihre SDK-Zielversionen, Ihre Anwendungs-ID usw. auflisten und dann alle Module, von denen dieses Anwendungsmodul abhängt.

Das Interessante an diesem Anwendungsmodul, das sich ein wenig von der Standard-Android-Vorlage unterscheidet, ist, dass sich im Quellordner nichts befindet.

In Lightbuild enthalten Anwendungsmodule also keinen Quellcode.

Der Grund dafür ist, dass sich dieses App-Modul nicht sehr oft ändert, aber einige Zeit für die Erstellung benötigt.

Wenn Sie also den gesamten Anwendungscode in Ihren Bibliotheksmodulen speichern, wird jeder Build schneller ausgeführt, da nicht alles im App-Modul neu berechnet und neu verpackt werden muss.

Sehen wir uns als Nächstes das Modul „app-core“ an, also das Bibliotheksmodul, von dem dieses Anwendungsmodul abhängt.

Und Sie können sehen, dass dieses Modul tatsächlich Quellcode enthält.

Hier befindet sich die Hauptlogik.

Dort steht nur „Hello, world!“.

Wenn ich mir die Datei lightbuild.yaml in diesem Modul ansehe, ist sie vom Typ „library“.

Hier werden auch einige SDK-Versionsnummern festgelegt, aber es werden alle externen Abhängigkeiten aufgeführt, die wir in diesem Modul haben.

Außerdem werden hier unsere Unit- und Instrumentierungstests deklariert.

Sehen wir uns als Nächstes eine andere Datei an, die Sie hier vielleicht bemerkt haben. Juan hat bereits ein wenig darüber gesprochen. In jedem Modul gibt es eine resolved.deps-Datei.

Diese Datei wird automatisch von Lightbuild generiert.

Sie sollten sie also nicht manuell bearbeiten. Sie enthält eine Liste aller aufgelösten Abhängigkeiten innerhalb dieses Moduls.

Alle Ihre Abhängigkeiten und transitiven Abhängigkeiten sind also bereits vorhanden.

Das bedeutet, dass Sie sich nicht darum kümmern müssen, wenn Ihre Anwendung in der IDE geöffnet wird oder wenn Sie einen Build erstellen, da dies bereits im Voraus erledigt und in Ihr Projekt eingecheckt wurde.

Sehen wir uns als Nächstes ein Beispiel dafür an, wie Lightbuild die Entwicklererfahrung bei der Projektsynchronisierung verbessert.

Ich bin jetzt wieder auf der Stammebene project.lightbuild.yaml, in den globalen Einstellungen, in denen alle Module meiner Anwendung aufgeführt sind.

Wenn Sie Konfigurations- oder Build-Konfigurationsdateien bearbeiten, wird normalerweise eine Schaltfläche für die Synchronisierung angezeigt. Es dauert dann eine Weile, bis alle diese Dateien verarbeitet sind, da die von Juan beschriebenen Prozesse ausgeführt werden müssen. Dabei wird ein Teil-Build erstellt, indem alle Build-Skripts ausgeführt werden, und dieses Modell wird dann mit der IDE synchronisiert.

Nehmen wir also eine ziemlich große Änderung an diesem kleinen Projekt vor.

Wir löschen einfach eines der Module.

Und Sie können sehen, dass dieses Modul, bevor ich auf die Schaltfläche „Speichern“ klicke, von der IDE erkannt wird, weil es hier fett formatiert ist.

Das Quellverzeichnis und die Testverzeichnisse wurden erkannt.

Sobald ich die Änderung gespeichert habe, ist das Modul sofort aus dem Projekt verschwunden.

Wenn ich die Änderung rückgängig mache und auf „Speichern“ klicke, ist sie genauso schnell wieder da.

Das ist ein Beispiel für die schnelle IDE-Synchronisierung, die Lightbuild für Ihre Projekte bietet.

Außerdem können Sie alle normalen Befehle verwenden, die Sie aus Android Studio kennen.

Klicken Sie auf die Schaltfläche „Ausführen“.

Ihre Anwendung wird kompiliert und hier ausgeführt.

Diese Demo-App ist nicht sehr groß, aber ich zoome heran, um zu zeigen, dass „Hello Android“ angezeigt wird.

Sie können Ihre Tests wie gewohnt ausführen, indem Sie die Testdatei aufrufen und sie wie hier gezeigt über den Bundsteg ausführen.

Im Hintergrund wird Lightbuild aufgerufen, um diese Tests auszuführen.

Das funktioniert also alles wie erwartet.

Als Nächstes möchte ich Ihnen zeigen, wie Sie Lightbuild verwenden, wenn Sie nicht Android Studio, sondern einen anderen agentischen Ablauf nutzen.

Dafür gibt es die Befehlszeile.

In der Befehlszeile für Lightbuild führe ich also einfach den grundlegenden Hilfebefehl aus.

Und ja, alle Tippfehler, die Sie heute in diesem Projekt sehen, sind von mir.

Lightbuild bietet verschiedene integrierte Befehle, wie… Oh, Entschuldigung, ich führe das außerhalb eines Projekts aus.

Das wird mir immer wieder angezeigt.

Ja, Live-Demo.

Bevor ich Lightbuild-Befehle ausführe, erstelle ich ein Lightbuild-Projekt.

Dafür verwende ich „android create“, unser Standard-Befehlszeilentool zum Erstellen neuer Projektvorlagen.

Ich verwende die Vorlage „empty-activity-lightbuild“, nenne meine App „Lightbuild Demo“ und speichere sie im Ausgabeverzeichnis „demo“.

Wenn ich jetzt in dieses Verzeichnis wechsle und „lightbuild -h“ eingebe, werden alle verfügbaren Lightbuild-Befehle angezeigt.

Wir haben also viele Dinge, die Sie erwarten würden: Erstellen, Bereinigen, Testen.

Aber es gibt auch ein paar neue.

Es gibt einen Auflösungsbefehl, der die Abhängigkeiten Ihres Projekts durchläuft und die zuvor gezeigten resolved.deps-Dateien generiert.

Mit dem Abfragebefehl können Sie und Ihre Kundenservicemitarbeiter die Struktur Ihres Projekts besser verstehen.

Zuerst zeige ich Ihnen den neuen Abfragebefehl.

Wenn ich mir die Struktur dieses Projekts über die Befehlszeile ansehe, ist sie dieselbe wie in der Android Studio-Demo.

Aber das sagt mir nicht viel darüber, wie mein Projekt aufgebaut ist.

Wenn ich also eine Lightbuild-Abfrage ausführe und mir beispielsweise dieses App-Modul ansehe, kann ich mit dieser speziellen Syntax sagen: „Zeige mir alles, was sich unter diesem App-Modul befindet.“

Und ich erhalte diese schöne Tabelle mit verschiedenen Zielen, die ich im App-Modul erstellen kann.

Sie enthält also die APKs und AABs für die Debug- und die Release-Binärdateien.

Wenn ich nur das App-Ziel ausführe, wird alles erstellt.

Außerdem gibt es eine Möglichkeit, die Ausgabe als JSON anzugeben.

Und so… Oh, Entschuldigung.

Auch hier sind alle meine Tippfehler heute echt.

Ich verwende die interaktive Lightbuild-Hilfe, um sicherzugehen, dass ich alles richtig mache.

Hm…

Ja, das sollte funktionieren.

Okay.

Wenn mir jemand sagen kann, was ich falsch mache, sprechen Sie mich nach diesem Vortrag an.

Anstelle dieser Tabelle können Sie Ihre Lightbuild-Befehle auch als JSON-Datei ausgeben, was für Ihre Agenten einfacher ist.

--format json…

Oh, Format.

Oh, tut mir leid.

Vielen Dank.

Dies ist Live-Feedback von Entwicklern.

Vielen Dank.

Okay, ja, und es gibt auch den Ausgabebefehl, den ich auch demonstrieren kann, vielleicht mit Ihrer Hilfe.

Wenn ich also die Dateien anstelle der Ziele ausgebe, werden mir die Speicherorte aller verschiedenen Binärdateien in meinem Build angezeigt.

So können Sie und Ihre Agenten Ihr Projekt über die Befehlszeile mit Lightbuild besser erkunden und verstehen.

Dann gibt es natürlich noch den Befehl lightbuild resolve, den ich bereits erwähnt habe und mit dem alle resolved.deps-Dateien generiert werden.

Diese Version bietet auch einige zusätzliche Funktionen.

Es gibt zum Beispiel den Parameter „locked dependencies“. Damit werden nicht nur diese Dateien generiert, sondern der Inhalt der Dateien wird mit den Abhängigkeiten verglichen, die Sie in Ihrer Build-Konfiguration deklariert haben.

Wenn es Unterschiede gibt, werden Sie darüber informiert und der Build schlägt fehl.

Diese Dateien mit aufgelösten Abhängigkeiten können also als Sperrdateien fungieren. Wenn Sie Ihre App beispielsweise in einem CI/CD-System für die Produktion erstellen, möchten Sie wissen, ob sich während dieses Builds Abhängigkeiten ändern.

Lightbuild hat auch eine integrierte Testfunktion. Sie können alle Tests in diesem Bibliotheksmodul auch direkt über die Befehlszeile ausführen.

Und ich möchte euch noch etwas zeigen.

Sie können auch die Hilfe aufrufen, um eine vollständige Liste aller Parameter und Unterbefehle zu erhalten, die Sie verwenden können.

Das ist für Ihren KI-Agenten verfügbar. Das ist also die Ausgabe für den KI-Agenten.

Okay.

Nachdem wir uns einige einfache Projekte mit Lightbuild angesehen haben, möchte ich Ihnen jetzt ein etwas anspruchsvolleres Projekt zeigen.

Das Android-Team stellt eine Beispiel-App namens „Now in Android“ zur Verfügung, die einige der neuesten Android-Funktionen enthält, zeigt, wie sie verwendet werden, und einige Best Practices vorstellt.

Es ist eine hochgradig modulare Anwendung.

Es ist in etwa 32 verschiedene Module unterteilt.

So sieht das in GitHub aus.

Ich wechsle jetzt zurück zu Android Studio, wo ich meinen Agenten bereits verwendet habe.

Ich habe Gemini Argon verwendet, um das Android-Projekt „Now in Android“ in Lightbuild zu konvertieren.

Das ist also nichts, was wir veröffentlicht haben, sondern etwas, das ich selbst gemacht habe.

Und Sie können sehen, dass dieses Projekt in meinem project.lightbuild.yaml zwar all diese verschiedenen Module hat, aber trotzdem unglaublich schnell geöffnet und mit dieser IDE synchronisiert wurde.

Ein weiterer wichtiger Punkt bei diesem Projekt ist, dass einige Build-Varianten oder spezielle Build-Konfigurationen verwendet wurden, um sowohl einen Demo-Build als auch einen Produktions-Build zu haben, die die App jeweils etwas anders präsentieren.

Die Demoversion verwendet integrierte Datenquellen, während die Produktionsversion tatsächlich Daten aus dem Netzwerk abruft.

Wenn Sie das mit Lightbuild tun möchten, müssen Sie in Ihr Anwendungsmodul gehen und angeben, dass dieses Anwendungsmodul beispielsweise die Demoanwendung ist. So werden Dinge wie verschiedene Build-Konfigurationen oder Produktvarianten gehandhabt.

Sie basiert also auf allen Kernkomponenten, ruft aber auch spezielle Einstellungen nur für die Demoversion der App ab.

So können Sie mehrere Anwendungsmodule haben.

Jede Variante kann beispielsweise eine kostenpflichtige oder kostenlose Version Ihrer App darstellen.

Und Sie profitieren weiterhin von den Vorteilen des Anwendungsmoduls, das eine leere Hülle ohne eigenen Code ist und viel schneller erstellt wird. Wenn sich Ihre Bibliotheken ändern, müssen nur diese neu kompiliert werden, um Ihre App neu zu erstellen.

Sehen wir uns an, ob die App „Now in Android“ mit Lightbuild und allen 32 Modulen erfolgreich erstellt wird.

Ja, da ist es.

Ich möchte darauf hinweisen, dass wir bei solchen Tests auch gelernt haben, dass Lightbuild nicht immer alle Build-Funktionen unterstützt, die Sie möglicherweise benötigen.

Die Android-App „Now in Android“ verwendet beispielsweise ein Hilt-Plug-in, um Hilt zu nutzen. Lightbuild unterstützt solche Plug-ins noch nicht.

Mein KI-Agent konnte eine Problemumgehung finden und die Hilt-Unterstützung einbinden, ohne den Code im Projekt selbst großartig zu ändern.

Der gesamte Code in all diesen Modulen ist mit dem ursprünglichen Repository identisch.

Aber das ist etwas, das Sie auf jeden Fall im Hinterkopf behalten sollten, wenn Sie selbst mit Lightbuild experimentieren und es vorführen: Nicht alles in Ihrem aktuellen Projekt wird in Bezug auf die Build-Konfiguration unterstützt.

Deshalb befindet sich Lightbuild noch in der Vorabversion und ist nur in Android Studio Canary verfügbar.

Und damit möchte ich zu den Folien zurückkehren.

Fassen wir noch einmal zusammen, worüber wir gesprochen haben: Lightbuild ist eine neue Build-Plattform für Android, die sich derzeit in der experimentellen Phase befindet.

Es hat eine deklarative Build-Konfiguration, sodass Sie keinen ausführbaren Code in Ihren Build-Konfigurationen ausführen. Das ermöglicht viele tolle Funktionen mit schneller IDE-Synchronisierung und effizienteren Builds.

Es bietet erstklassige Unterstützung für KI-Agenten und in der Befehlszeile alle Funktionen, die Sie mir heute gezeigt haben.

Wir laden Sie ein, es auszuprobieren und für Demo- und experimentelle Projekte zu verwenden.

Juan und ich sowie einige der Entwickler aus dem Team sind am Stand für agentische KI, um Ihre Fragen zu beantworten.

Vielen herzlichen Dank.