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

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

Intent は、別のアプリコンポーネントからアクションをリクエストするために使用できるメッセージングオブジェクトです。インテントを使用すると、コンポーネント間の通信をさまざまな方法で容易にできますが、基本的なユースケースは 3 つあります。

アクティビティの開始
Activity はアプリ内の 1 つの画面を表します。Intent を startActivity() に渡すことで、Activity の新しいインスタンスを開始できます。Intent は、開始するアクティビティを記述し、必要なデータを運ぶものです。

アクティビティの終了時にアクティビティから結果を受け取るには、startActivityForResult() を呼び出します。アクティビティは、アクティビティの onActivityResult() コールバックで、結果を別の Intent オブジェクトとして受け取ります。詳しくは、アクティビティガイドをご覧ください。
サービスの開始
Service は、ユーザーインターフェースなしでバックグラウンドでオペレーションを実行するコンポーネントです。Android 5.0（API レベル 21）以降では、JobScheduler を使用してサービスを開始できます。JobScheduler の詳細については、API-reference documentation をご覧ください。

Android 5.0（API レベル 21）より前のバージョンでは、Service クラスのメソッドを使用してサービスを開始できます。Intent を startService() に渡すことで、サービスを開始して 1 回限りのオペレーション（ファイルのダウンロードなど）を実行できます。Intent は、起動するサービスを記述し、必要なデータを運ぶ。

サービスがクライアントサーバーインターフェースで設計されている場合は、Intent を bindService() に渡すことで、別のコンポーネントからサービスにバインドできます。詳細については、サービスガイドをご覧ください。
ブロードキャストの配信
ブロードキャストは、どのアプリでも受信できるメッセージです。システムは、システムの起動やデバイスの充電開始など、システムイベントに関するさまざまなブロードキャストを配信します。Intent を sendBroadcast() または sendOrderedBroadcast() に渡すことで、他のアプリにブロードキャストを配信できます。

このページの残りの部分では、インテントの仕組みと使用方法について説明します。関連情報については、他のアプリと連携するとコンテンツを共有するをご覧ください。

インテントの種類

インテントには次の 2 種類があります。

明示的インテントでは、完全な ComponentName を指定して、インテントを満たすアプリのコンポーネントを指定します。通常、起動するアクティビティまたはサービスのクラス名がわかっているため、明示的インテントを使用して自分のアプリ内のコンポーネントを起動します。たとえば、ユーザーの操作に応じてアプリ内で新しいアクティビティを開始したり、サービスを開始してバックグラウンドでファイルをダウンロードしたりできます。
暗黙的インテントは、特定のコンポーネントに名前を付けるのではなく、実行する一般的なアクションを宣言します。これにより、別のアプリのコンポーネントがそのアクションを処理できます。たとえば、地図上の場所をユーザーに表示する場合は、暗黙的インテントを使用して、対応している別のアプリに指定した場所を地図上に表示するようリクエストできます。

図 1 は、アクティビティの開始時にインテントがどのように使用されるかを示しています。Intent オブジェクトで特定のアクティビティコンポーネントの名前を明示的に指定すると、システムはすぐにそのコンポーネントを起動します。

図 1. 暗黙的インテントがシステムを介して配信され、別のアクティビティが開始される仕組み: [1] アクティビティ A は、アクションの説明を含む Intent を作成し、startActivity() に渡します。[2] Android システムは、インテントフィルタがインテントに対応しているアプリをすべて検索します。一致が見つかった場合、[3] システムは、一致するアクティビティ（アクティビティ B）の onCreate() メソッドを呼び出して Intent を渡すことで、そのアクティビティを開始します。

暗黙的インテントを使用すると、Android システムは、デバイス上の他のアプリのマニフェストファイルで宣言されているインテントフィルタとインテントの内容を比較して、起動する適切なコンポーネントを見つけます。インテントがインテントフィルタと一致する場合、システムはそのコンポーネントを開始し、Intent オブジェクトをそのコンポーネントに渡します。複数のインテントフィルタが互換性がある場合は、システムはダイアログを表示して、ユーザーが使用するアプリを選択できるようにします。

インテントフィルタは、コンポーネントが受け取るインテントのタイプを指定するアプリのマニフェストファイル内の式です。たとえば、アクティビティのインテントフィルタを宣言すると、他のアプリが特定の種類のインテントを使用してアクティビティを直接起動できるようになります。同様に、アクティビティのインテントフィルタを宣言しない場合、そのアクティビティは明示的なインテントを使用してのみ開始できます。

注意: アプリの安全性を確保するため、Service の起動には必ず明示的インテントを使用します。このサービスにはインテントフィルタを宣言しないでください。暗黙的インテントを使用してサービスを開始すると、どのサービスがインテントに応答するのかを把握できず、ユーザーにはどのサービスが開始するのかがわからないため、セキュリティ上の危険が伴います。Android 5.0（API レベル 21）以降では、暗黙的インテントを使用して bindService() を呼び出すと、システムから例外がスローされます。

インテントの作成

Intent オブジェクトには、Android システムが起動するコンポーネントを決定するために使用する情報（インテントを受信する正確なコンポーネント名やコンポーネントカテゴリなど）と、受信側のコンポーネントがアクションを適切に実行するために使用する情報（実行するアクションや対象データなど）が含まれます。

Intent に含まれる主な情報は次のとおりです。

コンポーネント名

起動するコンポーネントの名前。

これは省略可能ですが、インテントを明示的にする重要な情報です。つまり、インテントはコンポーネント名で定義されたアプリコンポーネントにのみ配信する必要があります。コンポーネント名がない場合、インテントは暗黙的になり、システムは他のインテント情報（アクション、データ、カテゴリなど。後述）に基づいて、インテントを受け取るコンポーネントを決定します。アプリで特定のコンポーネントを起動する必要がある場合は、コンポーネント名を指定する必要があります。

注: Service を開始するときは、必ずコンポーネント名を指定してください。そうでない場合、どのサービスがインテントに応答するのかを把握できず、ユーザーにはどのサービスが起動するのかがわからないため、セキュリティ上の危険が伴います。

Intent のこのフィールドは ComponentName オブジェクトです。これは、アプリのパッケージ名を含むターゲットコンポーネントの完全修飾クラス名を使用して指定できます（例: com.example.ExampleActivity）。コンポーネント名は、setComponent()、setClass()、setClassName()、または Intent コンストラクタで設定できます。

操作

実行する汎用アクションを指定する文字列（「表示」や「選択」など）。

ブロードキャストインテントの場合、これは発生したアクションであり、報告されています。アクションによって、インテントの残りの部分の構造（特にデータとエクストラに含まれる情報）が大きく決まります。

アプリ内のインテント（または他のアプリがアプリ内のコンポーネントを呼び出すために使用する）で使用する独自のアクションを指定できますが、通常は Intent クラスまたは他のフレームワーククラスで定義されたアクション定数を指定します。アクティビティを開始する一般的なアクションを次に示します。

ACTION_VIEW: ギャラリーアプリで表示する写真や、地図アプリで表示する住所など、アクティビティでユーザーに表示できる情報がある場合は、startActivity() を使用してインテントでこのアクションを使用します。
ACTION_SEND: 共有インテントとも呼ばれます。ユーザーが別のアプリ（メールアプリやソーシャル共有アプリなど）で共有できるデータがある場合は、startActivity() を含むインテントで使用する必要があります。

汎用アクションを定義するその他の定数については、Intent クラスのリファレンスをご覧ください。その他のアクションは、Android フレームワークの他の場所（システムの設定アプリで特定の画面を開くアクションの場合は Settings など）で定義されています。

インテントのアクションは、setAction() または Intent コンストラクタで指定できます。

独自のアクションを定義する場合は、次の例に示すように、アプリのパッケージ名を接頭辞として含めるようにしてください。

Kotlin

const val ACTION_TIMETRAVEL = "com.example.action.TIMETRAVEL"

Java

static final String ACTION_TIMETRAVEL = "com.example.action.TIMETRAVEL";

データ

処理対象のデータまたはそのデータの MIME タイプを参照する URI（Uri オブジェクト）。通常、提供されるデータのタイプは、インテントのアクションによって決まります。たとえば、アクションが ACTION_EDIT の場合、データには編集するドキュメントの URI を含める必要があります。

インテントを作成する際は、URI に加えてデータのタイプ（MIME タイプ）を指定することが重要です。たとえば、画像を表示できるアクティビティは、URI の形式が類似していても、音声ファイルを再生できない可能性があります。データの MIME タイプを指定すると、Android システムがインテントを受け取るのに最適なコンポーネントを見つけやすくなります。ただし、MIME タイプは URI から推測できる場合もあります（特に、データが content: URI の場合）。content: URI は、データがデバイス上にあり、ContentProvider によって制御されていることを示します。これにより、データの MIME タイプがシステムに表示されます。

データ URI のみを設定するには、setData() を呼び出します。MIME タイプのみを設定するには、setType() を呼び出します。必要に応じて、setDataAndType() を使用して両方を明示的に設定できます。

注意: URI と MIME タイプの両方を設定する場合は、setData() と setType() を呼び出さないでください。どちらも他方の値を無効にするためです。常に setDataAndType() を使用して URI と MIME タイプの両方を設定します。

カテゴリ

インテントを処理するコンポーネントの種類に関する追加情報を含んだ文字列。カテゴリ記述は任意の数をインテントに配置できますが、ほとんどのインテントではカテゴリは必要ありません。一般的なカテゴリは次のとおりです。

CATEGORY_BROWSABLE: ターゲットアクティビティは、ウェブブラウザによって起動され、リンクによって参照されるデータ（画像やメールメッセージなど）を表示できます。
CATEGORY_LAUNCHER: このアクティビティはタスクの初期アクティビティであり、システムのアプリランチャーに表示されます。

カテゴリの完全なリストについては、Intent クラスの説明をご覧ください。

カテゴリは addCategory() で指定できます。

上記のプロパティ（コンポーネント名、アクション、データ、カテゴリ）は、インテントの定義的な特性を表します。これらのプロパティを読み取ることで、Android システムは、起動するアプリコンポーネントを解決できます。ただし、インテントには、アプリコンポーネントへの解決方法には影響しない追加情報を含めることができます。インテントには、次の情報を指定することもできます。

おまけ

リクエストされたアクションの実行に必要な追加情報を提供する Key-Value ペア。一部のアクションが特定の種類のデータ URI を使用するように、一部のアクションは特定のエクストラも使用します。

さまざまな putExtra() メソッドを使用して追加データを追加できます。各メソッドは、キー名と値の 2 つのパラメータを受け取ります。余分なデータをすべて含む Bundle オブジェクトを作成し、putExtras() を使用して Intent に Bundle を挿入することもできます。

たとえば、ACTION_SEND を使用してメールを送信するインテントを作成する場合は、EXTRA_EMAIL キーでto 受信者を指定し、EXTRA_SUBJECT キーでsubject を指定できます。

Intent クラスは、標準化されたデータ型の多くの EXTRA_* 定数を指定します。独自の追加キーを宣言する必要がある場合（アプリが受け取るインテントの場合）は、次の例に示すように、アプリのパッケージ名を接頭辞として含める必要があります。

Kotlin

const val EXTRA_GIGAWATTS = "com.example.EXTRA_GIGAWATTS"

Java

static final String EXTRA_GIGAWATTS = "com.example.EXTRA_GIGAWATTS";

注意: 別のアプリが受信することを想定したインテントを送信する場合は、Parcelable データまたは Serializable データを使用しないでください。アプリが Bundle オブジェクトのデータにアクセスしようとしたが、パーセル化されたクラスまたはシリアル化されたクラスにアクセスできない場合、システムは RuntimeException を発生させます。

フラグ

フラグは、インテントのメタデータとして機能する Intent クラスで定義されます。フラグは、アクティビティの起動方法（アクティビティが属するタスクなど）や、起動後の処理方法（最近のアクティビティのリストに属するかどうかなど）を Android システムに指示します。

詳細については、setFlags() メソッドをご覧ください。

明示的インテントの例

明示的インテントは、アプリ内の特定のアクティビティやサービスなど、特定のアプリコンポーネントを起動するために使用します。明示的インテントを作成するには、Intent オブジェクトのコンポーネント名を定義します。他のインテントプロパティはすべて省略可能です。

たとえば、ウェブからファイルをダウンロードするように設計された DownloadService という名前のサービスをアプリ内に作成した場合は、次のコードで起動できます。

Kotlin

// Executed in an Activity, so 'this' is the Context
// The fileUrl is a string URL, such as "http://www.example.com/image.png"
val downloadIntent = Intent(this, DownloadService::class.java).apply {
    data = Uri.parse(fileUrl)
}
startService(downloadIntent)

Java

// Executed in an Activity, so 'this' is the Context
// The fileUrl is a string URL, such as "http://www.example.com/image.png"
Intent downloadIntent = new Intent(this, DownloadService.class);
downloadIntent.setData(Uri.parse(fileUrl));
startService(downloadIntent);

Intent(Context, Class) コンストラクタは、アプリ Context とコンポーネントに Class オブジェクトを供給します。そのため、このインテントはアプリ内の DownloadService クラスを明示的に起動します。

サービスの構築と起動の詳細については、サービスガイドをご覧ください。

暗黙的インテントの例

暗黙的インテントでは、アクションを実行できるデバイス上の任意のアプリを呼び出すアクションを指定します。アプリでアクションを実行できないが、他のアプリで実行できる可能性があり、どのアプリを使用するかユーザーに選択してほしい場合は、暗黙的インテントを使用すると便利です。

たとえば、ユーザーが他のユーザーと共有するコンテンツがある場合は、ACTION_SEND アクションを使用してインテントを作成し、共有するコンテンツを指定するエクストラを追加します。そのインテントを使用して startActivity() を呼び出すと、ユーザーはコンテンツを共有するアプリを選択できます。

Kotlin

// Create the text message with a string.
val sendIntent = Intent().apply {
    action = Intent.ACTION_SEND
    putExtra(Intent.EXTRA_TEXT, textMessage)
    type = "text/plain"
}

// Try to invoke the intent.
try {
    startActivity(sendIntent)
} catch (e: ActivityNotFoundException) {
    // Define what your app should do if no activity can handle the intent.
}

Java

// Create the text message with a string.
Intent sendIntent = new Intent();
sendIntent.setAction(Intent.ACTION_SEND);
sendIntent.putExtra(Intent.EXTRA_TEXT, textMessage);
sendIntent.setType("text/plain");

// Try to invoke the intent.
try {
    startActivity(sendIntent);
} catch (ActivityNotFoundException e) {
    // Define what your app should do if no activity can handle the intent.
}

startActivity() が呼び出されると、システムはインストールされているすべてのアプリを調べて、この種のインテント（ACTION_SEND アクションを持つインテントで、「text/plain」データを伝送するインテント）を処理できるアプリを特定します。処理できるアプリが 1 つだけの場合は、そのアプリがすぐに開き、インテントが渡されます。他のアプリが処理できない場合、アプリは発生した ActivityNotFoundException をキャッチできます。複数のアクティビティがインテントを受け入れる場合、図 2 のようなダイアログが表示され、ユーザーが使用するアプリを選択できます。

他のアプリの起動について詳しくは、ユーザーを別のアプリに誘導するに関するガイドをご覧ください。

図 2. チューザダイアログ

アプリ選択ツールを強制的に表示する

暗黙的インテントに応答するアプリが複数ある場合、ユーザーは使用するアプリを選択して、そのアプリをアクションのデフォルトとして選択できます。デフォルトを選択する機能は、ウェブページを開くときなど、ユーザーが毎回同じアプリを使用することを希望している場合に便利です（多くのユーザーは、1 つのウェブブラウザだけを使用します）。

ただし、複数のアプリがインテントに応答でき、ユーザーが毎回異なるアプリを使用する可能性がある場合は、選択ツールのダイアログを明示的に表示する必要があります。チューザダイアログでは、ユーザーにアクションに使用するアプリを選択するよう求めるメッセージが表示されます（アクションのデフォルトアプリを選択することはできません）。たとえば、アプリが ACTION_SEND アクションで「共有」を実行する場合、ユーザーは現在の状況に応じて別のアプリを使用して共有したいと考える可能性があるので、図 2 に示すように、常に選択ツールダイアログを使用する必要があります。

チューザを表示するには、次の例に示すように、createChooser() を使用して Intent を作成し、startActivity() に渡します。この例では、createChooser() メソッドに渡されたインテントに応答するアプリのリストを含むダイアログを表示し、指定されたテキストをダイアログのタイトルとして使用します。

Kotlin

val sendIntent = Intent(Intent.ACTION_SEND)
...

// Always use string resources for UI text.
// This says something like "Share this photo with"
val title: String = resources.getString(R.string.chooser_title)
// Create intent to show the chooser dialog
val chooser: Intent = Intent.createChooser(sendIntent, title)

// Verify the original intent will resolve to at least one activity
if (sendIntent.resolveActivity(packageManager) != null) {
    startActivity(chooser)
}

Java

Intent sendIntent = new Intent(Intent.ACTION_SEND);
...

// Always use string resources for UI text.
// This says something like "Share this photo with"
String title = getResources().getString(R.string.chooser_title);
// Create intent to show the chooser dialog
Intent chooser = Intent.createChooser(sendIntent, title);

// Verify the original intent will resolve to at least one activity
if (sendIntent.resolveActivity(getPackageManager()) != null) {
    startActivity(chooser);
}

インテントの安全でない起動を検出する

アプリは、アプリ内のコンポーネント間を移動するため、または別のアプリに代わってアクションを実行するため、インテントを起動することがあります。Android 12（API レベル 31）以降では、プラットフォームのセキュリティを強化するため、アプリがインテントの安全でない起動を実行したときに警告するデバッグ機能が導入されました。たとえば、アプリがネストされたインテントの安全でない起動を実行する場合があります。ネストされたインテントとは、別のインテント内でエクストラとして渡されるインテントのことです。

アプリが次のアクションの両方を実行すると、システムによってインテントの安全でない起動が検出され、StrictMode 違反が発生します。

配信されたインテントのエクストラから、ネストされたインテントを取り出した。
そのネストされたインテントを使用して（たとえば startActivity()、startService()、または bindService() にインテントを渡して）、アプリコンポーネントを直ちに開始した。

この状況を識別してアプリに変更を加える方法について詳しくは、Medium の Android のネストインテントに関するブログ記事をご覧ください。

インテントの安全でない起動を確認する

アプリでの安全でないインテントの起動を確認するには、VmPolicy を構成する際に detectUnsafeIntentLaunch() を呼び出します。次のコードスニペットをご覧ください。アプリで StrictMode 違反が検出された場合は、機密に該当する可能性がある情報を保護するために、アプリの実行を停止することをおすすめします。

Kotlin

fun onCreate() {
    StrictMode.setVmPolicy(VmPolicy.Builder()
        // Other StrictMode checks that you've previously added.
        // ...
        .detectUnsafeIntentLaunch()
        .penaltyLog()
        // Consider also adding penaltyDeath()
        .build())
}

Java

protected void onCreate() {
    StrictMode.setVmPolicy(new VmPolicy.Builder()
        // Other StrictMode checks that you've previously added.
        // ...
        .detectUnsafeIntentLaunch()
        .penaltyLog()
        // Consider also adding penaltyDeath()
        .build());
}

より厳格なインテントの使い方

安全でないインテントの起動や StrictMode 違反の発生を最小限に抑えるには、次のベストプラクティスに従ってください。

インテント内の必須のエクストラのみをコピーして、必要なサニタイズと検証を行います。アプリは、あるインテントから、新しいコンポーネントの起動に使用される別のインテントに、エクストラをコピーすることがあります。これは、アプリが putExtras(Intent) または putExtras(Bundle) を呼び出したときに発生します。アプリがこれらのオペレーションのいずれかを実行する場合、受信コンポーネントで想定されるエクストラのみをコピーします。コピーを受信するインテントがエクスポートされていないコンポーネントを起動する場合は、エクストラをサニタイズして検証してから、コンポーネントを起動するインテントにコピーします。

アプリのコンポーネントを不必要にエクスポートしないでください。たとえば、内部ネストされたインテントを使用してアプリコンポーネントを起動する場合は、そのコンポーネントの android:exported 属性を false に設定します。

ネストされたインテントではなく PendingIntent を使用してください。この方法では、別のアプリがそのアプリの Intent の PendingIntent をアンパックすると、そのアプリの識別子を使用して PendingIntent を起動できます。この構成により、他のアプリは、アプリ内の任意のコンポーネント（エクスポートされていないコンポーネントを含む）を安全に起動できます。

図 2 の図は、システムが（クライアント）アプリから別の（サービス）アプリに制御を渡し、アプリに戻す方法を示しています。

アプリは、別のアプリのアクティビティを呼び出すインテントを作成します。そのインテント内に、PendingIntent オブジェクトをエクストラとして追加します。このペンディングインテントは、アプリ内のコンポーネントを呼び出します。このコンポーネントはエクスポートされていません。
アプリのインテントを受け取ると、他のアプリはネストされた PendingIntent オブジェクトを抽出します。
他のアプリが PendingIntent オブジェクトで send() メソッドを呼び出します。
アプリに制御を戻した後、システムはアプリのコンテキストを使用して保留中のインテントを呼び出します。

図 2. ネストされたペンディングインテントを使用する場合のアプリ間通信の図。

暗黙的インテントの受信

アプリが受け取れる暗黙的インテントをアドバタイズするには、マニフェストファイルで <intent-filter> 要素を使用して、アプリコンポーネントごとに 1 つ以上のインテントフィルタを宣言します。各インテントフィルタは、インテントのアクション、データ、カテゴリに基づいて、受け入れるインテントのタイプを指定します。システムは、インテントがいずれかのインテントフィルタを通過できる場合にのみ、アプリコンポーネントに暗黙的インテントを配信します。

注: 明示的インテントは、コンポーネントが宣言するインテントフィルタに関係なく、常にターゲットに配信されます。

アプリコンポーネントは、実行できる一意のジョブごとに個別のフィルタを宣言する必要があります。たとえば、画像ギャラリーアプリの 1 つのアクティビティには、画像を表示するフィルタと画像を編集するフィルタの 2 つのフィルタがあります。アクティビティの開始時に、Intent が検査され、Intent の情報に基づいて動作方法が決定されます（エディタコントロールを表示するかどうかなど）。

各インテントフィルタは、アプリのマニフェストファイル内の <intent-filter> 要素で定義され、対応するアプリコンポーネント（<activity> 要素など）にネストされます。

<intent-filter> 要素を含む各アプリコンポーネントで、android:exported の値を明示的に設定します。この属性は、アプリコンポーネントに他のアプリがアクセスできるかどうかを示します。インテントフィルタに LAUNCHER カテゴリが含まれているアクティビティなど、この属性を true に設定すると便利な場合があります。それ以外の場合は、この属性を false に設定することをおすすめします。

警告: アプリ内のアクティビティ、サービス、ブロードキャストレシーバがインテントフィルタを使用し、android:exported の値を明示的に設定していない場合、Android 12 以降を実行しているデバイスにアプリをインストールできません。

<intent-filter> 内で、次の 3 つの要素の 1 つ以上を使用して、受け入れるインテントのタイプを指定できます。

<action>: name 属性で、受け入れるインテントアクションを宣言します。値は、クラス定数ではなく、アクションのリテラル文字列値にする必要があります。
<data>: データ URI のさまざまな要素（scheme、host、port、path）と MIME タイプを指定する 1 つ以上の属性を使用して、受け入れ可能なデータのタイプを宣言します。
<category>: name 属性で、受け入れるインテントカテゴリを宣言します。値は、クラス定数ではなく、アクションのリテラル文字列値にする必要があります。
注: 暗黙的インテントを受け取るには、インテントフィルタに CATEGORY_DEFAULT カテゴリを含める必要があります。startActivity() メソッドと startActivityForResult() メソッドは、CATEGORY_DEFAULT カテゴリを宣言しているものとして、すべてのインテントを処理します。インテントフィルタでこのカテゴリを宣言していない場合、暗黙的インテントはアクティビティに変換されません。

たとえば、データ型がテキストの場合に ACTION_SEND インテントを受け取るインテントフィルタを含むアクティビティの宣言は次のようになります。

<activity android:name="ShareActivity" android:exported="false">
    <intent-filter>
        <action android:name="android.intent.action.SEND"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <data android:mimeType="text/plain"/>
    </intent-filter>
</activity>

<action>、<data>、<category> の複数のインスタンスが含まれるフィルタを作成できます。複数のフィルタ要素を使用する場合は、コンポーネントがそれらのフィルタ要素のあらゆる組み合わせを処理できることを確認する必要があります。

複数種類のインテントを処理する場合でも、アクション、データ、カテゴリタイプの特定の組み合わせでのみ処理する場合は、複数のインテントフィルタを作成する必要があります。

暗黙的インテントは、インテントを 3 つの要素のそれぞれと比較することで、フィルタに対してテストされます。コンポーネントに配信されるには、インテントが 3 つのテストすべてに合格する必要があります。いずれか 1 つでも一致しなかった場合、Android システムはコンポーネントにインテントを配信しません。ただし、コンポーネントには複数のインテントフィルタがある可能性があるため、コンポーネントのフィルタのいずれかを通過しなかったインテントが、別のフィルタで通過する可能性があります。システムがインテントを解決する方法について詳しくは、インテントの解決のセクションをご覧ください。

注意: インテントフィルタを使用することは、他のアプリがコンポーネントを起動しないようにするための安全な方法ではありません。インテントフィルタは、コンポーネントが特定の種類の暗黙的なインテントのみに対応するように制限しますが、デベロッパーがコンポーネント名を決定した場合、別のアプリが明示的なインテントを使用してアプリコンポーネントを起動する可能性があります。独自のアプリのみがコンポーネントを起動できるようにすることが重要である場合は、マニフェストでインテントフィルタを宣言しないでください。代わりに、そのコンポーネントの exported 属性を "false" に設定します。

同様に、別のアプリの Service を誤って実行しないように、常に明示的インテントを使用して独自のサービスを開始します。

注: すべてのアクティビティについて、マニフェストファイルでインテントフィルタを宣言する必要があります。ただし、ブロードキャストレシーバのフィルタは、registerReceiver() を呼び出すことで動的に登録できます。その後、unregisterReceiver() を使用してレシーバの登録を解除できます。これにより、アプリの実行中に特定のブロードキャストを特定の期間のみリッスンできます。

フィルタの例

インテントフィルタの動作の例として、ソーシャル共有アプリのマニフェストファイルの例を以下に示します。

<activity android:name="MainActivity" android:exported="true">
    <!-- This activity is the main entry, should appear in app launcher -->
    <intent-filter>
        <action android:name="android.intent.action.MAIN" />
        <category android:name="android.intent.category.LAUNCHER" />
    </intent-filter>
</activity>

<activity android:name="ShareActivity" android:exported="false">
    <!-- This activity handles "SEND" actions with text data -->
    <intent-filter>
        <action android:name="android.intent.action.SEND"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <data android:mimeType="text/plain"/>
    </intent-filter>
    <!-- This activity also handles "SEND" and "SEND_MULTIPLE" with media data -->
    <intent-filter>
        <action android:name="android.intent.action.SEND"/>
        <action android:name="android.intent.action.SEND_MULTIPLE"/>
        <category android:name="android.intent.category.DEFAULT"/>
        <data android:mimeType="application/vnd.google.panorama360+jpg"/>
        <data android:mimeType="image/*"/>
        <data android:mimeType="video/*"/>
    </intent-filter>
</activity>

最初のアクティビティ MainActivity は、アプリのメインエントリポイントです。ユーザーがランチャーアイコンでアプリを最初に起動したときに開くアクティビティです。

ACTION_MAIN アクションは、これがメインのエントリポイントであり、インテントデータが想定されていないことを示します。
CATEGORY_LAUNCHER カテゴリは、このアクティビティのアイコンをシステムのアプリランチャーに配置する必要があることを示します。<activity> 要素で icon を使用してアイコンを指定していない場合、システムは <application> 要素のアイコンを使用します。

アクティビティをアプリランチャーに表示するには、これら 2 つをペア設定する必要があります。

2 つ目のアクティビティ ShareActivity は、テキストコンテンツとメディアコンテンツの共有を容易にすることを目的としています。ユーザーは MainActivity からこのアクティビティに移動してアクセスできますが、2 つのインテントフィルタのいずれかに一致する暗黙的インテントを発行する別のアプリから直接 ShareActivity にアクセスすることもできます。

注: MIME タイプ application/vnd.google.panorama360+jpg は、パノラマ写真を指定する特別なデータ型です。このデータ型は、Google パノラマ API で処理できます。

インテントと他のアプリのインテントフィルタを一致させる

別のアプリが Android 13（API レベル 33）以降をターゲットとしている場合、そのアプリは、アプリのインテントがそのアプリの <intent-filter> 要素のアクションとカテゴリと一致する場合にのみ、アプリのインテントを処理できます。一致が見つからない場合、ActivityNotFoundException がスローされます。送信側のアプリはこの例外を処理する必要があります。

同様に、Android 13 以上をターゲットとするようにアプリを更新した場合、外部アプリから発信されるすべてのインテントは、アプリで宣言された <intent-filter> 要素のアクションとカテゴリと一致する場合にのみ、アプリのエクスポート済みコンポーネントに配信されます。この動作は、送信元アプリのターゲット SDK バージョンに関係なく発生します。

以下のケースでは、インテントマッチングは適用されません。

インテントフィルタを宣言していないコンポーネントに配信されるインテント。
同じアプリからのインテント。
システムからのインテント、つまり「システム UID」（uid=1000）から送信されるインテント。システムアプリとしては、system_server と、android:sharedUserId を android.uid.system に設定するアプリがあります。
ルートからのインテント。

詳しくは、インテントマッチングについての記事をご覧ください。

ペンディングインテントを使用する

PendingIntent オブジェクトは、Intent オブジェクトをラップするラッパーです。PendingIntent の主な目的は、アプリ独自のプロセスから実行されているかのように、含まれている Intent を使用する権限を外部アプリに付与することです。

ペンディングインテントの主なユースケースは次のとおりです。

ユーザーが通知でアクションを実行したときに実行されるインテントを宣言する（Android システムの NotificationManager が Intent を実行します）。
ユーザーがアプリウィジェットでアクションを実行したときに実行されるインテントを宣言する（ホーム画面アプリが Intent を実行します）。
指定した将来の時刻に実行されるインテントを宣言する（Android システムの AlarmManager が Intent を実行します）。

各 Intent オブジェクトが特定のタイプのアプリコンポーネント（Activity、Service、BroadcastReceiver）によって処理されるように設計されているように、PendingIntent も同じ考慮事項に基づいて作成する必要があります。ペンディングインテントを使用している場合、アプリは startActivity() などの呼び出しでインテントを実行しません。代わりに、PendingIntent を作成するときに、それぞれの作成者メソッドを呼び出して、目的のコンポーネントタイプを宣言する必要があります。

PendingIntent.getActivity(): Activity を開始する Intent。
Service を開始する Intent の場合は PendingIntent.getService()。
BroadcastReceiver を開始する Intent の場合は PendingIntent.getBroadcast()。

アプリが他のアプリから保留中のインテントを受信している場合を除き、PendingIntent を作成する上記のメソッドは、おそらく必要な唯一の PendingIntent メソッドです。

各メソッドは、現在のアプリ Context、ラップする Intent、インテントの使用方法を指定する 1 つ以上のフラグ（インテントを複数回使用できるかどうかなど）を受け取ります。

保留中のインテントの使用方法については、通知 API ガイドやアプリウィジェット API ガイドなど、それぞれのユースケースのドキュメントをご覧ください。

可変性を指定する

アプリが Android 12 以降をターゲットとしている場合、アプリが作成する各 PendingIntent オブジェクトの可変性を指定する必要があります。特定の PendingIntent オブジェクトが可変または不変であることを宣言するには、PendingIntent.FLAG_MUTABLE フラグまたは PendingIntent.FLAG_IMMUTABLE フラグをそれぞれ使用します。

アプリがどちらの可変性フラグも設定せずに PendingIntent オブジェクトを作成しようとすると、IllegalArgumentException がスローされ、logcat に次のメッセージが表示されます。

PACKAGE_NAME: Targeting S+ (version 31 and above) requires that one of \
FLAG_IMMUTABLE or FLAG_MUTABLE be specified when creating a PendingIntent.

Strongly consider using FLAG_IMMUTABLE, only use FLAG_MUTABLE if \
some functionality depends on the PendingIntent being mutable, e.g. if \
it needs to be used with inline replies or bubbles.

可能な限り不変のペンディングインテントを作成する

ほとんどの場合において、アプリでは不変の PendingIntent オブジェクトを作成するようにしてください（次のコードスニペットを参照）。PendingIntent オブジェクトが不変の場合、他のアプリはそのインテントを変更して、インテント呼び出しの結果を調整することはできません。

Kotlin

val pendingIntent = PendingIntent.getActivity(applicationContext,
        REQUEST_CODE, intent,
        /* flags */ PendingIntent.FLAG_IMMUTABLE)

Java

PendingIntent pendingIntent = PendingIntent.getActivity(getApplicationContext(),
        REQUEST_CODE, intent,
        /* flags */ PendingIntent.FLAG_IMMUTABLE);

ただし、次のユースケースでは可変の PendingIntent オブジェクトが必要です。

通知でのダイレクト返信アクションのサポート。ダイレクト返信では、返信に関連付けられた PendingIntent オブジェクト内のクリップデータの変更が必要です。通常は、fillIn() メソッドに FILL_IN_CLIP_DATA をフラグとして渡すことにより、この変更をリクエストします。
CarAppExtender のインスタンスを使用して、通知を Android Auto フレームワークに関連付ける。
PendingIntent のインスタンスを使用して会話をバブルに配置する。可変の PendingIntent オブジェクトを使用すると、システムは FLAG_ACTIVITY_MULTIPLE_TASK や FLAG_ACTIVITY_NEW_DOCUMENT などの正しいフラグを適用できます。
requestLocationUpdates() などの API を呼び出して、デバイスの位置情報をリクエストする。変更可能な PendingIntent オブジェクトを使用すると、位置情報のライフサイクルイベントを表すインテントエクストラをシステムが追加できます。これらのイベントには、場所の変更やプロバイダの利用可能化が含まれます。
AlarmManager を使用してアラームのスケジュールを設定する。変更可能な PendingIntent オブジェクトを使用すると、システムが EXTRA_ALARM_COUNT インテントエクストラを追加できます。この追加情報は、繰り返しアラートがトリガーされた回数を表します。この追加情報を含めることで、デバイスがスリープ状態のときなど、アラームが複数回トリガーされたかどうかをアプリに正確に通知できます。

アプリで可変の PendingIntent オブジェクトを作成する場合は、明示的インテントを使用して ComponentName の値をフィルインすることを強くおすすめします。そうすれば、別のアプリが PendingIntent を呼び出してアプリに制御を戻すたびに、常にアプリ内の同じコンポーネントが開始されます。

保留中のインテント内で明示的インテントを使用する

他のアプリがアプリのペンディングインテントをどのように使用できるかを明確に定義するには、常にペンディングインテントを明示的インテントでラップします。このベストプラクティスに沿って対応するには、次の手順を行います。

ベースインテントのアクション、パッケージ、コンポーネントの各フィールドが設定されていることを確認します。
Android 6.0（API レベル 23）で追加された FLAG_IMMUTABLE を使用して、保留中のインテントを作成します。このフラグにより、PendingIntent を受信したアプリが未入力プロパティを入力するのを防ぐことができます。アプリの minSdkVersion が 22 以下の場合は、次のコードを使用して安全性と互換性を同時に提供できます。
```
if (Build.VERSION.SDK_INT >= 23) {
  // Create a PendingIntent using FLAG_IMMUTABLE.
} else {
  // Existing code that creates a PendingIntent.
}
```

インテントの解決

システムがアクティビティを開始する暗黙的インテントを受信すると、次の 3 つの要素に基づいてインテントをインテントフィルタと比較し、インテントに最適なアクティビティを検索します。

アクション。
データ（URI とデータ型の両方）。
カテゴリ。

以降のセクションでは、アプリのマニフェストファイルのインテントフィルタ宣言に従って、インテントを適切なコンポーネントに照合する方法について説明します。

アクションテスト

受け入れられるインテントアクションを指定するには、次の例に示すように、インテントフィルタで 0 個以上の <action> 要素を宣言します。

<intent-filter>
    <action android:name="android.intent.action.EDIT" />
    <action android:name="android.intent.action.VIEW" />
    ...
</intent-filter>

このフィルタを通過するには、Intent で指定されたアクションが、フィルタにリストされているアクションのいずれかと一致している必要があります。

フィルタにアクションがリストされていない場合、インテントが一致するアクションがないため、すべてのインテントがテストに失敗します。ただし、Intent でアクションが指定されていない場合、フィルタにアクションが 1 つ以上含まれていれば、テストは合格します。

カテゴリテスト

受け入れ可能なインテントカテゴリを指定するには、インテントフィルタで 0 個以上の <category> 要素を宣言します。次の例をご覧ください。

<intent-filter>
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />
    ...
</intent-filter>

インテントがカテゴリテストに合格するには、Intent 内のすべてのカテゴリがフィルタ内のカテゴリと一致している必要があります。逆は必要ありません。インテントフィルタは、Intent で指定されているよりも多くのカテゴリを宣言しても、Intent は引き続き合格します。したがって、カテゴリのないインテントは、フィルタで宣言されているカテゴリに関係なく、常にこのテストに合格します。

注: Android は、startActivity() と startActivityForResult() に渡されるすべての暗黙的インテントに CATEGORY_DEFAULT カテゴリを自動的に適用します。アクティビティで暗黙的インテントを受け取るには、前の <intent-filter> の例に示すように、インテントフィルタに "android.intent.category.DEFAULT" のカテゴリを含める必要があります。

データテスト

受け入れ可能なインテントデータを指定するには、インテントフィルタで 0 個以上の <data> 要素を宣言します。次の例をご覧ください。

<intent-filter>
    <data android:mimeType="video/mpeg" android:scheme="http" ... />
    <data android:mimeType="audio/mpeg" android:scheme="http" ... />
    ...
</intent-filter>

各 <data> 要素には、URI 構造とデータ型（MIME メディアタイプ）を指定できます。URI の各部分は、scheme、host、port、path の個別の属性です。

<scheme>://<host>:<port>/<path>

次の例は、これらの属性の有効な値を示しています。

content://com.example.project:200/folder/subfolder/etc

この URI では、スキームは content、ホストは com.example.project、ポートは 200、パスは folder/subfolder/etc です。

これらの属性は <data> 要素では省略可能ですが、リニアな依存関係があります。

スキームが指定されていない場合、ホストは無視されます。
ホストが指定されていない場合、ポートは無視されます。
スキームとホストの両方が指定されていない場合、パスは無視されます。

インテント内の URI がフィルタ内の URI 仕様と比較される場合、フィルタに含まれる URI の部分のみが比較されます。次に例を示します。

フィルタでスキームのみが指定されている場合、そのスキームのすべての URI がフィルタに一致します。
フィルタでスキームとオーソリティが指定されていて、パスが指定されていない場合、同じスキームとオーソリティを持つすべての URI が、パスに関係なくフィルタを通過します。
フィルタでスキーム、権限、パスを指定すると、スキーム、権限、パスが同じ URI のみがフィルタを通過します。

注: パスの指定にワイルドカードアスタリスク（*）を含めると、パス名の部分的な一致のみを要求できます。

データテストでは、インテントの URI と MIME タイプの両方を、フィルタで指定された URI と MIME タイプと比較します。ルールは次のとおりです。

URI も MIME タイプも含まれていないインテントは、フィルタで URI または MIME タイプが指定されていない場合にのみ、テストに合格します。
URI は含まれているものの、MIME タイプが指定されていない（明示的でも URI から推測可能でもない）インテントは、URI がフィルタの URI 形式と一致し、フィルタでも MIME タイプが指定されていない場合にのみ、テストに合格します。
MIME タイプは含むが URI を含まないインテントは、フィルタに同じ MIME タイプがリストされ、URI 形式が指定されていない場合にのみ、テストに合格します。
URI と MIME タイプの両方（明示的または URI から推測可能）を含むインテントは、そのタイプがフィルタにリストされているタイプと一致する場合にのみ、テストの MIME タイプ部分に合格します。テストの URI 部分は、URI がフィルタ内の URI と一致する場合、または content: または file: URI があり、フィルタで URI が指定されていない場合に合格します。つまり、フィルタに MIME タイプがのみリストされている場合、コンポーネントは content: データと file: データをサポートしていると見なされます。

注: インテントで URI または MIME タイプが指定されている場合、<intent-filter> に <data> 要素がないと、データテストは失敗します。

この最後のルール（d）は、コンポーネントがファイルまたはコンテンツプロバイダからローカルデータを取得できることを前提としています。したがって、フィルタではデータ型のみを指定でき、content: スキーマと file: スキーマの名前を明示的に指定する必要はありません。次の例は、コンポーネントがコンテンツプロバイダから画像データを取得して表示できることを Android に通知する <data> 要素の一般的なケースを示しています。

<intent-filter>
    <data android:mimeType="image/*" />
    ...
</intent-filter>

利用可能なデータのほとんどはコンテンツプロバイダによって提供されるため、データ型を指定し URI を指定しない場合のフィルタが最も一般的です。

別の一般的な構成は、スキーマとデータ型を持つフィルタです。たとえば、次のような <data> 要素は、コンポーネントがアクションを実行するためにネットワークから動画データを取得できることを Android に伝えます。

<intent-filter>
    <data android:scheme="http" android:mimeType="video/*" />
    ...
</intent-filter>

インテントマッチング

インテントはインテントフィルタと照合され、アクティブにするターゲットコンポーネントを検出するだけでなく、デバイス上のコンポーネントセットに関する情報を検出します。たとえば、Google Home アプリは、ACTION_MAIN アクションと CATEGORY_LAUNCHER カテゴリを指定するインテントフィルタを持つすべてのアクティビティを見つけて、アプリランチャーに表示します。一致は、IntentFilter クラスのドキュメントに記載されているように、インテント内のアクションとカテゴリがフィルタと一致する場合にのみ成功します。

アプリは、Google Home アプリと同様にインテントマッチングを使用できます。PackageManager には、特定のインテントを受け入れることができるすべてのコンポーネントを返す一連の query...() メソッドと、インテントに応答するのに最適なコンポーネントを決定する一連の resolve...() メソッドがあります。たとえば、queryIntentActivities() は引数として渡されたインテントを実行できるすべてのアクティビティのリストを返します。queryIntentServices() は同様のサービスのリストを返します。どちらの方法でもコンポーネントはアクティブになりません。応答できるコンポーネントのみがリストされます。ブロードキャストレシーバには、queryBroadcastReceivers() という同様のメソッドがあります。

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

インテントの種類

インテントの作成

Kotlin

Java

Kotlin

Java

明示的インテントの例

Kotlin

Java

暗黙的インテントの例

Kotlin

Java

アプリ選択ツールを強制的に表示する

Kotlin

Java

インテントの安全でない起動を検出する

インテントの安全でない起動を確認する

Kotlin

Java

より厳格なインテントの使い方

暗黙的インテントの受信

フィルタの例

インテントと他のアプリのインテント フィルタを一致させる

ペンディング インテントを使用する

可変性を指定する

可能な限り不変のペンディング インテントを作成する

Kotlin

Java

保留中のインテント内で明示的インテントを使用する

インテントの解決

アクション テスト

カテゴリテスト

データテスト

インテント マッチング

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

インテントと他のアプリのインテントフィルタを一致させる

ペンディングインテントを使用する

可能な限り不変のペンディングインテントを作成する

アクションテスト

インテントマッチング