Lightbuild プロジェクトの構造

試験運用版: Lightbuild は試験運用版のプレビューです。設計はまだ進化中であり、すべての Android ビルド機能をサポートしているわけではありません。本番環境アプリ、既存のプロジェクト、野心的な新しいアプリの場合は、引き続き Kotlin DSL を使用してください。Lightbuild プレビューは、小規模なアプリ、プロトタイプ、デモに最適です。サポート内容の詳細については、Kotlin DSL の比較とリリースノートをご覧ください。

Lightbuild プロジェクトでは、アプリのアセンブリがアプリのコードから分離されます。アプリ モジュール（「アプリケーション シェル」）がアプリをアセンブルし、ライブラリ モジュールにアプリの機能、UI、ビジネス ロジックが含まれます。このページでは、新しい Lightbuild プロジェクトのレイアウトと、各モジュールとビルドファイルの役割について説明します。

プロジェクトのレイアウト

デフォルトの Lightbuild プロジェクト テンプレートには、次のビルドファイルとモジュールが含まれています。

MyApp/
├── project.lightbuild.yaml  # Project-wide settings
├── app/                     # App module
│   ├── lightbuild.yaml
│   └── resolved.deps
└── app-core/                # Library module
    ├── lightbuild.yaml
    ├── resolved.deps
    └── src/                 # The app's source code

このプロジェクトには、ルート ディレクトリの project.lightbuild.yaml ファイルと、各モジュールの lightbuild.yaml ファイルという 3 つのビルド構成ファイルがあります。各モジュールには resolved.deps ファイルもあります。各構成ファイルの設定の詳細については、Lightbuild 構成リファレンスをご覧ください。

アプリ モジュール

Lightbuild プロジェクトでは、アプリのベースとしてアプリ モジュールを使用します。ソースコードを含まずにプロジェクトのアセンブリを処理するため、「アプリケーション シェル」とも呼ばれます。すべての機能とロジックは個別のライブラリ モジュールに残り、アプリケーション シェルは署名や最適化などの最終的な構成に重点を置きます。

アプリ モジュールの lightbuild.yaml ファイルは、モジュールの type を application に設定し、最終的なアプリの構成方法を指定します。これには、次のものが含まれます。

• アプリの ID: アプリケーション ID、バージョン コード、バージョン名
• アプリの SDK 要件: compileSdk、minSdk、targetSdk のバージョン
• アプリが依存するモジュール（この例では app-core）

ライブラリ モジュール

ライブラリ モジュールには、アプリの機能、UI コンポーネント、ビジネス ロジックなど、アプリ モジュールがアセンブルするコードが含まれています。新しいプロジェクト テンプレートでは、app-core ライブラリ モジュールにサンプルコードを含む MainActivity.kt ファイルが含まれています。

ライブラリ モジュールの lightbuild.yaml ファイルは、モジュールの type 値を library に設定します。ライブラリ モジュールは compileSdk バージョンと minSdk バージョンを定義しますが、targetSdk 設定はサポートしていません。ライブラリ モジュールの lightbuild.yaml ファイルでは、モジュールの依存関係、KSP プロセッサ、テストも宣言します。

注: モジュールを追加するには、lightbuild.yaml ファイルを含むディレクトリを作成し、project.lightbuild.yaml の modules リストにモジュールの名前を追加します。

複数のアプリ モジュール

1 つのプロジェクトに複数のアプリ モジュールを含めることができます。Lightbuild は、従来の製品フレーバーとカスタムビルド タイプをサポートしていません。代わりに、アプリのバージョンごとに別々のアプリ モジュールを作成します（dev バージョンと prod バージョン、free バージョンと paid バージョンなど）。

各アプリ モジュールは、そのバージョンに必要なライブラリ モジュールに依存します。アプリ モジュールは、ライブラリ モジュールを共有したり、バージョン固有のコードや設定（個別の依存関係注入（DI）モジュールなど）のために異なるライブラリ モジュールに依存したり、バージョンに含まれていない機能のライブラリ モジュールを除外したりできます。

たとえば、アプリの無料版と有料版を含むプロジェクトには、次のモジュールが含まれる場合があります。

MyApp/
├── project.lightbuild.yaml
├── app-free/   # App module for the free version
├── app-paid/   # App module for the paid version
├── core/       # Library module that both versions use
├── di-free/    # DI module for the free version
├── di-paid/    # DI module for the paid version
└── premium/    # Library module for paid-only features

有料版の app-paid/lightbuild.yaml ファイルは、有料版のすべてのモジュールに依存します。

android:
  applicationId: com.example.myapp.paid
  dependencies:
    module:
      - //core
      - //di-paid
      - //premium

無料版の app-free/lightbuild.yaml ファイルは、共有 core モジュールと独自の DI モジュールに依存し、premium モジュールは除外します。

android:
  applicationId: com.example.myapp.free
  dependencies:
    module:
      - //core
      - //di-free

各アプリ モジュールには、アプリケーション ID やリリース署名などの独自の設定があるため、各バージョンを個別にビルド、インストール、公開できます。特定のバージョンをビルドするには、build コマンドの実行時にそのアプリ モジュールを指定します。次に例を示します。

lightbuild build app-free

解決済みの依存関係

Lightbuild プロジェクトの各モジュールには、推移的な依存関係を含む、モジュールの解決済みの依存関係をすべて記録する resolved.deps ファイルが含まれています。Lightbuild はこのファイルを自動的に生成するため、プロジェクトを開いたりビルドしたりするたびに依存関係を動的に解決する必要がありません。このファイルは手動で編集しないでください。

resolved.deps ファイルを、プロジェクトの lightbuild.yaml ファイルとともにバージョン管理にチェックインします。

CI ビルドなどで依存関係をロックするには、--locked-dependencies フラグを lightbuild resolve または lightbuild test に追加します。このフラグを使用すると、resolved.deps ファイルがモジュールの依存関係と一致しない場合、ファイルを更新する代わりにコマンドが失敗します。

lightbuild resolve --locked-dependencies