Android 版プライバシー サンドボックス デベロッパー プレビューがリリースされました。ご利用方法についてご確認のうえ、引き続きフィードバックをお寄せください

SDK ランタイム

コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

フィードバックを送信

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

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

Android 13 では、サードパーティ SDK を SDK ランタイムという専用のランタイム環境で実行できるようにする、新しいプラットフォーム機能を追加する予定です。SDK ランタイムは、次のように、ユーザーデータの収集と共有に関する安全対策と保証を強化します。

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

目標

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

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

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

今回提案する SDK ランタイムでは、対応している SDK(以下「RE(ランタイム対応)SDK」)を、アプリの別のプロセスで動作するようにします。このプラットフォームにより、アプリのプロセスと SDK ランタイム間の双方向通信が容易になります。詳細については、このドキュメントの通信に関するセクションをご覧ください。非 RE SDK は、現状と同様にアプリのプロセス内に残ります。こうした変更を図 1 に示します。

変更前:


変更後:

図 1. SDK ランタイムへの追加前および追加後のランタイム対応 SDK の相対的な位置関係。1 つ目の「変更前」の図は、SDK を呼び出すコードとその呼び出しを受け取る SDK の両方が、アプリのプロセス内に存在することを示しています。2 つ目の「変更後」の図は、アプリのフォアグラウンド プロセスで、SDK の呼び出しコードが SDK インターフェースと通信することを示しています。これらのインターフェースは、プロセス境界を越えて SDK ランタイム プロセスに含まれ、SDK 自体を呼び出します。

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

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

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

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

この新しい配信メカニズムにより、SDK デベロッパーは、SDK に互換性を破らない変更(API やそのセマンティクスの変更はない)を加え、アプリ デベロッパーの関与なしにデバイスへ配信することができます。このような SDK の互換性を破らない変更については、デプロイやロールバックの際に、アプリ デベロッパーによる新しい SDK でのアプリの再ビルドや、エンドユーザーによるアプリの更新を待つことが必須ではなくなります。互換性を破る変更については、今後もアプリ デベロッパーによる更新が必要ですが、互換性を破らない変更と修正については、SDK デベロッパーが最新の内容をより多くのユーザーに迅速かつ一様に提供でき、しいてはバージョン サポートを最小限に抑えることが望めます。

SDK 配信の変更案を図 2 に示します。

変更前:

変更前の図

変更後:

変更後の図
図 2. SDK ランタイム導入前と導入後の SDK 配信。SDK デベロッパーは、SDK をアプリに直接送信するのではなく、SDK アップロード UI を使用して、SDK をアプリストアに公開するようになります。アプリストアは、SDK の依存関係とともに、エンドユーザー デバイスへのアプリの配信を処理します。

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

この提案は、柔軟な SDK ランタイムと配信技術の実現を目的とした最初のものです。以降のセクションでは、次の幅広いカテゴリにわたる一連の変更について提案します。

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

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

これは初期設計案であり、エコシステムのメンバーにとって重要な変更となる可能性があります。そのため、皆様からのフィードバックをお待ちしています。こちらの Issue Tracker からご意見をお寄せください。

アクセス

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

SDK の権限

SDK ランタイムの場合、ユーザーがアプリに付与した権限を継承するのではなく、別個のプロセスとして、明確に定義された独自の権限セットが用意されることになります。広告関連の SDK が使用する権限についての予備調査結果をふまえ、SDK ランタイムの SDK には、次の権限をデフォルトで利用できるようにすることを提案します。

  • INTERNET: ウェブサービスと通信できるようにするためのインターネット アクセス。
  • ACCESS_NETWORK_STATE: ネットワークに関する情報へのアクセス。
  • クロスアプリ識別子にアクセスすることなく、主要な広告機能を提供できるプライバシー保護 API の利用に関する権限。権限名は未定ですが、この権限に対するアプリのアクセス権によって、この API の利用を制限します。
  • AD_ID: 広告 ID をリクエストする機能。これも、この権限に対するアプリのアクセス権によって制限されます。
  • BIND_GET_INSTALL_REFERRER_SERVICE: Google Play Install Referrer API を使用してアプリのインストール元を特定する機能。

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

メモリ

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

ストレージ

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

  • アプリは SDK のストレージに直接アクセスできない。その逆も同様。
  • デバイスの外部ストレージに SDK からはアクセスできない。
  • 各 SDK ランタイム内に、すべての SDK からアクセス可能なストレージと、特定の SDK 専用のストレージを用意する。

現在のストレージ モデルのように、ストレージ自体のサイズや期間に任意の制限はありません(つまりエフェメラルではなく、アプリのアンインストール時に削除されます)。

実行

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

コード

Android コード(アプリと SDK)は、コードの記述に使用したプログラミング言語が Kotlin か Java かにかかわらず、主に Android ランタイム(ART)によって解釈されます。ART には豊富な機能があり、その言語構造や代替手段(具体的にはネイティブ コード)と比較した場合の検証可能性もふまえると、機能性とプライバシーのバランスが適切に保たれていると考えられます。JNI アクセスをサポートするのではなく、SDK コードを Dex バイトコードのみで構成することを提案します。

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

SELinux

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

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

API

SDK ランタイム内では、リフレクション API と呼び出し API を使用できます。 ただし、別のランタイム対応の SDK でリフレクション API や呼び出し API を使用することはできません。禁止されている API の提案について詳しくは、今後の更新でお知らせします。

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

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

また、RE SDK では、通知 API を使用したユーザー通知の送信がいずれかの時点でできなくなります。

ライフサイクル

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

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

    SDK ランタイムは、関連するアプリより高い優先度で実行されます。そのため、メモリ不足で終了してしまう可能性は、関連するアプリより低くなります。ただし、アプリの実行中に SDK ランタイムが終了する場合(SDK に未処理の例外がある場合など)、関連するライフサイクル コールバック メソッドの使用をアプリ デベロッパーに提案します。これらのメソッドは SDK ランタイムの終了に伴って処理を実行し、SDK ランタイムを再度初期化できるようにします。プロセスが終了すると、SDK ランタイムの状態(以前に読み込まれたすべての SDK とリモートビューを含む)が失われます。

    このライフサイクル モデルは、今後の更新で変更される可能性があります。

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

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

メディアのレンダリング

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

SDK ではなくアプリがレンダリングするネイティブ広告は、SDK ランタイムの SDK でサポートされます。ネイティブ広告以外でも、シグナルの収集処理とクリエイティブの取得処理が一貫して行われます。ただし、SDK によって通常の WebView レンダリングに提供される 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 デベロッパーへの影響を最小限に抑えることを目指しています。検討中のアプローチを図 3 に示します。

図
図 3. アプリと SDK を起動する際のアプリ~SDK 間のインタラクションを示すシーケンス図

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

図 3 のグラフは、マーシャリング レイヤがない下位レベルでのアプリ~SDK 間の通信を示しています。

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

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

    次のコード スニペットに API の例を示します。

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

    バインドされたサービスに関するガイドで、IBinder を提供するさまざまな方法について説明しています。どの方法を採用するとしても、SDK と呼び出し元アプリ間で一貫して使用する必要があります(図 3 のグラフは、AIDL を例として使用しています)。

  3. SdkSandboxManagerIBinder インターフェースを受け取り、アプリに返します。

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

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

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

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

    次のコード スニペットに API の例を示します。

    SdkSandboxManager.requestSurfacePackage(String sdkName, Bundle extraParams,
            Executor executor,
            OutcomeReceiver<Bundle, RequestSurfacePackageException> receiver)
    
  2. アプリは SurfaceView の setChildSurfacePackage API を介して、返された SurfacePackage を SurfaceView に埋め込むことができます。

    次のコード スニペットに API の例を示します。

    SurfaceView.setChildSurfacePackage(SurfacePackage surfacePackage)
    

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

SDK~SDK 間

同じアプリ内の 2 つの SDK 間で通信を行う必要があるケースです。このケースは、ある SDK が、構成要素 SDK で構成されるように設計されている場合に生じる可能性があります。また、呼び出し元アプリからのリクエストに対応するために、異なる当事者の 2 つの SDK が連携する必要がある場合にも生じる可能性があります。

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

  • 両方の SDK が RE の場合: この場合、両方の SDK が SDK ランタイムで実行され、すべての保護が適用されます。SDK は、現在アプリ内で行っているような通信を行うことができません。そのため、通信が容易になるように、SDK ランタイムの SDK で、SDK の登録と検出が行えるように設計しています。
  • 一方の SDK のみが RE の場合:
    • 呼び出し元 SDK がアプリ内で実行されている場合は、SDK ランタイム内の 2 番目の SDK をアプリ自体が呼び出す場合と同じように動作します。
    • 呼び出し元 SDK が SDK ランタイム内で実行されている場合については、アプリ~SDK 間のセクションで説明されている IBinder を使用してメソッドを公開することを提案します。この呼び出しでは、指定のコールバックを使用して、アプリのコードでリッスン、処理、応答を行います。これは現在調査中です。

こうしたプリミティブを設計するにあたり、次のユースケースを考慮しています。

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

アプリ~アプリ間

これはアプリ間通信であり、通信する 2 つのプロセスのうち、少なくとも 1 つが RE SDK になります。アプリ間通信であることから、一般的に非公開のデータ共有の仲介に使用されます。

そのため、SDK ランタイムは、ブロードキャストやインテントを含め、いかなる手段によっても他のアプリプロセスと通信できなくなります。その結果、SDK ランタイム内の SDK はいずれも、他のアプリや、他のアプリがホストする RE SDK と通信できなくなります。

開発

この提案の基本方針は、デベロッパー エコシステムへの影響を可能な限り最小限に抑えることです。そのため、RE アプリと SDK の記述、ビルド、デバッグを行うための包括的な開発ツールセットのデベロッパーへの提供を提案します。ただし、提案の整合性を確保するため、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 環境に対応できるようにするためのアプローチに取り組んでいます。

ビルド

アプリ デベロッパー

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

デバッグビルドでは、デバッグを可能にするためにすべてのコードとシンボルをデバッグビルドに含める必要があります。一方、リリースビルドでは必要に応じて、アプリストアで配信されるすべての 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 とその提供元、アプリとその提供元の整合性を確保し、依存関係を解決するメカニズム。
  • 一貫した信頼性を保ち、パフォーマンスの高い方法でデバイスにデプロイするメカニズム。

よくある質問

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

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

  2. どのような SDK でも SDK ランタイムで実行できますか?

    当初の対象は広告関連の SDK ですが、広告関連以外の SDK でプライバシーを重視し、上述の要件で運用できるとお考えのデベロッパーは、SDK ランタイムでの SDK の運用についてフィードバックをお送りください。ただし、SDK ランタイムはすべての SDK 設計と互換性を持つように設計されているわけではありません。記載されている制限以外にも、SDK ランタイムは、ホスティング アプリとのリアルタイムまたは高スループットの通信を必要とする SDK には適さない可能性があります。

  3. プロセスを Java ベースのランタイム内で分離するのではなく、プロセスを分離することを選んだのはなぜですか。

    現時点では、Android ユーザーに提供しようとしているプライバシーの確保に必要なセキュリティ境界を、Java ベースのランタイムによって提供することは容易ではありません。実装するには数年にわたる取り組みが必要となり、成功する保証もありません。そのため、プライバシー サンドボックスでは、実績があり、理解の進んでいる技術であるプロセス境界を使用しています。

  4. SDK を SDK ランタイム プロセスに移行すると、ダウンロード サイズやディスク容量を節約できますか?

    複数のアプリを同じバージョンのランタイム対応 SDK と統合すると、ダウンロード サイズとディスク容量を節約できます。