Build Android deklaratif yang siap untuk agen dengan Lightbuild

Halo semuanya.

Nama saya Juan Sebastian Oviedo.

Saya adalah product manager di tim Android Developer Experience.

Saya di sini bersama Scott, dan hari ini kami ingin menyampaikan kepada Anda gambaran awal Lightbuild, pengalaman build eksperimental baru untuk aplikasi Android.

Saya akan membahas konteks project ini, filosofi di baliknya, dan alasan kami yakin bahwa sekarang adalah waktu yang tepat untuk memikirkan kembali cara konfigurasi project Android.

Saya juga akan membahas bagaimana pendekatan baru ini mempersiapkan kita untuk masa depan pengembangan aplikasi Android.

Mari kita mulai dengan beberapa konteks tentang cara kerja saat ini.

Gradle dan skrip build imperatif memberi developer kemampuan untuk menentukan hampir semua hal tentang build mereka secara terprogram.

Misalnya, Anda dapat memiliki logika yang secara dinamis menghitung kode versi berdasarkan histori Git, atau menentukan tugas kustom yang mengubah aset.

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

    }

  }

}

Selain Gradle, ada AGP atau Plugin Android Gradle, yang menggunakan mesin tujuan umum Gradle dan menyesuaikannya dengan toolchain Android.

Bersama-sama, Gradle dan AGP membentuk sistem dinamis yang mendukung pengalaman konfigurasi build untuk jutaan aplikasi produksi saat ini.

Karena fleksibilitas ini, alat pengembangan kami beroperasi dalam siklus proses arsitektur tertentu.

Saat Anda membuka project, beralih cabang, atau mengedit file build, IDE harus memiliki peta yang jelas, pemahaman yang jelas tentang konfigurasi project Anda, sehingga dapat mendukung fitur seperti pelengkapan kode dan navigasi kode.

Karena file build ditulis dalam bahasa imperatif yang Turing-complete, satu-satunya cara umum bagi IDE untuk mengetahui konfigurasi adalah dengan menjalankan skrip build.

Selama sinkronisasi IDE, sistem build akan melalui fase konfigurasi.

Fase ini mengevaluasi skrip build, menjalankan logika plugin, dan membuat model project.

Tindakan ini akan menyelaraskan tampilan project Anda di Android Studio dengan konfigurasi project yang sebenarnya.

Sebagai developer, hal yang paling Anda pedulikan adalah menghadirkan aplikasi Android yang bagus dan menyediakannya bagi pengguna.

Namun, mengelola skrip build, terus mengupdate AGP, dan terus menyinkronkan project dengan IDE memerlukan waktu dan upaya.

Ada beberapa inisiatif di Google dan ekosistem yang lebih luas yang berupaya meningkatkan pengalaman developer di area ini.

Inisiatif seperti Gradle Deklaratif dan toolchain Kotlin bertujuan untuk mengganti skrip build yang dapat dieksekusi dengan konfigurasi build deklaratif.

Di Android Studio, kami memiliki Upgrade Assistant AGP, yang memandu Anda dalam melakukan perubahan yang diperlukan untuk beralih dari satu versi AGP ke versi lainnya.

Kami juga menyediakan keahlian upgrade yang dapat diinstal dan diikuti oleh agen untuk mengupgrade AGP.

Selain itu, kami berinvestasi di area seperti sinkronisasi bertahap dan sinkronisasi tangguh, sehingga developer memiliki pengalaman yang lebih baik saat menyinkronkan dan mengimpor project mereka.

Setiap upaya ini menargetkan bagian dari teka-teki sehingga developer dapat menghabiskan lebih banyak waktu untuk membuat aplikasi dan lebih sedikit waktu untuk membangun project, mengelola file build, dan menyinkronkan project.

Selain upaya ini, kami mengajukan pertanyaan yang lebih luas kepada diri kami sendiri.

Bagaimana jika kita menata ulang cara project dikonfigurasi dari awal?

Jika kita melihat cara aplikasi Android modern dirancang saat ini, kita akan melihat perubahan besar menuju modularisasi yang masif.

Code base besar sering kali memiliki puluhan, atau bahkan ratusan modul: modul UI, modul fitur, modul domain, dan modul data.

Meskipun aplikasi root terkadang memerlukan pengemasan kustom, sebagian besar modul library tersebut mengikuti pola berulang yang standar.

Mereka sebenarnya tidak perlu memiliki kode arbitrer yang dapat dieksekusi dalam file build mereka.

Yang mereka butuhkan hanyalah cara yang jelas untuk menyatakan struktur dan dependensinya.

Pengamatan tersebut mendorong kami untuk membuat Lightbuild.

Lightbuild bertumpu pada dua pilar.

Pertama, Gradle menggunakan sintaksis deklaratif untuk konfigurasi, sehingga memberikan pemisahan yang jelas antara konfigurasi build dan logika.

Kedua, fitur ini memberikan pengalaman sinkronisasi IDE yang cepat melalui resolusi dependensi di awal.

Kami akan membahas setiap pilar ini secara mendetail agar Anda dapat melihat pengaruhnya terhadap alur kerja harian Anda.

Mari kita mulai dengan pilar konfigurasi build deklaratif.

Lihat file di sisi kiri layar.

Ini mewakili konfigurasi untuk modul saat ini.

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

Karena file ini adalah kode yang dapat dieksekusi, file ini dapat memiliki definisi variabel lokal, panggilan ke fungsi bantuan kustom atau plugin konvensi, pernyataan bersyarat, dan definisi tugas inline.

Agar IDE mengetahui hasil konfigurasi ini, IDE harus menjalankan skrip.

Sekarang, lihat file di sisi kanan layar.

Ini adalah konfigurasi Lightbuild untuk modul serupa.

# 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

File ini murni berisi data deklaratif.

Tidak ada definisi variabel lokal, tidak ada panggilan ke fungsi bantuan kustom, dan tidak ada pernyataan bersyarat atau definisi tugas inline.

File ini dengan jelas menyatakan jenis modul, target SDK, dan dependensinya.

Jika engineer baru bergabung dengan tim Anda dan membuka file ini, dia tidak perlu menguraikan idiom build kustom, dan setiap modul Lightbuild di setiap project Lightbuild menggunakan bahasa yang sama dan langsung dapat dibaca.

Meskipun pemisahan antara konfigurasi dan logika sangat bagus untuk keterbacaan manusia, pemisahan ini bahkan lebih transformatif untuk alur kerja yang dibantu agen.

Saat developer mengadopsi agen sebagai bagian dari alur kerja mereka, agen tersebut harus dapat membaca dan mengubah konfigurasi build.

Namun, mereka tidak memiliki cara untuk memprediksi efek samping dari perubahan konfigurasi selain dengan benar-benar membangun project.

Menambahkan satu baris ke file konfigurasi dapat bertentangan dengan variabel yang dihitung secara dinamis di tempat lain dalam project atau dengan plugin konvensi.

Di Lightbuild, konfigurasi project Anda adalah grafik data statis yang deterministik.

Artinya, agen dapat memeriksa grafik tersebut, memahami topologi modul, dan mengubahnya menggunakan skema yang diketahui.

Agen dapat melihat daftar modul, daftar dependensi dan versinya, mengupdate dependensi, atau bahkan menambahkan modul fitur baru hanya dengan membaca dan menulis data terstruktur.

Hal ini menjadikan konfigurasi project Anda sebagai elemen utama untuk alur kerja yang dibantu agen.

Detail lain yang ingin kami soroti saat ini adalah fakta bahwa Lightbuild bukanlah plugin untuk sistem build, melainkan antarmuka ke mesin build.

Versi Lightbuild, pratinjau yang kami rilis hari ini, menggunakan Gradle di balik layar sebagai mesin eksekusinya.

Namun, pendekatan arsitektur yang kami ikuti dengan Lightbuild membuat Android Studio, IDE, melihat dan memperlakukan project sebagai project Lightbuild.

Sekarang mari kita bahas pilar kedua, yang membahas produktivitas dan alur developer: sinkronisasi IDE yang cepat.

Meskipun developer mengadopsi agen sebagai bagian dari alur kerja mereka, Android Studio tetap menjadi alat penting untuk tugas interaktif, misalnya, untuk meninjau pratinjau Compose UI atau untuk menelusuri kode di debugger sebagai bagian dari penyelidikan masalah, atau untuk menganalisis performa dengan profiler.

Karena konfigurasi project Anda adalah grafik data statis yang deterministik, IDE tidak perlu melalui fase evaluasi skrip atau menjalankan kode plugin untuk memahami project Anda.

Baik saat Anda membuka project, mengedit file build, atau beralih cabang, IDE dapat memproses informasi tersebut dengan cepat dan mengarahkan Anda langsung ke alat.

Salah satu alasan kecepatan dan keandalan ini dapat dicapai adalah cara Lightbuild menangani dependensi.

Biasanya, saat Anda mendeklarasikan dependensi, sistem build harus melalui hierarki dependensi transitif untuk mengumpulkan informasi versi dan menyelesaikan konflik.

Di Lightbuild, setiap kali dependensi Anda berubah, alat ini akan otomatis menghitung informasi dependensi transitif dan menulisnya ke file resolved.deps di dalam setiap direktori modul.

Hal ini membuat IDE atau alat build tidak perlu menghitung ulang informasi dependensi transitif tersebut saat project dibuka lagi di masa mendatang atau di-build ulang.

Sebaiknya periksa file ini ke dalam kontrol sumber sehingga saat Anda mengirim perubahan kepada rekan satu tim untuk ditinjau, mereka dapat, dua hal, mereka dapat melihat apakah ada perubahan pada informasi dependensi transitif, ditambah mesin mereka tidak perlu menghitung ulang informasi dependensi transitif tersebut.

Selain itu, dengan memeriksa informasi ini ke dalam kontrol sumber, Anda dapat memastikan bahwa Anda, rekan satu tim, dan pipeline CI/CD dapat membangun dengan versi dependensi yang sama setiap saat.

Dengan senang hati kami umumkan bahwa Lightbuild tersedia sebagai pratinjau awal di Android Studio Canary dan juga melalui alat CLI mandiri.

Perlu diingat bahwa versi Lightbuild ini bersifat eksperimental, sehingga tidak memiliki semua fitur yang Anda perlukan untuk membangun dan mengelola aplikasi produksi.

Terus gunakan AGP dan Gradle untuk aplikasi produksi Anda sambil mencoba Lightbuild dalam project demo dan eksperimental.

Anda dapat memulai sekarang dengan membuka goo.gle/lightbuild, dan kami menantikan masukan Anda untuk membantu kami membentuk produk ini seiring perkembangannya.

Sekarang, saya akan menyerahkan presentasi kepada Scott agar dia dapat menunjukkan cara kerja Lightbuild.

Terima kasih, Juan.

Nama saya Scott Myers.

Saya adalah Android Developer Relations Engineer. Kami telah mengerjakan Lightbuild selama beberapa waktu dan kami sangat senang dapat menunjukkan cara Anda dapat mencobanya dan menggunakannya sekarang.

Jadi, hal pertama yang perlu Anda lakukan adalah membuka link yang disebutkan Juan, goo.gle/lightbuild, atau cukup telusuri Lightbuild.

Anda akan diarahkan ke halaman dokumentasi ini yang berisi semua langkah yang diperlukan untuk memulai, termasuk menginstal Android Studio versi Canary, karena ingat, fitur ini masih dalam pratinjau, belum ada di Android Studio versi stabil.

Selain itu, ada Lightbuild CLI yang dapat Anda instal untuk mendapatkan manfaat penuh dari pengalaman agentic dengan Lightbuild.

Jadi, setelah Anda menyiapkannya, seperti yang saya lakukan di komputer saya, saya menjalankan Android Studio Canary terbaru.

Sekarang, saya akan membahas langkah-langkah membuat project Lightbuild demo dan menunjukkan cara melakukannya, bahkan hari ini.

Jadi, pertama-tama, saya akan membuka wizard New Project.

Saya akan memilih Empty Activity, lalu klik Next.

Sekarang Anda akan melihat bahwa ini adalah layar detail project yang normal, tetapi di bagian bawah, ada opsi baru.

Di bagian bahasa konfigurasi build, Anda dapat memilih Lightbuild.

Dan Anda akan diingatkan bahwa ini adalah eksperimental sebelum Anda menekan Selesai.

Anda akan langsung melihat bahwa project kita disinkronkan dengan IDE dan aktif, siap untuk kita gunakan.

Sekarang, mari kita lihat struktur project Lightbuild standar.

Jadi, ini hanyalah template Android default yang Anda dapatkan saat membuat aplikasi baru.

Hanya menampilkan, "Halo dunia!"

Jadi, ini adalah cara yang mudah untuk memulai.

Anda akan melihat bahwa di tingkat root project ini, ada file bernama project.lightbuild.yaml.

Tindakan ini akan memberi kita setelan global untuk seluruh project.

Jadi, Anda dapat memberi nama project, mencantumkan semua modul dalam project, menyebutkan repositori eksternal tempat Anda mengambil dependensi, lalu versi yang diterapkan secara global, ke berbagai bagian project Anda di sini.

Jadi, kita melihat bahwa kita memiliki dua modul di sini, app dan app-core.

Hal ini karena semua project Lightbuild memiliki setidaknya dua modul.

Hal ini karena diperlukan setidaknya satu modul aplikasi dan setidaknya satu modul library.

Dan kita akan membahas alasannya sebentar lagi.

Jadi, pertama-tama mari kita lihat modul aplikasi ini.

Jika saya meluaskannya di sini, Anda akan melihat bahwa di level root modul, ada file lightbuild.yaml, yang akan dimiliki setiap modul.

Di sini, ada beberapa informasi dasar.

Kami sedang mengerjakan platform Android, tentu saja.

Dan modul ini berjenis aplikasi.

Anda dapat mencantumkan versi target SDK, ID aplikasi, dan sebagainya, lalu mencantumkan semua modul yang menjadi dependensi modul aplikasi ini.

Hal menarik dari modul aplikasi ini yang sedikit berbeda dari template Android standar adalah tidak ada apa pun di folder sumber.

Jadi, di Lightbuild, modul aplikasi tidak berisi kode sumber apa pun.

Alasannya adalah modul aplikasi ini tidak akan sering berubah, tetapi memerlukan waktu untuk di-build.

Jadi, jika Anda menyimpan semua kode aplikasi dalam modul library, setiap build akan berjalan lebih cepat karena tidak perlu menghitung ulang dan mengemas ulang semuanya dalam modul aplikasi.

Jadi, selanjutnya mari kita lihat modul app-core, yang merupakan modul library yang menjadi dependensi modul aplikasi ini.

Seperti yang terlihat, modul ini memiliki kode sumber di dalamnya.

Di sini ada logika utama kita.

Hanya menampilkan, "Halo dunia!"

Dan jika saya melihat file lightbuild.yaml dalam modul ini, Anda dapat melihat bahwa file tersebut berjenis library.

Di sini, file ini juga menetapkan beberapa nomor versi SDK, tetapi mencantumkan semua dependensi eksternal yang kita miliki, dalam modul ini.

Dan juga mendeklarasikan pengujian unit dan uji instrumentasi kita.

Selanjutnya, mari kita lihat file lain yang mungkin Anda perhatikan di sini, dan Juan telah membahasnya sedikit, ada file resolved.deps di dalam setiap modul.

Dan ini adalah file yang dibuat secara otomatis oleh Lightbuild.

Jadi, artinya Anda tidak boleh mengeditnya secara manual, tetapi file ini akan berisi daftar semua dependensi yang diselesaikan dalam modul ini.

Jadi, semua dependensi dan dependensi transitif Anda sudah ada di sini.

Jadi, artinya saat aplikasi Anda dibuka di IDE atau saat Anda akan membuat build, Anda tidak perlu memikirkan hal ini pada saat itu karena hal ini sudah dipikirkan sebelumnya dan diperiksa ke dalam project Anda.

Selanjutnya, mari kita lihat contoh bagaimana Lightbuild benar-benar meningkatkan pengalaman developer dengan sinkronisasi project.

Jadi, sekarang saya kembali ke level root project.lightbuild.yaml, setelan global di sini yang mencantumkan semua modul dalam aplikasi saya.

Dan biasanya, saat Anda mengedit file konfigurasi atau konfigurasi build, Anda akan melihat tombol sinkronisasi yang muncul dan memerlukan waktu untuk memproses semuanya karena proses yang dijelaskan Juan, yaitu harus melakukan build parsial dengan mengeksekusi semua skrip build Anda, lalu menyinkronkan model tersebut dengan IDE.

Jadi, mari kita lakukan perubahan yang cukup besar untuk project kecil ini.

Kita hanya akan menghapus salah satu modul.

Dan Anda dapat melihat bahwa modul ini, sebelum saya menekan tombol simpan, dikenali oleh IDE karena Anda dapat melihat bahwa modul ini dicetak tebal di sini.

Android Studio mengenali direktori sumber dan direktori pengujian.

Dan begitu saya menekan simpan, setelah saya membuat perubahan itu, Anda dapat melihat bahwa modul ini langsung hilang dari project.

Dan jika saya mengurungkan perubahan itu lagi dan menekan simpan, perubahan tersebut akan kembali dengan cepat.

Jadi, ini adalah contoh sinkronisasi IDE cepat yang dihadirkan Lightbuild ke project Anda.

Selain itu, Anda dapat melakukan semua perintah normal yang biasa Anda gunakan di Android Studio.

Anda dapat menekan tombol run.

Alat ini akan mengompilasi aplikasi Anda dan menjalankannya di sini.

Aplikasi demo ini tidak terlalu besar, tetapi saya akan memperbesarnya untuk menunjukkan bahwa aplikasi ini menampilkan teks "Hello Android".

Anda dapat menjalankan pengujian seperti biasa dengan membuka file pengujian, lalu menjalankannya dari gutter seperti ini.

Dan sebenarnya, Lightbuild dipanggil di balik layar untuk menjalankan pengujian ini.

Jadi, semua ini berfungsi seperti yang Anda harapkan.

Namun, selanjutnya saya ingin menunjukkan cara menggunakan Lightbuild jika Anda tidak menggunakan Android Studio, jika Anda menggunakan alur agentic lainnya.

Untuk itu, kita memiliki command line.

Jadi, di CLI untuk Lightbuild, saya hanya akan menjalankan perintah bantuan dasar.

Dan ya, semua kesalahan ketik yang Anda lihat dalam project ini hari ini adalah kesalahan saya.

Jadi, Lightbuild akan memiliki beberapa perintah berbeda yang disertakan di dalamnya seperti Oh, maaf, saya menjalankan ini di luar project.

Asisten terus memberi tahu saya hal itu.

Ya, demo langsung.

Jadi, pertama-tama, sebelum menjalankan perintah Lightbuild, saya akan membuat project Lightbuild.

Untuk itu, saya akan menggunakan android create, yang merupakan alat command line standar kami untuk membuat template project baru.

Saya akan menggunakan template empty-activity-lightbuild dan memberi nama aplikasi saya, Lightbuild Demo, lalu menempatkannya di direktori output demo.

Oke, sekarang jika saya masuk ke direktori tersebut dan mengetik lightbuild -h, saya akan melihat semua perintah berbeda yang tersedia di Lightbuild.

Jadi, kami memiliki banyak hal yang Anda harapkan: build, clean, test.

Namun, ada beberapa fitur baru.

Ada perintah resolve, yang sebenarnya menjalankan dependensi project Anda dan menghasilkan file resolved.deps yang saya tunjukkan sebelumnya.

Ada juga perintah kueri, yang memungkinkan Anda dan agen Anda memahami struktur project dengan lebih baik.

Jadi, pertama-tama, mari kita lihat perintah kueri baru tersebut.

Jadi, jika saya hanya melihat struktur project ini menggunakan command line, strukturnya sama dengan yang saya miliki di demo Android Studio.

Namun, hal ini tidak memberi tahu saya banyak hal tentang tata letak project saya.

Jadi, jika saya menjalankan kueri lightbuild, dan saya melihat, misalnya, modul aplikasi ini, dan saya akan menggunakan sintaksis khusus ini untuk mengatakan, "Tunjukkan semua yang ada di bawah modul aplikasi ini."

Dan memberi saya tabel bagus berisi berbagai target yang dapat saya build dalam modul aplikasi.

Jadi, aplikasi ini memiliki APK dan AAB untuk biner debug dan rilis.

Dan jika saya hanya menjalankan target aplikasi, semuanya akan di-build.

Ada juga cara untuk menentukan output sebagai JSON.

Jadi, dengan begitu, Oh, maaf.

Sekali lagi, semua kesalahan ketik saya hari ini benar-benar terjadi.

Saya akan menggunakan bantuan lightbuild interaktif untuk memastikan saya melakukannya dengan benar.

Hah…

Ya, seharusnya sudah berfungsi.

Oke.

Nah, jika ada yang bisa memberi tahu saya apa yang salah, bicaralah dengan saya setelah presentasi ini.

Namun, selain tabel ini, Anda juga dapat menghasilkan perintah Lightbuild sebagai JSON, yang lebih mudah bagi agen Anda.

--format json…

Oh, format.

Oh, maaf.

Terima kasih.

Ini adalah masukan developer langsung.

Terima kasih.

Oke, ya, dan ada juga perintah output yang juga bisa saya demokan, mungkin dengan bantuan Anda.

Jadi, jika saya menampilkan file, bukan target, tindakan ini akan menampilkan lokasi semua biner yang berbeda dalam build saya.

Jadi, ini hanyalah cara bagi Anda dan agen Anda untuk dapat menjelajahi dan memahami project Anda dengan lebih baik dari command line menggunakan Lightbuild.

Kemudian, tentu saja, ada perintah lightbuild resolve yang saya sebutkan sebelumnya, yang akan menghasilkan semua file resolved.deps Anda.

Sistem itu juga memiliki beberapa fitur tambahan.

Misalnya, ada parameter dependensi terkunci ini, dan dengan parameter tersebut, alih-alih hanya membuat file ini, parameter ini sebenarnya hanya akan membandingkan konten file dengan dependensi yang telah Anda deklarasikan dalam konfigurasi build.

Jika ada perbedaan, alat ini akan memberi tahu Anda, dan menggagalkan build.

Jadi, dengan cara itu, file dependensi yang di-resolve ini dapat bertindak sebagai file kunci, misalnya, jika Anda mem-build aplikasi dalam sistem CI/CD untuk produksi, Anda akan ingin mengetahui apakah ada dependensi yang berubah selama build tersebut.

Selain itu, Lightbuild memiliki fitur pengujian bawaan, dan Anda juga dapat menjalankan semua pengujian di modul library ini, misalnya, langsung dari command line.

Dan ada satu hal lagi yang ingin saya tunjukkan.

Hanya saja, alat ini juga memiliki bantuan yang akan memberi Anda daftar yang sangat lengkap tentang semua pembuatan semua parameter dan subperintah yang dapat Anda gunakan.

yang tersedia untuk agen Anda, jadi ini adalah output untuk agen tersebut.

Oke.

Jadi, setelah kita melihat beberapa project sederhana dengan Lightbuild, saya ingin menunjukkan seperti apa project yang sedikit lebih ambisius.

Jadi, kami memiliki aplikasi contoh yang disediakan oleh tim Android bernama Now in Android yang memberi Anda beberapa fitur Android terbaru, menunjukkan cara menggunakannya, dan menunjukkan beberapa praktik terbaik.

Aplikasi ini sangat modular.

Kursus ini dibagi menjadi sekitar 32 modul yang berbeda.

Jadi, seperti inilah tampilannya di GitHub.

Namun, saya akan beralih kembali ke Android Studio, tempat saya telah menggunakan agen saya sebelumnya.

Saya menggunakan Gemini Argon untuk mengonversi project Now in Android ke Lightbuild.

Jadi, ini bukan sesuatu yang kami publikasikan, ini hanya sesuatu yang saya lakukan sendiri.

Dan Anda dapat melihat bahwa meskipun project ini di project.lightbuild.yaml saya memiliki semua modul yang berbeda ini, project ini masih terbuka dengan sangat cepat, dan disinkronkan dengan IDE ini dengan cara yang sangat cepat.

Hal lain yang perlu Anda perhatikan tentang project khusus ini adalah bahwa project ini menggunakan beberapa ragam build, atau konfigurasi build khusus, agar memiliki build demo dan build prod, yang masing-masing memiliki cara yang sedikit berbeda dalam menyajikan aplikasi.

Versi demo akan menggunakan sumber data bawaan, dan versi produksi akan benar-benar mengakses jaringan dan mengambil data.

Jadi, untuk melakukannya dengan Lightbuild, cara menangani hal-hal seperti konfigurasi build atau ragam produk yang berbeda adalah dengan membuka modul aplikasi, dan menentukan bahwa modul aplikasi ini, misalnya, adalah aplikasi demo.

Jadi, varian ini akan mengandalkan semua komponen inti, tetapi juga mengambil setelan khusus hanya untuk versi demo aplikasi.

Jadi, dengan cara ini, Anda dapat memiliki beberapa modul aplikasi.

Setiap ragam produk dapat merepresentasikan, misalnya, versi berbayar atau gratis dari aplikasi Anda.

Anda tetap mendapatkan manfaat dari modul aplikasi yang berupa shell kosong tanpa kode di dalamnya yang di-build jauh lebih cepat, dan setiap kali library Anda berubah, hanya library tersebut yang perlu dikompilasi ulang untuk mem-build aplikasi Anda lagi.

Mari kita lihat apakah aplikasi Now in Android ini berhasil di-build dengan Lightbuild beserta 32 modulnya yang berbeda.

Ya, itu dia.

Dan kami ingin menunjukkan bahwa hal lain yang kami pelajari dari melakukan eksperimen seperti ini adalah Lightbuild tidak selalu mendukung setiap fitur build yang mungkin Anda perlukan.

Misalnya, aplikasi Now in Android mengandalkan plugin Hilt untuk menggunakan Hilt, dan Lightbuild belum mendukung hal semacam itu.

Jadi, agen saya dapat menemukan solusi untuk masalah tersebut, dan tetap mendapatkan dukungan Hilt tanpa benar-benar mengubah banyak kode dalam project itu sendiri.

Semua kode di semua modul ini sama dengan repositori aslinya.

Namun, hal itu harus-- harus diingat saat Anda bereksperimen dan mendemokan Lightbuild sendiri, yaitu tidak semua hal dalam project Anda saat ini akan didukung dalam hal konfigurasi build.

Jadi, itulah alasan Lightbuild masih dalam versi pratinjau, masih di Android Studio Canary.

Sekarang, mari kita kembali ke slide.

Dan ya, untuk menyimpulkan semua yang kita bicarakan di sini, ingatlah Lightbuild, platform build baru untuk Android, yang saat ini masih bersifat eksperimental.

Bazel memiliki konfigurasi build deklaratif, sehingga Anda tidak menjalankan kode yang dapat dieksekusi dalam konfigurasi build, dan hal ini membuka banyak fitur hebat dengan sinkronisasi IDE yang cepat dan build yang lebih efisien.

IDE ini memiliki dukungan agen AI kelas satu, di command line, dan memiliki semua fitur yang Anda bantu demokan hari ini.

Jadi, kami mengundang Anda untuk mencoba dan menggunakannya untuk project demo dan eksperimental.

Juan dan saya, serta beberapa engineer di tim, juga akan berada di stan Agentic AI untuk menjawab pertanyaan Anda.

Jadi, terima kasih banyak.