| Key concepts | Set up your development environment | Build an RE SDK | Consume the RE SDK | Testing, and building for distribution |
主なコンセプト
このセクションでは、SDK ランタイムのアーキテクチャ、ランタイム対応 SDK のインストール方法、下位互換性、既存の SDK を SDK ランタイムに移行する方法について説明します。
用語集
- ランタイム対応 SDK（RE SDK）: SDK ランタイム環境で実行され、プロセス間通信（IPC）を介してアプリと通信するように作成された SDK。
- ランタイム対応 SDK（RA SDK）: ランタイム対応ではない SDK。アプリに静的にリンクされます。既存の SDK コードと、ランタイム対応 SDK を呼び出すための新しいコードが含まれる場合があります。
- これは、静的リンクまたは静的 SDK とも呼ばれます。
- Shim: プロセス間通信（IPC）を抽象化し、アプリと SDK のインターフェースを維持するのに役立つ Jetpack ライブラリ。
SDK ランタイム アーキテクチャ
SDK ランタイムは、クライアント サーバー タイプのモデルを採用しています。
主な違いは、「クライアント」（アプリ）と「サーバー」（ランタイム対応 SDK）が同じデバイス上で実行され、この通信がプロセス間で行われることです。
こうした課題に対処するため、SDK ランタイム内でのアプリと SDK の統合を簡素化する Jetpack ライブラリとツールを以下のように構築しました。
- シム ライブラリ: ラッパー ライブラリ（またはシム）は、プロセス間の通信またはプロセス間通信（IPC）を抽象化するのに役立ちます。また、アプリと SDK のインターフェースを同じに保つこともできます。
- Backcompat ライブラリ: このライブラリは下位互換性を処理し、SDK ランタイムが利用可能かどうかに関係なく、SDK の互換性を確保します。
- UI ライブラリ: ランタイム対応 SDK からの UI の取得や、ビューのサイズ変更と再レイアウトなど、リモート プレゼンテーションを処理するためのライブラリも提供しています。
インストール フローの変更
Android Studio などのツールでランタイム対応 SDK をビルドすると、ランタイム対応 SDK の公開フォーマットである Android SDK Bundle（ASB）が作成されます。
bundletool は ASB を処理して、ランタイム対応 SDK の APK を生成します。この個別の APK には SDK コードが含まれますが、アプリコードは含まれません。
アプリのマニフェスト ファイルで、ランタイム対応 SDK の名前とバージョンへの依存関係が宣言され、この依存関係はインストーラアプリによって解決されます。
インストーラが SDK APK を取得すると、SDK APK のインストールからインストールが開始されます。成功すると、アプリの APK のインストールが続きます。
Android 13 以前にアプリがインストールされている場合や、SDK ランタイムをサポートしていないデバイスでは、フローが異なります。このシナリオでは、ストアは、ランタイム対応の SDK とアプリコードの両方を含む単一の APK をインストールします。詳しくは、配信セクションをご覧ください。
アプリが本番環境でこの SDK に依存している場合、アプリストアはこの ASB から正しい SDK APK を作成してインストールします。
下位互換性
SDK ランタイムは Android 14 で導入されたため、SDK デベロッパーやアプリ デベロッパーにオーバーヘッドを導入することなく、以前のバージョンをサポートする必要がありました。
Android 13 以前の下位互換性に対応するため、SDK ランタイムのデバイス サポートに関係なく、ランタイム対応 SDK をシームレスに実行できる Jetpack ライブラリを導入しました。
このガイドに沿って対応すると、ランタイム対応 SDK はデフォルトで下位互換性を持つようになり、これ以上の対応は必要ありません。
関連するステージで下位互換性に関連するアクションをハイライト表示しますが、一般的には、適切な依存関係が宣言されていること、および該当する場合は *Compat クラスを使用していることを確認する必要があります。
既存の SDK を移行する
ランタイムに移行する既存の SDK がある場合、コードベース全体を一度にリファクタリングする必要はありません。代わりに、既存の SDK ロジックを新しいランタイム対応 SDK に段階的に移行することもできます。
既存の SDK を SDK ランタイムに移行するには、次の 3 つのフェーズをおすすめします。
- 移行期間のランタイム対応 SDK と、対応する厚いランタイム対応 SDK をビルドします。これにより、既存の SDK からビジネス ロジックを段階的に移行し、A/B テスト用のテスト プラットフォームを提供できます。
- 既存の SDK ビジネス ロジックをすべて 定常状態に移行し、アプリの移行を容易にするために、対応するシン ランタイム対応 SDK を用意
- 薄いランタイム対応 SDK を使用せずに、ランタイム対応 SDK を直接使用する完全な移行で、対象アプリをサポート
フェーズ 1 - 移行期間: 厚いランタイム対応 SDK
まず、ビジネス ロジックの一部をランタイム対応 SDK に残すかどうかを選択します。これを、ランタイム認識型の厚い SDK またはアプリ内ラッパーと呼びます。
このアプローチでは、新しくビルドされたランタイム対応 SDK とともに、SDK の機能のすべてまたは一部を静的アプリ ライブラリに保持できます。
これにより、ユースケースをランタイム対応 SDK に段階的に移行し、既存の SDK に対してランタイム対応 SDK をテストできます。
このフェーズでは、アプリ デベロッパーは SDK の使用方法を変更する必要はありません。ランタイム対応 SDK の使用に必要な処理は、静的アプリ ライブラリ（ランタイム対応 SDK）が行うためです。
フェーズ 2 - 安定状態: シン ランタイム対応 SDK
厚いランタイム対応 SDK とは対照的に、シン ラッパーまたはシン ランタイム対応 SDK（シン RA_SDK）には、静的リンク ライブラリ SDK の API 変換とランタイム対応 SDK 呼び出しコードのみが含まれます。
この段階では、すべての SDK コードを静的アプリ ライブラリ SDK からランタイム対応 SDK に移行しているはずです。
アプリ デベロッパーは、フェーズ 1 から変更を加える必要はありません。アプリ内のシン ランタイム対応 SDK が、SDK ランタイム内のランタイム対応 SDK への呼び出しを処理するためです。
フェーズ 3 - 完全な移行
この最終フェーズでは、SDK のすべての機能をランタイム対応 SDK に移行し、アプリからすべての静的ライブラリを削除します。
この時点で、アプリ クライアントはビルドにライブラリを含める必要がなくなり、マニフェストで SDK の依存関係をリストし、アプリコードに SDK 呼び出しを含めるだけで済みます。
SDK 呼び出しはシステムによって SDK ランタイムにルーティングされ、ランタイム対応 SDK が自動的に読み込まれます。
