このページは Cloud Translation API によって翻訳されました。

SDK ランタイムの概要

Android プラットフォームでは、アプリサンドボックスのコンセプトをもちいることで、プロセス境界に沿ったアプリコードの堅牢な実行とセキュリティ境界が維持されます。アプリにサードパーティのコードを含めることは一般的であり、多くの場合、広告 SDK や分析 SDK などの SDK の形をとります。このような再利用により、アプリデベロッパーはアプリの差別化に専念できると同時に、専門家の力を借り、負担なく独自で行える範囲をさらに広げることができます。

ほとんどのオペレーティングシステムと同様に、Android では、SDK はホストアプリのサンドボックス内で実行され、ホストアプリと同じ特権と権限を継承します。また、ホストアプリのメモリとストレージへのアクセス権も継承します。このアーキテクチャでは SDK とアプリを柔軟に統合できますが、非公開のユーザーデータが収集され共有される可能性も生じます。さらに、アプリデベロッパーは、サードパーティ SDK の機能やアクセスするデータの範囲を十分に把握していない場合があり、アプリのデータ収集や共有の方法について説明することは困難です。

Android 13 では、サードパーティサービスアカウントからの SDK ランタイムと呼ばれる専用のランタイム環境で実行する SDK。「 SDK ランタイムは、次のような、より強力な安全保護対策と保証を提供します。ユーザーデータの収集と共有：

実行環境の変更
SDK の権限とデータアクセス権の明確な定義

で確認できます。

現在、モバイルアプリの広告コミュニティの皆様からのフィードバックをお待ちしています。考えてみましょう。また、Google はあらゆる開発者コミュニティからのフィードバックを歓迎し、 SDK ランタイムの今後のイテレーションの改善に役立っています。たとえば、ユースケースが増えています

目標

この提案では、以下の目標を達成することを目指します。

プロセスの分離と明確に定義された API およびデータアクセス制御を通じて、サードパーティ SDK によってユーザーのアプリデータが秘密裡にアクセスされたり共有されたりすることを抑えます。プロセスの分離の詳細については、このドキュメントの別のセクションをご覧ください。
SDK による一意の永続的な識別子へのアクセスを制限することで、サードパーティ SDK によってユーザーのアプリ使用状況が秘密裡に追跡されることを抑えます。
アプリデベロッパーとエンドユーザーの負担を軽減し、安全性を確保したうえで、アプリに対する SDK アップデートの配信を推進します。信頼できる SDK の配信モデルの案については、このドキュメントの別のセクションをご覧ください。
アプリデベロッパーが、アプリのデータアクセスと共有の方法について適切に説明できるようにします。
SDK デベロッパーが、JNI コードなどの安全でない特定の言語構造を制限することで、他の SDK による改ざんを防止できるようにします。
メディアを表示するリモートビューを完全に制御することで、広告 SDK が無効なトラフィックや広告の不正行為を検出して防止できるようにします。
アプリデベロッパーと SDK デベロッパーへの過度な影響をできる限り最小に抑えます。

独立したプロセスで SDK を実行する

提案された SDK ランタイムでは、互換性のある SDK が有効になります。 ランタイム対応（RE）SDK と呼びます。これらは、別のプロセスが必要になりますこのプラットフォームでは、ネットワークアプリのプロセスと SDK ランタイム間の通信を可能にします。詳細については、このドキュメントの通信に関するセクションをご覧ください。非 RE SDK はアプリのプロセスに残ることになります次の図は、変更します。

アプリプロセスを実行するすべてのものを示す前の図 — SDK ランタイムに追加する前に、SDK 呼び出し側のコードと、SDK の呼び出しを受信する SDK すべてアプリのプロセスに存在する

アプリプロセスと SDK ランタイムプロセスの間で分割されたプロセスを示す図 — SDK の呼び出しコードを SDK ランタイムに追加すると、フォアグラウンドプロセスでは、SDK の呼び出しコードは SDK のインターフェース。これらのインターフェースはプロセス境界をまたいで SDK 自体を呼び出す SDK ランタイムプロセス

信頼性の高い新しい SDK 配信モデル

SDK とアプリの分離という提案は、SDK とアプリの配信という別の分離コンセプトにもつながります。この提案では、アプリの SDK ランタイムに正しい SDK がインストールされるように、配信とインストールについて信頼性の高いメカニズムが必要になります。そうすることで、無効な SDK が読み込まれないようにユーザーとアプリデベロッパーを保護できるほか、アプリストアで SDK を配信するアプリデベロッパーの負担を大幅に減らすことができます。

SDK を配信する際には、アプリストアにアップロードする前にアプリと静的にリンクしてパッケージ化する必要がありますが、これがなくなります。代わりに、次のプロセスが発生します。

SDK デベロッパーは、バージョニングされた SDK をアプリストアにアップロードし、管理することもできます。
アプリデベロッパーは、SDK の依存関係をバージョンごとに指定してビルドし、実際の SDK の依存関係を含まないアプリリリースをアップロードします。
ユーザーがこのアプリをダウンロードする際には、インストールプロセスでアプリに指定された SDK の依存関係が使用され、アプリがアプリストアからダウンロードされます。

この新しい配布メカニズムにより、SDK デベロッパーは互換性を損なわない変更（つまり、API やそのセマンティクスの変更）を SDK とデバイスへの配信（アプリデベロッパーの関与なし）このような互換性を損なわない SDK の変更は、デプロイやロールバックをすることなくアプリデベロッパーが新しいソフトウェアアップデートでアプリを再構築するのをエンドユーザーがアプリを更新するのを待たずに済みます。互換性を損なう変更とはアプリデベロッパーが更新する必要がありますが、SDK デベロッパーは最新の非互換性を損なわない変更と修正を迅速かつ均一にバージョンのサポートを最小限に抑えることが理想的です。

次の図は、SDK の配布で提案される変更を示しています。

変更前の図 — SDK ランタイムを導入する前に、デベロッパーは直接アプリに移行できます

で確認できます。

変更後の図 — SDK ランタイムの導入後に、デベロッパーは SDK アップロード UI を使用して SDK をアプリストアに公開します。アプリストアが SDK とともにアプリの配信を処理します。エンドユーザーのデバイスに提供します。

SDK とアプリのビルド、実行、配信方法の変更

この提案は、柔軟な SDK ランタイムと配信技術の実現を目的とした最初のものです。以降のセクションでは、次のような広範なカテゴリがあります

アクセス: 権限、メモリ、ストレージ
実行: 言語、ランタイムの変更、ライフサイクル、メディアのレンダリング
通信: アプリ～SDK 間、SDK～SDK 間
開発: このモデルでのビルド、デバッグ、テストの方法
配信: Android、アプリ、SDK のバージョン間での配信、更新、ロールバックの方法

このドキュメントには、一般的な質問に対応するためのよくある質問も記載されています。

これは初期の設計案であり、有意義であると Google は理解しています一部のメンバーにのみ変更を適用できますそのため Google ではその際は、。

アクセス

システムのプライバシーを管理するということは、さまざまな当事者による複数のリソースへのアクセス方法を管理するということを意味します。Google は、プライバシーに関する価値提案を満たすために、アプリ、SDK、ユーザーデータへのアクセスモデルを更新し、最小権限の原則に従って、機密情報になり得るデータへの非公開のアクセスを防止することを提案します。

SDK の権限

別個のプロセスとして、SDK ランタイムには明確に定義された独自の一連のユーザーがアプリに付与した権限を継承しません。ベース広告関連の SDK で使用される権限に関する予備調査では、が、SDK 内の SDK から以下の権限にアクセスできることを提案しているデフォルトのランタイム:

INTERNET: ウェブサービスと通信するためのインターネットアクセス。
ACCESS_NETWORK_STATE: ネットワークに関する情報にアクセスします。
READ_BASIC_PHONE_STATE: スマートフォンのステータスに関する情報（モバイルネットワークの種類など）にアクセスします。
クロスアプリ識別子にアクセスすることなく、主要な広告機能を提供できるプライバシー保護 API の利用に関する権限。
AD_ID: 広告 ID をリクエストする機能。これも、この権限に対するアプリのアクセス権によって制限されます。

現在、プライバシーとユーザビリティの両面からエンドユーザーへの影響を抑えつつ、追加の権限を承認するかどうか、またどのように承認するかについて検討しています。この権限のセットでは対応できないと考えられるユースケースがあれば、ぜひフィードバックをお寄せください。

メモリ

SDK ランタイムには独自の分離メモリ空間がある独自のプロセスがあるからですこの構造においては、SDK がアプリのメモリ領域にアクセスすることがデフォルトで拒否され、同様に SDK のメモリ領域にアクセスすることもできなくなります。最小権限の原則に沿ったうえで、このデフォルトの動作を維持することを提案します。

ストレージ

ここでの提案の目的は、SDK が通常のオペレーションのためにストレージにアクセスする必要性と、永続ストレージを使用したアプリ間やプロセス間のトラッキングを最小限に抑えることのバランスをとることです。ストレージにアクセスする方法について、次のように更新することを提案します。

アプリから SDK ストレージに直接アクセスすることはできず、その逆も同様です。
SDK からデバイスの外部ストレージにはアクセスできなくなります。
各 SDK ランタイム内には、すべての SDK からアクセス可能なストレージと、非公開にできます

現在のストレージモデルと同様に、ストレージ自体に制限はありません。見てきました。SDK は、アセットをキャッシュするためにストレージを使用できます。このストレージは定期的にクリアされます。

実行

アプリ、SDK、ユーザーの間でプライベートシステムを確保するには、実行コンテキスト自体（コード形式、言語構造、アクセス可能な API、システムデータ）でプライバシー境界を強化するか、少なくとも回避する手段を導入しないようにする必要があります。同時に、現在の SDK の高機能なプラットフォームとランタイム機能の大部分にも引き続きアクセスできるようにします。このバランスをとるために、ランタイム環境に対する一連の更新を提案します。

コード

Android コード（アプリと SDK）は、主に Android ランタイムによって解釈されます。（ART）とは、コードが Kotlin と Java のどちらで記述されたかを示すものです。ART の豊かさ言語構造に加え、それが提供する検証可能性。他の方法（特にネイティブコード）と比較した場合、機能性とプライバシーのバランスを取る必要がありますランタイム対応 SDK コードは Dex バイトコードのみで構成されており、JNI アクセスはサポートされていません。

カスタムパッケージの SQLite を使用するなどのユースケースもあります。ネイティブコードを使用している場合には、Android SDK の組み込みバージョンの SQLite など、代替手段に置き換える必要があります。

SELinux

Android では、各プロセス（root として実行されているものを含む）が特定の SELinux コンテキストで実行されるため、カーネルでシステムサービス、ファイル、デバイス、その他のプロセスへのアクセス制御を管理できます。Google が進めようとしているプライバシー保護の回避を最小限に抑えつつ、SDK のユースケースの大部分を保持するために、システム以外のアプリの SELinux コンテキストから、SDK ランタイムを対象に次のように更新することを提案します。

アクセスできるシステムサービスを一部に限る（設計中）。
SDK が APK 内のコードの読み込みと実行しかできないようにする
アクセスできるシステムプロパティを一部に限る（設計中）。

API

SDK ランタイム内でのリフレクション API と呼び出し API の使用は許可されています。ただし、SDK でリフレクション API を使用したり、別の API でリフレクション API を SDK が含まれます。禁止されている API の完全な提案は、今後のアップデート予定。

さらに、最近の Android プラットフォームリリースでは、プライバシー強化のために永続的な識別子へのアクセスが制限されるようになりました。SDK ランタイムでは、クロスアプリトラッキングに使用される可能性のある識別子へのアクセスをさらに制限することを提案します。

SDK ランタイム API は、フォアグラウンドで実行されているアプリからのみアクセスできます。バックグラウンドでアプリから SdkSandboxManager API にアクセスしようとすると、SecurityException がスローされます。

また、RE SDK では、通知 API を使用したユーザー通知の送信がいかなる時点でもできません。

Lifecycle

現在、アプリ SDK はホストアプリのライフサイクルに従うようになっています。つまり、アプリがフォアグラウンドで開始または終了される、シャットダウンされる、メモリ負荷のためにオペレーティングシステムによって強制停止されると、アプリ SDK も同じ動作をします。そこで、アプリ SDK を別のプロセスに分割するよう提案しますが、これはライフサイクルを次のように変更することを意味します。

アプリは、ユーザーまたはオペレーティングシステムによって終了させることができる。直後に、SDK ランタイムが自動的に終了する。
SDK ランタイムは、メモリ負荷や、SDK での未処理の例外などにより、オペレーティングシステムによって終了させることができる。

Android 13 ではアプリがフォアグラウンドにある場合、SDK ランタイムは高優先度で実行され、停止する可能性は低くなります。アプリがバックグラウンドに移行すると、SDK ランタイムプロセスの優先度が低くなり、停止の対象になります。アプリがフォアグラウンドに戻っても、SDK ランタイムプロセスの優先度は低いままです。そのため、メモリ不足で終了してしまう可能性は、アプリより非常に高くなります。

Android 14 以降では、アプリと SDK ランタイムのプロセス優先度は一致しています。アプリと SDK ランタイムの ActivityManager.RunningAppProcessInfo.importance のプロセス優先度はほぼ同じです。

アプリの実行中に SDK ランタイムが終了した場合（SDK に未処理の例外がある場合など）、以前に読み込まれたすべての SDK とリモートビューを含む SDK ランタイムの状態が失われます。アプリデベロッパーは、次のいずれかの方法で SDK ランタイムの終了に伴って処理を実行できます。
- このプロポーザルでは、関連するライフサイクルコールバックメソッドをアプリデベロッパーに提供し、SDK ランタイムの終了が発生したタイミングを検出します。
- 広告の表示中に SDK ランタイムが終了した場合、広告が想定どおりに機能しなくなる可能性があります。たとえば、ビューが画面上でフリーズし、操作できなくなることがあります。アプリでは、ユーザーエクスペリエンスに影響しない場合は広告ビューを削除できます。
- アプリでは SDK の読み込みと広告のリクエストを再試行できます。
- Android 14 では、SDK の読み込み中に SDK ランタイムが終了し、アプリデベロッパーが前述のライフサイクルコールバックメソッドを登録していない場合、デフォルトではアプリは終了します。SDK を読み込んだアプリプロセスのみが正常に終了します。
- 通信のために SDK から返されたバインダオブジェクト（SandboxedSdk など）は、アプリで使用されている場合に DeadObjectException をスローします。
このライフサイクルモデルは、今後の更新で変更される可能性があります。

永続的な障害が発生した場合には、アプリデベロッパーは SDK を使用しないグレースフルデグラデーションを予定する必要があります。あるいは、SDK がアプリのコア機能に不可欠であればユーザーに通知する必要があります。このアプリと SDK の間のインタラクションについて詳しくは、このドキュメントの通信のセクションをご覧ください。

非 RE SDK では、サービス、アクティビティ、ブロードキャストなど、組み込みアプリで使用できる標準的な OS プリミティブを引き続き使用できますが、RE SDK では使用できません。

特別な場合

次のようなケースはサポートされていないため、予期しない動作が発生する可能性があります。

複数のアプリが同じ UID を共有している場合、SDK ランタイムが正常に機能しない可能性があります。共有 UID のサポートは今後追加される可能性があります。
プロセスが複数あるアプリの場合、SDK の読み込みはメインプロセスです

メディアのレンダリング

複数の SDK で、テキスト、画像、動画などのコンテンツをアプリ指定のビューにレンダリングする場合があります。これを実現するために、リモートレンダリングアプローチを提案します。このアプローチでは、SDK が SDK ランタイム内からメディアをレンダリングしますが、アプリ指定のビューでメディアをレンダリングできるように SurfaceControlViewHost API を使用します。これにより、SDK では、ユーザーに限定された方法でメディアをレンダリングする機能が提供されるとともに、レンダリングされたメディアに対する無効または不正なユーザー操作の防止と検出が行えます。

SDK ではなくアプリがレンダリングするネイティブ広告は、SDK ランタイムの SDK でサポートされます。ネイティブ広告以外でも、シグナルの収集処理とクリエイティブの取得処理が一貫して行われます。これについては現在調査中です。

インストリーム動画広告は、動画プレーヤー内に表示される動画とともにインストリーム動画配信されます。行うことができます。動画はアプリ内のプレーヤー内で再生され、レンダリングモデルは、SDK のプレーヤーやビューとは異なる使用できます。Google は、サーバーサイドの広告挿入と SDK ベースの広告挿入の両方をサポートするメカニズムを検討しています。

システムの健全性

Google は、システムの健全性に関して SDK ランタイムがエンドユーザーのデバイスに与える影響を最小限に抑えることを目指しており、そのための方法を設計しています。ただし、Android（Go エディション）など、システムリソースが非常に限られている一部のエントリーレベル Android 13 デバイスでは、システムの健全性に影響するため、SDK ランタイムがサポートされません。SDK ランタイムを正常に使用するために必要な最小要件については、近日中にお知らせいたします。

通信

現在、アプリと SDK は同じプロセスで実行されているため、両者の間の通信は妨げられず、仲介もされません。また、Android では、SDK で通信の開始と終了を行う場合でもアプリ間の通信が可能です。この自由な通信モデルにより、さまざまなユースケースが実現される一方で、アプリとアプリ、アプリ内の SDK と SDK、アプリ間の SDK と SDK の間で、非公開のデータが共有される可能性が生じます。このような通信の価値と Google が掲げた目標の実現との間でバランスを取ることを目指し、通信モデルを次のように更新することを提案します。

アプリ～SDK 間

アプリと SDK の間のインターフェースは SDK への最も一般的な通信経路です。SDK の API には、ユーザー向けの差別化とイノベーションの多くが存在しています。Google は、SDK のイノベーションと差別化の機能を保つことを目指します。その結果として、SDK がアプリに対して API を公開し、アプリがイノベーションの恩恵をすべて受けられるようにすることを提案します。

具体的には、SDK ランタイムのプロセス境界構造をふまえ、アプリと SDK の間の境界を越えて API の呼び出しとレスポンスまたはコールバックを伝送するために、アプリ内でアクセス可能なマーシャリングレイヤを構築します。このマーシャリングレイヤのインターフェースは SDK デベロッパーが定義し、Google が開発する公式のオープンソースビルドツールで生成します。

この提案では、アプリデベロッパーと SDK デベロッパーがマーシャリングに関連するボイラープレートを記述しなくていいようにすることを目指します。また同時に、SDK デベロッパーに柔軟性を提供しつつ、SDK コードが SDK ランタイムで実行されるようにして、Google の目指すプライバシー目標を達成できるようにします。なお、この方法を採用する場合には、API の定義言語とツールについて、デベロッパーの意見を取り入れて設計する予定です。

一般的なインタラクションモデルは次のようになります。

アプリがインターフェースを通じて SDK を呼び出し、コールバックで渡す。
SDK がコールバックを使用して非同期的にリクエストを処理し、応答する。
任意のパブリッシャーサブスクライバーモデルに一般化できる。つまり、アプリはコールバックで SDK のイベントに登録でき、イベントが発生するとコールバックがトリガーされる。

この新しいクロスプロセス構造を提案することで、アプリ自体のプロセスライフサイクルと、SDK ランタイムのプロセスライフサイクルという 2 つのプロセスライフサイクルを管理する必要が生じます。今回の提案では、この点を可能な限り自動化することで、アプリデベロッパーと SDK デベロッパーへの影響を最小限に抑えることを目指しています。「次の図は、検討しているアプローチを示しています。

プラットフォームでは、SDK ランタイムプロセスに SDK を動的に読み込み、プロセスの状態の変化について通知を受け、SDK ランタイムに読み込まれた SDK とやりとりするための新しい API が公開されます。

上の図のグラフは、100 ミリ秒未満でのアプリと SDK 間の通信を示しています。マーシャリングレイヤはありません。

アプリは、次の手順で SDK ランタイムプロセスで実行されている SDK と通信します。

アプリは SDK とやりとりする前に、SDK を読み込むようプラットフォームにリクエストします。システムの整合性を確保するために、アプリがマニフェストファイルで読み込む予定の SDK を指定します。指定された SDK だけが読み込みを行えます。

次のコードスニペットに API の例を示します。
```
SdkSandboxManager.loadSdk(String sdkName, Bundle data, Executor executor,
    OutcomeReceiver<SandboxedSdk, LoadSdkException> receiver)
```
SDK は、読み込み完了の通知を受け取り、そのインターフェースを返します。このインターフェースは、アプリプロセスで使用するためのものです。プロセス境界外でインターフェースを共有するには、インターフェースを IBinder オブジェクトとして返す必要があります。

バインドされたサービスのガイドに、IBinder を指定するさまざまな方法が記載されています。いずれの場合も、SDK と通話アプリ。この図では AIDL を例として使用しています。
SdkSandboxManager は IBinder インターフェースを受け取り、アプリに返します。

アプリは IBinder を取得して SDK インターフェースにキャストし、その関数を呼び出します。

IBinder binder = sandboxSdk.getInterface();
ISdkInterface mySdkInterface = ISdkInterface.Stub.asInterface(binder);
mySdkInterface.something();

アプリは、次の手順で SDK からメディアをレンダリングすることもできます。

このドキュメントのメディアレンダリングのセクションで説明したように、SDK を取得してビューにメディアをレンダリングするために、アプリは requestSurfacePackage() を呼び出して該当する SurfaceControlViewHost.SurfacePackage を取得します。

次のコードスニペットに API の例を示します。
```
SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
        Executor executor,
        OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
```
アプリは、返された SurfacePackage を SurfaceView に埋め込むことができます。 SurfaceView の setChildSurfacePackage API 経由。

次のコードスニペットに API の例を示します。
```
SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
```

この提案では、IBinder API と requestSurfacePackage() API は汎用であり、アプリから直接呼び出されることを想定していません。代わりに、先に説明したように、アプリデベロッパーの負担を軽減するため、これらの API は生成された API リファレンスによって「shim」レイヤで呼び出されます。

SDK～SDK 間

同じアプリ内の 2 つの SDK が通信を行う必要が生じることがよくあります。これは、特定のエンティティが SDK は構成要素となる SDK で構成されるように設計されており、2 つの SDK が異なるパーティの SDK が連携して、通話アプリ。

考慮すべき重要なケースが 2 つあります。

両方の SDK がランタイム対応の場合。この例では、両方の SDK がすべての保護を含む SDK ランタイムを実行します。SDK は他の Google Cloud ユーザーとしていくつか見てみましょうそのため、取得を有効にするために SdkSandboxController が追加されました読み込まれたすべての RE-SDK の SandboxedSdk オブジェクト。これにより RE-SDK が SDK ランタイムに読み込まれた他の SDK と通信します。
1 つの SDK のみがランタイム対応である場合。
- 呼び出し元 SDK がアプリ内で実行されている場合は、SDK ランタイム内の 2 番目の SDK をアプリ自体が呼び出す場合と同じように動作します。
- 呼び出し元の SDK が SDK ランタイム内で実行されている場合、このプロポーザルは、では、アプリから SDK に関するセクションに説明されているとおり、IBinder を使用してメソッドを公開することを推奨しています。でリッスン、処理、応答するセクションに、使用できます。
- ランタイム対応でない広告 SDK は、自身を登録できない場合があります。任意のパートナーやアプリを含むメディエーション SDK を作成することをおすすめしますアプリの直接的な依存関係として SDK を使用し、登録を処理します。このメディエータ SDK がランタイム非対応の間の通信を確立する SDK または他のアプリの依存関係と、サービスアカウントとして機能するランタイム対応メディエータ設定してください。

SDK 間通信の機能セットは、以下のカテゴリに分類されます。

SDK ランタイム内の SDK 間通信（最新のデベロッパープレビューで利用可能）
およびアプリと SDK ランタイム間の SDK 間通信（最新のデベロッパープレビュー）
メディエーションのビューとリモートレンダリングの仕組み（開発中の提案）

プリミティブが設計中で、次のユースケースが検討されています。

メディエーションと入札: 多くの広告 SDK にはメディエーションや入札の機能があります。これにより SDK は他のさまざまな SDK を呼び出して、広告の表示（メディエーション）や、オークション（入札）を行うためのシグナル収集を行います。調整 SDK は通常、調整 SDK が提供するアダプターを通じて他の SDK を呼び出します。前述のプリミティブを考慮すると、調整 SDK は、RE かどうかにかかわらず、通常のオペレーションのためにすべての RE SDK と非 RE SDK にアクセスできる必要があります。この場合のレンダリングについては現在調査中です。
機能の検出: 一部の SDK プロダクトはより少ない SDK で構成されています。このようなプロダクトでは、SDK 間での検出プロセスを通じて、アプリデベロッパーに公開される最終的な機能セットが特定されます。このユースケースを有効にするために、登録と検出のプリミティブが想定されます。
パブリッシャーサブスクリプションモデル: 一部の SDK はイベントのセントラルパブリッシャーを持つように設計されます。これは、他の SDK またはアプリが通知を受け取るためにコールバックを通じて登録できるものです。前述のプリミティブは、このユースケースをサポートする必要があります。

アプリ～アプリ間

アプリ間の通信では、2 つのプロセスのうち少なくとも 1 つが SDK と通信するための API はランタイム対応 SDK であり、非公開のデータ共有です。そのため、SDK ランタイムはクライアントアプリケーション以外のアプリとの直接通信チャネル別のアプリ用に作成された別の SDK ランタイムの SDK がある場合。これは、達成する方法:

SDK では、<service>、<contentprovider>、マニフェスト内で <activity> を指定します。
SDK が ContentProvider を公開したり、ブロードキャストを送信したりすることはできません。
SDK は別のアプリに属するアクティビティを起動できますが、渡す必要があります。たとえば、エクストラやカスタムアクションでは、追加することもできます。
SDK はサービスの許可リストの開始またはバインドのみできます。
SDK はシステム ContentProvider のサブセットにのみアクセスできます（com.android.providers.settings.SettingsProvider など）が、データに識別子がなく、ユーザーのフィンガープリントの作成には使用できません。これらのチェックは、次を使用して ContentProvider にアクセスする場合にも適用されます。 ContentResolver。
SDK がアクセスできるのは、保護されたブロードキャストレシーバのサブセット（ android.intent.action.AIRPLANE_MODE など）。

マニフェストタグ

SDK がインストールされると、PackageManager が SDK のマニフェストを解析し、エラーになるは、禁止されているマニフェストタグが存在する場合に SDK をインストールします。たとえば、SDK は <service>, <activity>, <provider> や <receiver> などのコンポーネントを定義しないマニフェストで <permission> を宣言することはできません。失敗したタグ SDK ランタイムではサポートされていません。エラーが発生しないタグ通知なく無視される機能は、今後の Android ではサポートされる可能性がありますあります。

これらのチェックは、SDK がコンテナイメージのビルドに使用する任意のビルド時ツールによっても適用されるアプリケーションストアへのアップロード時に SDK Bundle を作成する必要があります。

アクティビティのサポート

SDK ランタイム環境の SDK では、マニフェストにアクティビティタグを追加できません Context.startActivity を使用して自分のアクティビティを開始することはできません。代わりに、プラットフォームがリクエストに応じて SDK のアクティビティを作成し、 SDK と共有します。

プラットフォームアクティビティのタイプは android.app.Activity です。プラットフォームアクティビティアプリのアクティビティの 1 つから開始され、アプリタスクの一部です。 FLAG_ACTIVITY_NEW_TASK はサポートされていません。

SDK がアクティビティを開始できるように、SDK でタイプのインスタンスを登録する必要があります。 SdkSandboxActivityHandler: 次の場合にアクティビティの作成について通知するために使用されます。アプリが SdkSandboxManager::startSdkSandboxActivity(Activity, IBinder) を呼び出してアクティビティを開始します。

アクティビティのリクエストの流れを以下のグラフに示します。

開発

この提案の基本方針は、デベロッパーエコシステムへの影響を可能な限り最小限に抑えることです。このプロポーザルでは開発、開発、デバッグするための包括的な開発ツールセットを説明します。この提案の完全性を保証するために、 RE アプリと SDK の構成、作成、ビルドの方法に対するいくつかの変更が加えられました。

オーサリング

Android Studio と関連ツールが SDK ランタイムに対応するように更新される予定です。デベロッパーが RE アプリと SDK を正しく設定し、既存の呼び出しやサポートされていない呼び出しを関連する新しい代替方法に更新できるようにサポートします。この提案では、デベロッパーにオーサリングフェーズでいくつかの手順を踏むよう求めています。

アプリデベロッパー

アプリマニフェストで、アプリの RE SDK と SDK 証明書の依存関係を指定する必要があります。今回の提案全体で、この依存関係の指定をアプリデベロッパーからの信頼できる情報源として扱います。次に例を示します。

名前: SDK またはライブラリのパッケージ名。
メジャーバージョン: SDK のメジャーバージョンコード。
証明書ダイジェスト: SDK ビルドの証明書ダイジェスト。関連するアプリストアを通じて、SDK デベロッパーが特定のビルドについてこの値を取得して登録することを提案します。

これは、RE であるかどうかにかかわらず、アプリストアで配布される SDK にのみ適用されます。SDK を静的にリンクするアプリでは、現在の依存関係メカニズムを使用します。

デベロッパーへの影響を最小限に抑えるという目標をふまえると、SDK ランタイムをサポートするターゲット API レベルが指定されれば、ビルドが SDK ランタイムをサポートしているデバイスで実行されているかどうかにかかわらず、アプリデベロッパーがビルドを 1 つ用意すれば済むようになることが重要です。

SDK デベロッパー

今回の提案では、RE SDK デベロッパーが、SDK またはライブラリエンティティを表す新しい要素をマニフェストで明示的に宣言する必要があります。さらに、依存関係と同様の値のセットとマイナーバージョンを指定する必要があります。

名前: SDK またはライブラリのパッケージ名。
メジャーバージョン: SDK のメジャーバージョンコード。
マイナーバージョン: SDK のマイナーバージョンコード。

RE SDK デベロッパーは、ビルド時の依存関係として他の RE SDK を使用している場合、アプリデベロッパーが同じ依存関係を宣言する際と同じ方法で RE SDK を宣言する必要が生じます。RE SDK が非 RE SDK に依存する場合は、静的にリンクされます。非 RE SDK が、SDK ランタイムでサポートされていない機能を必要とする場合、またはアプリのプロセスで実行される必要がある場合、ビルド時またはテストパス中に検出される問題が発生する可能性があります。

RE SDK デベロッパーが、RE 未対応デバイスのサポート継続を必要とする場合もあります。RE 未対応デバイスには、Android 12 以前や、このドキュメントのシステムの健全性に関するセクションで説明した、システムリソースが非常に限られているエントリーレベルの Android 13 デバイスなどが挙げられます。Google は、SDK デベロッパーが単一のコードベースを保持して RE 環境と非 RE 環境に対応できるようにするためのアプローチに取り組んでいます。

ビルド

アプリデベロッパー

アプリデベロッパーがビルドステップで変更を必要とすることはほとんどないと見込まれます。SDK の依存関係（ローカルに配布されているかアプリにあるか） lint チェックを行うには、ストア配布（RE かどうかを問わず）がマシン上に存在している必要があります。コンパイル、ビルドを行います。アプリデベロッパーから提供されるこれらの詳細情報と通常の使用状況を、Android Studio で抽象化し、可能な限り透明性を保つことを提案します。

デバッグビルドにはすべてのコードとシンボルを含める必要がありますが、を DEBUG ビルドに含めると、リリースビルドはデバッグのために必要に応じて、アプリストアで配布されているすべての SDK（RE または生成されます。

今は設計の初期段階であるため、具体化するときに詳しくお伝えします。

SDK デベロッパー

Google は、SDK の非 RE 版と RE 版を単一のアーティファクトに組み込んで配信できるようにする取り組みを進めています。これによりアプリデベロッパーは、RE 版と非 RE 版の両方の SDK で別々のビルドをサポートする必要がなくなります。

アプリと同様に、lint チェック、コンパイル、ビルドを行うためには、アプリストアで配信される依存関係 SDK がマシン上に存在する必要があります。これは、Android Studio によりシームレスに容易に行えるようになることが期待されます。

テスト

アプリデベロッパー

この提案で説明しているとおり、アプリデベロッパーは、Android 13 を搭載したデバイスで通常と同じようにアプリをテストすることが可能です。アプリをビルドしたら、RE デバイスまたはエミュレータにインストールできます。このインストールプロセスでは、SDK がリモート SDK リポジトリから取得されたか、ビルドシステムからキャッシュに保存されたかにかかわらず、デバイスまたはエミュレータの SDK ランタイムに正しい SDK がインストールされます。

SDK デベロッパー

SDK デベロッパーは通常、デバイスとエミュレータ上で自社のテストアプリを使用して開発内容をテストします。この点については、今回の提案で変更されることはありません。アプリ内検証は上述のアプリデベロッパー向けの手順と同様に実施でき、RE アプリと非 RE アプリの両方に単一のビルドアーティファクトが使用されます。SDK デベロッパーは、SDK ランタイムかどうかにかかわらず、コードをステップスルーできます。ただし、高度なデバッグツールやプロファイリングツールには制約の生じる場合があります。これについては現在調査中です。

配信

アプリの SDK からの分離を提案することで、SDK をアプリストアで配布することが可能になります。これは特定のアプリストアに限ったことではなく、全体として可能です。次のようなメリットがあります。

SDK の品質と一貫性が確保されます。
SDK デベロッパー向けのパブリケーションが合理化されます。
SDK のマイナーバージョンアップデートがインストール済みのアプリに迅速にロールアウトされます。

SDK の配信をサポートするには、アプリストアで以下の機能をほぼすべて提供する必要があります。

SDK デベロッパーが、アプリストアで配信可能な SDK をストアにアップロードし、アップデートやロールバックを行い、場合によっては削除を行うメカニズム。
SDK とその提供元、アプリとその提供元の整合性を確保し、依存関係を解決するメカニズム。
一貫した信頼性を保ち、パフォーマンスの高い方法でデバイスにデプロイするメカニズム。

制限の進化

SDK ランタイムのコードに伴う制限は、今後変更される可能性があります。できます。アプリケーションの互換性を確保するため、これらは変更されません。特定の SDK レベルのメインラインモジュールアップデートによる制限。動作対応するまで保持する targetSdkVersion targetSdkVersion はアプリストアポリシーにより非推奨となりました。 targetSdkVersion のサポート終了は、アプリよりも短い間隔で実施される可能性があります。制限は Android SDK のバージョン間で頻繁に変更されることが予想されます（特に、導入が進んでいます

さらに、Google はカナリアメカニズムを構築してテスターが、次のテストで提案された一連の制限を受けるグループに参加するできます。これにより、適用することもできます。

よくある質問

広告関連の SDK とは何ですか。

広告関連の SDK とは、広告主が所有していないアプリで、営利目的のメッセージを使用したユーザーのターゲティングを促進する SDK です。これには、以降のターゲティング用にユーザーグループを作成できるアナリティクス SDK、広告配信 SDK、広告の不正使用防止 SDK と不正行為防止 SDK、エンゲージメント SDK、アトリビューション SDK などが含まれますが、これらに限定されません。
どのような SDK でも SDK ランタイムで実行できますか？

最初は広告関連の SDK を対象としていますが、広告以外の SDK もプライバシー重視の姿勢を求め、 SDK に関するフィードバックを共有できる実行されていることがわかりますただし、SDK ランタイムはすべての SDK 設計と互換性を持つように設計されているわけではありません。記載されている制限以外にも、SDK ランタイムは、ホスティングアプリとのリアルタイムまたは高スループットの通信を必要とする SDK には適さない可能性があります。
プロセスを Java ベースのランタイム内で分離するのではなく、プロセスを分離することを選んだのはなぜですか。

現在のところ、Java ベースのランタイムでは、 Android で求められるプライバシー保証に必要な境界できます。実装するには数年にわたる取り組みが必要となり、成功する保証もありません。そのため、プライバシーサンドボックスでは、実績があり、理解の進んでいる技術であるプロセス境界を使用しています。
SDK を SDK ランタイムプロセスに移行すると、ダウンロードサイズやディスク容量を節約できますか？

複数のアプリを同じバージョンのランタイム対応 SDK と統合すると、ダウンロードサイズとディスク容量を節約できます。
アプリのライフサイクルイベントの種類（アプリが SDK は SDK ランタイムでアクセスできますか？

私たちはアプリレベルで SDK ランタイムに通知する設計のサポートに積極的に取り組んでいるライフサイクルイベント（例: アプリがバックグラウンドに移行し、アプリがフォアグラウンドに移る場合）。設計とサンプルコードは、リリース予定です

あなたへのおすすめ

注: JavaScript がオフになっている場合はリンクテキストが表示されます
SDK ランタイムデベロッパーガイド

SDK ランタイムの概要

目標

独立したプロセスで SDK を実行する

信頼性の高い新しい SDK 配信モデル

SDK とアプリのビルド、実行、配信方法の変更

アクセス

SDK の権限

メモリ

ストレージ

実行

コード

SELinux

API

Lifecycle

特別な場合

メディアのレンダリング

システムの健全性

通信

アプリ～SDK 間

SDK～SDK 間

アプリ～アプリ間

マニフェスト タグ

アクティビティのサポート

開発

オーサリング

アプリ デベロッパー

SDK デベロッパー

ビルド

アプリ デベロッパー

SDK デベロッパー

テスト

アプリ デベロッパー

SDK デベロッパー

配信

制限の進化

よくある質問

あなたへのおすすめ

マニフェストタグ

アプリデベロッパー

アプリデベロッパー

アプリデベロッパー