| 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または静的 SDKとも呼ばれます。
- Shim: プロセス間通信またはプロセス間通信（IPC）を抽象化し、同じアプリ SDK インターフェースを維持する Jetpack ライブラリ。
SDK ランタイムのアーキテクチャ
SDK ランタイムは、クライアント サーバー型のモデルを採用しています。
主な違いは、「クライアント」（アプリ）と「サーバー」（ランタイムで有効な SDK）が同じデバイスで実行され、この通信がプロセス間で行われることです。
こうした課題に対処するため、Google は SDK ランタイム内でのアプリと SDK の統合を簡素化するために、次の Jetpack ライブラリとツールを構築しました。
- シム ライブラリ: ラッパー ライブラリ（またはシム）は、プロセス間通信またはプロセス間通信（IPC）を抽象化するために使用されます。また、同じアプリ SDK インターフェースを維持するのにも役立ちます。
- 下位互換ライブラリ: このライブラリは下位互換性を処理し、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 とは対照的に、ランタイム対応の薄いラッパー（薄い RA_SDK）には、静的にリンクされたライブラリ SDK に API 変換とランタイム対応の SDK 呼び出しコードのみが含まれています。
この段階では、すべての SDK コードを静的アプリ ライブラリ SDK からランタイム対応 SDK に移行する必要があります。
アプリ内ランタイム対応の薄い SDK が、SDK ランタイム内のランタイム対応 SDK への呼び出しを処理するため、アプリ デベロッパーはフェーズ 1 から変更を加える必要はありません。
フェーズ 3 - 完全な移行
この最後のフェーズでは、SDK のすべての機能をランタイム対応 SDK に移行し、アプリからすべての静的ライブラリを削除しました。
この時点で、アプリ クライアントはビルドにライブラリを含める必要がなくなります。マニフェストに SDK の依存関係をリストし、アプリコードに SDK 呼び出しを含めるだけです。
SDK 呼び出しはシステムによって SDK ランタイムに転送され、ランタイム対応 SDK が自動的に読み込まれます。
