Lightbuild を使用した宣言型の、エージェント対応の Android ビルド

皆さん、こんにちは。

私の名前は Juan Sebastian Oviedo です。

私は Android デベロッパー エクスペリエンス チームのプロダクト マネージャーです。

本日は Scott とともに、Android アプリ向けの新しい試験運用版ビルド エクスペリエンスである Lightbuild の早期プレビューをご紹介します。

このプロジェクトの背景、その背後にある理念、そして今が Android プロジェクトの構成方法を再考する適切なタイミングであると考える理由について説明します。

また、この新しいアプローチが Android アプリ開発の未来をどのように形作るかについても説明します。

まず、現在の状況について説明します。

Gradle と命令型ビルド スクリプトを使用すると、デベロッパーはビルドに関するほぼすべてのことをプログラムで定義できます。

たとえば、Git の履歴に基づいてバージョン コードを動的に計算するロジックを記述したり、アセットを変換するカスタムタスクを定義したりできます。

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

    }

  }

}

Gradle とともに、AGP（Android Gradle プラグイン）があります。これは、Gradle の汎用エンジンを Android ツールチェーンに適応させるものです。

Gradle と AGP は、現在、何百万もの本番環境アプリのビルド構成エクスペリエンスを支える動的なシステムを形成しています。

この柔軟性により、Google のデベロッパー ツールは特定のアーキテクチャ ライフサイクル内で動作します。

プロジェクトを開く、ブランチを切り替える、ビルドファイルを編集するなどの操作を行う際、IDE はプロジェクト構成を明確に把握している必要があります。そうすることで、コード補完やコード ナビゲーションなどの機能を提供できるようになります。

ビルドファイルは、命令型のチューリング完全な言語で記述されているため、IDE が構成を把握する唯一の一般的な方法は、ビルド スクリプトを実行することです。

IDE の同期中、ビルドシステムは構成フェーズに入ります。

ビルド スクリプトを評価し、プラグイン ロジックを実行して、プロジェクト モデルを構築します。

これにより、Android Studio のプロジェクト ビューが実際のプロジェクト構成と一致するようになります。

デベロッパーにとって最も重要なことは、優れた Android アプリを開発してユーザーに提供することです。

しかし、ビルド スクリプトの管理、AGP の最新状態の維持、IDE とのプロジェクトの同期には、時間と労力がかかります。

この分野におけるデベロッパー エクスペリエンスを改善するために、Google とより広範なエコシステムの両方でいくつかの取り組みが行われています。

Declarative Gradle や Kotlin ツールチェーンなどのイニシアチブは、実行可能なビルド スクリプトを宣言型のビルド構成に置き換えることを目的としています。

Android Studio には AGP Upgrade Assistant があり、AGP のバージョンをアップグレードするために必要な変更をガイドします。

また、エージェントがインストールして AGP をアップグレードできるアップグレード スキルも提供しています。

さらに、段階的な同期や復元力のある同期などの分野に投資することで、デベロッパーがプロジェクトを同期してインポートする際のエクスペリエンスを向上させています。

これらの取り組みはそれぞれ、パズルのピースをターゲットにしています。これにより、デベロッパーはアプリの作成に多くの時間を費やし、プロジェクトのビルド、ビルドファイルの管理、プロジェクトの同期に費やす時間を減らすことができます。

この取り組みと並行して、私たちはより広範な疑問を抱きました。

プロジェクトの構成方法を根本から見直したらどうなるでしょうか。

現在の最新の Android アプリのアーキテクチャを見ると、大幅なモジュール化への大きなシフトが見られます。

大規模なコードベースには、UI モジュール、機能モジュール、ドメイン モジュール、データ モジュールなど、数十から数百のモジュールが含まれていることがよくあります。

ルート アプリケーションではカスタム パッケージが必要になることもありますが、ライブラリ モジュールの大部分は標準化された反復可能なパターンに従います。

ビルドファイルに任意の実行可能コードを実際に含める必要はありません。

必要なのは、構造と依存関係を明確に記述する方法だけです。

この観察から、Lightbuild の開発に至りました。

Lightbuild は 2 つの柱を基盤としています。

まず、構成に宣言型構文を使用することで、ビルド構成とロジックを明確に分離します。

2 つ目は、依存関係を事前に解決することで、IDE の同期を高速化することです。

これらの柱が日々のワークフローにどのように影響するかを理解できるように、それぞれの柱について詳しく説明します。

まず、宣言型ビルド構成の柱から見ていきましょう。

画面の左側にあるファイルをご覧ください。

これは、現在のモジュールの構成を表します。

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

このファイルは実行可能コードであるため、ローカル変数の定義、カスタム ヘルパー関数または規則プラグインの呼び出し、条件文、インライン タスク定義を含めることができます。

IDE がこの構成の解決先を認識するには、実際にスクリプトを実行する必要があります。

次に、画面の右側にあるファイルを見てみましょう。

これは、同様のモジュールの Lightbuild 構成です。

# 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

このファイルは純粋に宣言型のデータです。

ローカル変数の定義、カスタム ヘルパー関数の呼び出し、条件文、インライン タスク定義はありません。

モジュールのタイプ、SDK ターゲット、依存関係が明確に記述されています。

新しいエンジニアがチームに加わり、このファイルを開いた場合、解読が必要なカスタムビルド イディオムはなく、すべての Lightbuild プロジェクトのすべての Lightbuild モジュールで、すぐに読み取れる同じ言語が使用されます。

構成とロジックの分離は、人間にとっての読みやすさの向上に役立ちますが、Agent Assist ワークフローにとってはさらに大きな変革をもたらします。

開発者がワークフローの一部としてエージェントを採用する際、それらのエージェントはビルド構成を読み取り、変更できる必要があります。

しかし、実際にプロジェクトをビルドする以外に、構成変更の副作用を予測する方法はありません。

構成ファイルに 1 行追加すると、プロジェクト内の別の場所で動的に計算された変数や、規則プラグインと競合する可能性があります。

Lightbuild では、プロジェクトの構成は決定的で静的なデータグラフです。

つまり、エージェントはそのグラフを検査し、モジュールのトポロジを理解して、既知のスキーマを使用して変更できます。

エージェントは、構造化データの読み取りと書き込みを行うだけで、モジュールのリスト、依存関係とそのバージョンのリストを確認したり、依存関係を更新したり、新しい機能モジュールを追加したりできます。

これにより、プロジェクトの構成がエージェント支援ワークフローの主要な要素になります。

ここで強調しておきたいもう一つの点は、Lightbuild はビルドシステムのプラグインではなく、ビルドエンジンへのインターフェースであるということです。

本日リリースする Lightbuild のプレビュー版では、実行エンジンとして Gradle が内部で使用されています。

しかし、Lightbuild で採用したアーキテクチャ アプローチにより、IDE である Android Studio はプロジェクトを Lightbuild プロジェクトとして認識し、処理します。

次に、2 つ目の柱である、デベロッパーの生産性とフロー、つまり高速な IDE 同期について説明します。

デベロッパーがワークフローの一部としてエージェントを採用している場合でも、Android Studio はインタラクティブなタスクに不可欠なツールです。たとえば、Compose UI プレビューの確認、問題の調査の一環としてデバッガでコードをステップ実行する、プロファイラでパフォーマンスを分析するなどのタスクです。

プロジェクトの構成は、決定論的な静的データグラフであるため、IDE はプロジェクトを理解するためにスクリプト評価フェーズを実行したり、プラグイン コードを実行したりする必要がありません。

プロジェクトを開く、ビルドファイルを編集する、ブランチを切り替えるなど、IDE はその情報を迅速に処理し、すぐにツールにアクセスできるようにします。

この速度と信頼性を実現できる理由の一つは、Lightbuild が依存関係を処理する方法にあります。

通常、依存関係を宣言すると、ビルドシステムは推移的依存関係のツリーを走査してバージョン情報を収集し、競合を解決する必要があります。

Lightbuild では、依存関係が変更されるたびに、ツールが推移的依存関係情報を自動的に計算し、各モジュール ディレクトリ内の resolved.deps ファイルに書き込みます。

これにより、将来プロジェクトを再度開いたときや、プロジェクトを再ビルドしたときに、IDE やビルドツールが推移的依存関係情報を再計算する必要がなくなります。

これらのファイルをソース管理にチェックインすることをおすすめします。そうすれば、変更をチームメイトに送信してレビューしてもらうときに、チームメイトは推移的依存関係情報に変更があったかどうかを確認できます。また、チームメイトのマシンで推移的依存関係情報を再計算する必要がなくなります。

さらに、この情報をソース管理にチェックインすることで、自分、チームメイト、CI / CD パイプラインが、毎回同じ依存関係バージョンでビルドできるようになります。

このたび、Lightbuild の早期プレビュー版が Android Studio Canary とスタンドアロン CLI ツールで利用可能になりました。

このバージョンの Lightbuild は試験運用版であるため、本番環境アプリケーションのビルドとメンテナンスに必要な機能がすべて揃っているわけではありません。

本番環境のアプリケーションでは引き続き AGP と Gradle を使用し、デモ プロジェクトや試験運用プロジェクトで Lightbuild をお試しください。

Lightbuild は、goo.gle/lightbuild から今すぐお試しいただけます。皆様からのフィードバックをお待ちしております。

ここからは、スコットにプレゼンテーションをバトンタッチして、Lightbuild の実際の動作を見せてもらいます。

Juan さん、ありがとうございます。

Scott Myers と申します。

私は Android デベロッパー リレーションズ エンジニアです。私たちはしばらくの間 Lightbuild に取り組んできました。本日、実際に Lightbuild をお試しいただけることを嬉しく思います。

まず、Juan が言及したリンク（goo.gle/lightbuild）にアクセスするか、Lightbuild を検索してください。

このドキュメント ページには、Android Studio の Canary バージョンのインストールなど、開始に必要なすべての手順が記載されています。これはまだプレビュー版であり、Android Studio の安定版には含まれていないことに注意してください。

また、Lightbuild CLI をインストールすると、Lightbuild のエージェント型エクスペリエンスを最大限に活用できます。

セットアップが完了したら、私のマシンと同じように、最新の Android Studio Canary を実行します。

次に、デモ用の Lightbuild プロジェクトを実際に作成する手順を説明します。今日からでも実践できる方法です。

まず、[New Project] ウィザードに移動します。

[Empty Activity] を選択して [Next] をクリックします。

これは通常のプロジェクト詳細画面ですが、下部に新しいオプションが表示されています。

ビルド構成言語で Lightbuild を選択できます。

[完了] をクリックする前に、これが試験運用版であることを示すメッセージが表示されます。

すると、プロジェクトが IDE と同期され、すぐに実行できるようになります。

次に、一般的な Lightbuild プロジェクトのプロジェクト構造を見てみましょう。

これは、新しいアプリケーションを作成するときに取得するデフォルトの Android テンプレートです。

「Hello, world!」と表示されるだけです。

簡単に始められる方法です。

プロジェクトのルートレベルに project.lightbuild.yaml というファイルがあることがわかります。

これにより、プロジェクト全体のグローバル設定が提供されます。

プロジェクトに名前を付け、プロジェクト内のすべてのモジュールをリストし、依存関係を pull する外部リポジトリを指定して、プロジェクトのさまざまな部分にグローバルに適用されるバージョンをここで指定できます。

ここでは、app と app-core の 2 つのモジュールがあることがわかります。

これは、すべての Lightbuild プロジェクトに少なくとも 2 つのモジュールがあるためです。

これは、少なくとも 1 つのアプリ モジュールと少なくとも 1 つのライブラリ モジュールが必要であるためです。

その理由については後ほど説明します。

まず、このアプリ モジュールを見てみましょう。

ここで展開すると、モジュールのルートレベルに lightbuild.yaml ファイルがあることがわかります。これはすべてのモジュールにあります。

ここには、いくつかの基本情報があります。

もちろん、Android プラットフォームにも取り組んでいます。

このモジュールのタイプは application です。

SDK のターゲット バージョンやアプリケーション ID などをリストアップし、このアプリケーション モジュールが依存するすべてのモジュールをリストアップします。

このアプリケーション モジュールで興味深いのは、標準の Android テンプレートとは少し異なり、ソースフォルダに何も入っていないことです。

そのため、Lightbuild では、アプリケーション モジュールにソースコードは含まれません。

その理由は、このアプリ モジュールはあまり頻繁に変更されないものの、ビルドに時間がかかるためです。

そのため、すべてのアプリケーション コードをライブラリ モジュール内に保持すると、アプリ モジュール内のすべてを再計算して再パッケージ化する必要がなくなるため、各ビルドが高速になります。

次に、このアプリ モジュールが依存しているライブラリ モジュールである app-core モジュールを見てみましょう。

このモジュールには実際にソースコードが含まれていることがわかります。

ここにメインロジックがあります。

「Hello, world!」と表示されるだけです。

このモジュールの lightbuild.yaml ファイルを見ると、タイプがライブラリであることがわかります。

また、SDK のバージョン番号も設定されていますが、このモジュール内にある外部依存関係がすべてリストされています。

また、単体テストとインストルメンテーション テストも宣言しています。

次に、ここにある別のファイルを見てみましょう。Juan が少し触れていましたが、すべてのモジュール内に resolved.deps ファイルがあります。

これは Lightbuild によって自動的に生成されるファイルです。

つまり、手動で編集する必要はありませんが、このモジュール内で解決されたすべての依存関係のリストが含まれます。

つまり、すべての依存関係と推移的な依存関係がすでにここにあります。

つまり、IDE でアプリケーションを開いたときや、ビルドを作成するときに、このことを把握する必要はありません。事前に把握され、プロジェクトにチェックインされているためです。

次に、Lightbuild がプロジェクトの同期によってデベロッパー エクスペリエンスを実際にどのように改善するかの例を見てみましょう。

ルートレベルの project.lightbuild.yaml に戻りました。ここには、アプリケーション内のすべてのモジュールを一覧表示するグローバル設定があります。

通常、構成ファイルやビルド構成ファイルを編集しているときに、同期ボタンが表示されることがあります。このボタンを押すと、すべての処理が完了するまでに時間がかかります。これは、Juan が説明したように、すべてのビルド スクリプトを実行して部分的なビルドを行い、そのモデルを IDE と同期する必要があるためです。

この小さなプロジェクトに、かなり大きな変更を加えてみましょう。

モジュールの 1 つを削除します。

このモジュールは、保存ボタンを押す前に IDE によって認識されています。これは、ここで太字になっていることからわかります。

ソース ディレクトリとテスト ディレクトリが認識されています。

変更を加えて保存すると、このモジュールがプロジェクトからすぐに削除されたことがわかります。

その変更を元に戻して保存すると、すぐに元に戻ります。

これは、Lightbuild がプロジェクトにもたらす高速な IDE 同期の例です。

さらに、Android Studio で使い慣れた通常のコマンドをすべて実行することもできます。

[実行] ボタンをクリックします。

アプリがコンパイルされ、ここで実行されます。

このデモアプリはそれほど大きくありませんが、拡大すると「Hello Android」と表示されていることがわかります。

テストファイルに移動して、このようにガターから実行することで、通常どおりにテストを実行できます。

そして、これらのテストを実行するために、舞台裏で Lightbuild を呼び出しています。

すべて想定どおりに動作します。

次に、Android Studio を使用していない場合、つまり他のエージェント フローを使用している場合に Lightbuild を使用する方法を説明します。

そのために、コマンドラインがあります。

Lightbuild の CLI で、基本的なヘルプコマンドを実行します。

このプロジェクトで見つかる誤字脱字は、すべて私のものです。

Lightbuild には、いくつかの異なるコマンドが組み込まれています。たとえば、プロジェクト外で実行している場合は、

ずっとそう言ってる。

はい、ライブデモです。

まず、Lightbuild コマンドを実行する前に、Lightbuild プロジェクトを作成します。

そのために、新しいプロジェクト テンプレートを作成するための標準のコマンドライン ツールである android create を使用します。

empty-activity-lightbuild テンプレートを使用し、アプリに「Lightbuild Demo」という名前を付けて、デモの出力ディレクトリに配置します。

このディレクトリに移動して「lightbuild -h」と入力すると、Lightbuild で使用できるすべてのコマンドが表示されます。

build、clean、test など、予想されるものがたくさんあります。

新しいものもいくつかあります。

resolve コマンドは、プロジェクトの依存関係を実際に実行し、前述の resolved.deps ファイルを生成します。

また、クエリコマンドを使用すると、ユーザーとエージェントがプロジェクトの構造をより深く理解できます。

まず、新しいクエリコマンドをご紹介します。

コマンドラインを使用してこのプロジェクトの構造を確認すると、Android Studio のデモと同じであることがわかります。

しかし、これではプロジェクトのレイアウトについてあまりわかりません。

そこで、Lightbuild クエリを実行して、このアプリ モジュールを確認します。この特別な構文を使用して、「このアプリ モジュールの下にあるものをすべて表示する」ように指示します。

app モジュール内でビルドできるさまざまなターゲットの表が表示されます。

そのため、デバッグ バイナリとリリース バイナリの両方の APK と AAB が含まれています。

アプリ ターゲットを実行するだけで、すべてがビルドされます。

また、出力を JSON として指定する方法もあります。

そうすれば、あ、すみません。

繰り返しになりますが、今日の私の入力ミスはすべて本物です。

ここでは、インタラクティブな Lightbuild ヘルプを使用して、この操作を正しく行っていることを確認します。

ええ…

はい、動作するはずです。

それでは

私のやり方が間違っていると思われる方は、この講演の後でお話ししましょう。

この表の代わりに、Lightbuild コマンドを JSON として出力することもできます。これはエージェントにとってより簡単です。

--format json…

フォーマット。

あ、ごめん。

ありがとうございました

これは、デベロッパーからのライブ フィードバックです。

ありがとうございました

はい、そうです。また、出力コマンドもあります。これもデモできます。

ターゲットではなくファイルを出力すると、ビルド内のすべての異なるバイナリの場所が表示されます。

つまり、これは、Lightbuild を使用してコマンドラインからプロジェクトを探索し、より深く理解するための方法です。

そして、先ほど説明した lightbuild resolve コマンドで、すべての resolved.deps ファイルを生成します。

これには追加機能もいくつか含まれています。

たとえば、この lockedDependencies パラメータを使用すると、これらのファイルを生成するのではなく、ファイルの内容をビルド構成で宣言した依存関係と比較します。

違いがある場合は、通知され、ビルドが失敗します。

そのため、これらの解決済み依存関係ファイルはロックファイルとして機能します。たとえば、本番環境用の CI / CD システムでアプリをビルドする場合、ビルド中に依存関係が変更されているかどうかを確認できます。

また、Lightbuild にはテスト機能が組み込まれており、たとえばコマンドラインから、このライブラリ モジュール内のすべてのテストを実行することもできます。

もう一つご紹介したいことがあります。

また、使用可能なすべてのパラメータとサブコマンドの構築に関する詳細なリストを提供するヘルプも用意されています。

これはエージェントが利用できるため、エージェントの出力となります。

それでは

Lightbuild を使用したシンプルなプロジェクトをいくつか見てきたので、もう少し野心的なプロジェクトがどのようなものかをご紹介します。

Android チームが提供している Now in Android というサンプルアプリがあります。このアプリでは、最新の Android 機能の一部が紹介されており、その使用方法やベスト プラクティスが示されています。

高度にモジュール化されたアプリケーションです。

32 種類のモジュールに分割されています。

GitHub ではこのように表示されます。

Android Studio に戻りましょう。事前にエージェントを使用しています。

私は Gemini Argon を使用して、Now in Android プロジェクトを Lightbuild に変換していました。

これは公開されたものではなく、私が独自に行ったものです。

project.lightbuild.yaml のこのプロジェクトにはさまざまなモジュールが含まれていますが、非常に高速に開き、この IDE と非常に高速に同期されていることがわかります。

このプロジェクトで注目すべきもう 1 つの点は、デモビルドと製品ビルドの両方を作成するために、いくつかのビルド フレーバー（特別なビルド構成）を使用していることです。それぞれ、アプリの表示方法が少し異なります。

デモ版では組み込みのデータソースを使用し、本番環境版では実際にネットワークにアクセスしてデータを取得します。

Lightbuild でこれを行うには、さまざまなビルド構成やプロダクト フレーバーなどを処理する方法として、アプリケーション モジュールに移動し、このアプリケーション モジュールがデモ アプリケーションであることを指定します。

そのため、すべてのコア コンポーネントに依存しますが、アプリのデモ版専用の特別な設定も取り込みます。

このように、複数のアプリケーション モジュールを使用できます。

たとえば、アプリの有料版と無料版をそれぞれ表すことができます。

また、アプリケーション モジュールがコード自体を含まない空のシェルであるため、ビルドがはるかに高速になるというメリットもあります。ライブラリが変更された場合、アプリを再度ビルドするために再コンパイルする必要があるのは、それらのライブラリだけです。

この Now in Android アプリが、32 個の異なるモジュールすべてで Lightbuild を使用して正常にビルドされているかどうかを確認してみましょう。

ありました。

また、このようなテストから学んだこととして、Lightbuild は、必要となる可能性のあるすべてのビルド機能をサポートしているわけではないという点も指摘しておきたいと思います。

たとえば、Now in Android アプリは Hilt を使用するために Hilt プラグインに依存していますが、Lightbuild はまだそのような機能をサポートしていません。

そこで、エージェントは回避策を見つけ、プロジェクト自体のコードをほとんど変更せずに Hilt のサポートを組み込むことができました。

これらのモジュールのすべてのコードは、元のリポジトリと同じです。

ただし、Lightbuild を自分で試したりデモしたりする際には、現在のプロジェクトのすべてがビルド構成の観点からサポートされるわけではないことに注意してください。

そのため、Lightbuild はまだプレビュー版であり、Android Studio Canary に搭載されています。

それでは、スライドに戻りましょう。

最後に、今回お話しした内容をまとめましょう。Lightbuild は、Android 向けの新しいビルド プラットフォームです。現在は試験運用段階です。

宣言型のビルド構成を備えているため、ビルド構成で実行可能コードを実行する必要がありません。これにより、高速な IDE 同期やより効率的なビルドなど、多くの優れた機能が実現します。

ファーストクラスの AI エージェント サポートがあり、コマンドラインには、本日デモでご紹介したすべての機能が備わっています。

ぜひお試しいただき、デモや試験運用プロジェクトにご活用ください。

また、Juan と私、そしてチームのエンジニアがエージェント型 AI ブースに常駐し、皆様のご質問にお答えします。

ありがとうございました 長くなって申し訳ないのですが