Intents und Intent-Filter

Ein Intent ist ein Messaging-Objekt, mit dem Sie eine Aktion von einer anderen App-Komponente anfordern können. Intents erleichtern die Kommunikation zwischen Komponenten auf verschiedene Weise. Es gibt jedoch drei grundlegende Anwendungsfälle:

• Aktivität starten

  Eine Activity stellt einen einzelnen Bildschirm in einer App dar. Sie können eine neue Instanz einer Activity starten, indem Sie eine Intent an startActivity() übergeben. Der Intent beschreibt die zu startende Aktivität und enthält alle erforderlichen Daten.

  Wenn Sie nach Abschluss der Aktivität ein Ergebnis erhalten möchten, rufen Sie startActivityForResult() auf. Ihre Aktivität erhält das Ergebnis als separates Intent-Objekt im onActivityResult()-Callback Ihrer Aktivität. Weitere Informationen finden Sie im Leitfaden zu Aktivitäten.

• Dienst starten

  Ein Service ist eine Komponente, die Vorgänge im Hintergrund ohne Benutzeroberfläche ausführt. Ab Android 5.0 (API-Level 21) können Sie einen Dienst mit JobScheduler starten. Weitere Informationen zu JobScheduler finden Sie in der entsprechenden API-reference documentation.

  Bei Versionen vor Android 5.0 (API-Level 21) können Sie einen Dienst mit Methoden der Klasse Service starten. Sie können einen Dienst starten, um einen einmaligen Vorgang auszuführen (z. B. das Herunterladen einer Datei). Dazu übergeben Sie ein Intent-Objekt an startService(). Der Intent beschreibt den zu startenden Dienst und enthält alle erforderlichen Daten.

  Wenn der Dienst mit einer Client-Server-Schnittstelle entworfen wurde, können Sie ihn von einer anderen Komponente aus binden, indem Sie ein Intent an bindService() übergeben. Weitere Informationen finden Sie im Leitfaden zu Diensten.

• Nachricht an alle senden

  Ein Broadcast ist eine Nachricht, die von jeder App empfangen werden kann. Das System liefert verschiedene Broadcasts für Systemereignisse, z. B. wenn das System hochfährt oder das Gerät geladen wird. Du kannst einen Broadcast an andere Apps senden, indem du einen Intent an sendBroadcast() oder sendOrderedBroadcast() übergibst.

Auf dieser Seite wird erläutert, wie Intents funktionieren und wie sie verwendet werden. Weitere Informationen finden Sie unter Mit anderen Apps interagieren und Inhalte teilen.

Intent-Typen

Es gibt zwei Arten von Intents:

• Explizite Intents geben an, welche Komponente welcher Anwendung den Intent erfüllt, indem ein vollständiger ComponentName angegeben wird. In der Regel verwenden Sie einen expliziten Intent, um eine Komponente in Ihrer eigenen App zu starten, da Sie den Klassennamen der Aktivität oder des Dienstes kennen, den Sie starten möchten. Beispielsweise könntest du als Reaktion auf eine Nutzeraktion eine neue Aktivität in deiner App starten oder einen Dienst zum Herunterladen einer Datei im Hintergrund starten.
• Bei impliziten Intents wird keine bestimmte Komponente genannt, sondern eine allgemeine Aktion deklariert, die ausgeführt werden soll. Dadurch kann eine Komponente aus einer anderen App die Aktion verarbeiten. Wenn Sie dem Nutzer beispielsweise einen Ort auf einer Karte zeigen möchten, können Sie einen impliziten Intent verwenden, um eine andere geeignete App aufzufordern, einen bestimmten Ort auf einer Karte anzuzeigen.

Abbildung 1 zeigt, wie ein Intent beim Starten einer Aktivität verwendet wird. Wenn das Intent-Objekt eine bestimmte Aktivitätskomponente explizit benennt, startet das System diese Komponente sofort.

Abbildung 1. So wird ein impliziter Intent über das System übermittelt, um eine andere Aktivität zu starten: [1] Aktivität A erstellt einen Intent mit einer Aktionsbeschreibung und übergibt ihn an startActivity(). [2] Das Android-System sucht in allen Apps nach einem Intent-Filter, der mit dem Intent übereinstimmt. Wenn eine Übereinstimmung gefunden wird, [3] startet das System die übereinstimmende Aktivität (Aktivität B), indem es die Methode onCreate() aufruft und den Intent übergibt.

Wenn Sie einen impliziten Intent verwenden, sucht das Android-System die entsprechende Komponente, die gestartet werden soll. Dazu vergleicht es den Inhalt des Intents mit den Intent-Filtern, die in der Manifestdatei anderer Apps auf dem Gerät deklariert sind. Wenn der Intent mit einem Intent-Filter übereinstimmt, startet das System diese Komponente und übergibt ihr das Intent-Objekt. Wenn mehrere Intent-Filter kompatibel sind, wird ein Dialogfeld angezeigt, in dem der Nutzer die gewünschte App auswählen kann.

Ein Intent-Filter ist ein Ausdruck in der Manifestdatei einer App, der den Typ der Intents angibt, die die Komponente empfangen möchte. Wenn Sie beispielsweise einen Intent-Filter für eine Aktivität deklarieren, können andere Apps Ihre Aktivität direkt mit einer bestimmten Art von Intent starten. Wenn Sie keine Intent-Filter für eine Aktivität deklarieren, kann sie nur mit einem expliziten Intent gestartet werden.

Achtung:Damit deine App sicher ist, solltest du beim Starten eines Service immer einen expliziten Intent verwenden und keine Intent-Filter für deine Dienste deklarieren. Die Verwendung eines impliziten Intents zum Starten eines Dienstes ist ein Sicherheitsrisiko, da Sie nicht sicher sein können, welcher Dienst auf den Intent reagiert, und der Nutzer nicht sehen kann, welcher Dienst gestartet wird. Ab Android 5.0 (API-Level 21) löst das System eine Ausnahme aus, wenn Sie bindService() mit einem impliziten Intent aufrufen.

Intent erstellen

Ein Intent-Objekt enthält Informationen, die das Android-System verwendet, um zu bestimmen, welche Komponente gestartet werden soll (z. B. den genauen Komponentennamen oder die Komponentenkategorie, die den Intent empfangen soll). Außerdem enthält es Informationen, die die Empfängerkomponente verwendet, um die Aktion ordnungsgemäß auszuführen (z. B. die auszuführende Aktion und die Daten, auf die reagiert werden soll).

Die wichtigsten Informationen in einem Intent sind:

Komponentenname

Der Name der Komponente, die gestartet werden soll.

Diese Angabe ist optional, aber sie ist die entscheidende Information, die einen Intent explizit macht. Das bedeutet, dass der Intent nur an die App-Komponente übermittelt werden soll, die durch den Komponentennamen definiert ist. Ohne Komponentennamen ist der Intent implizit und das System entscheidet anhand der anderen Intent-Informationen (z. B. Aktion, Daten und Kategorie, wie unten beschrieben), welche Komponente den Intent erhalten soll. Wenn Sie eine bestimmte Komponente in Ihrer App starten müssen, sollten Sie den Komponentennamen angeben.

Hinweis: Wenn Sie einen Service starten, geben Sie immer den Komponentennamen an. Andernfalls können Sie nicht sicher sein, welcher Dienst auf den Intent reagiert, und der Nutzer kann nicht sehen, welcher Dienst gestartet wird.

Dieses Feld des Intent ist ein ComponentName-Objekt, das Sie mit einem voll qualifizierten Klassennamen der Zielkomponente angeben können, einschließlich des Paketnamens der App, z. B. com.example.ExampleActivity. Sie können den Komponentennamen mit setComponent(), setClass(), setClassName() oder mit dem Konstruktor Intent festlegen.

Aktion

Ein String, der die allgemeine Aktion angibt, die ausgeführt werden soll (z. B. view oder pick).

Bei einem Broadcast-Intent ist dies die Aktion, die stattgefunden hat und gemeldet wird. Die Aktion bestimmt weitgehend, wie der Rest des Intents strukturiert ist, insbesondere die Informationen, die in den Daten und Extras enthalten sind.

Sie können eigene Aktionen für Intents in Ihrer App oder für andere Apps angeben, um Komponenten in Ihrer App aufzurufen. In der Regel geben Sie jedoch Aktionskonstanten an, die von der Klasse Intent oder anderen Framework-Klassen definiert werden. Hier sind einige gängige Aktionen zum Starten einer Aktivität:

ACTION_VIEW

Verwende diese Aktion in einem Intent mit startActivity(), wenn du Informationen hast, die eine Aktivität dem Nutzer anzeigen kann, z. B. ein Foto, das in einer Galerie-App angezeigt werden soll, oder eine Adresse, die in einer Karten-App angezeigt werden soll.

ACTION_SEND

Auch als Share-Intent bezeichnet. Du solltest diesen Intent mit startActivity() verwenden, wenn du Daten hast, die der Nutzer über eine andere App wie eine E‑Mail-App oder eine App zum Teilen in sozialen Netzwerken teilen kann.

Weitere Konstanten, die allgemeine Aktionen definieren, finden Sie in der Referenz zur Klasse Intent. Andere Aktionen werden an anderer Stelle im Android-Framework definiert, z. B. in Settings für Aktionen, die bestimmte Bildschirme in der App „Einstellungen“ des Systems öffnen.

Sie können die Aktion für einen Intent mit setAction() oder mit einem Intent-Konstruktor angeben.

Wenn Sie eigene Aktionen definieren, müssen Sie den Paketnamen Ihrer App als Präfix angeben, wie im folgenden Beispiel gezeigt:

Kotlin

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

Java

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

Daten

Der URI (ein Uri-Objekt), der auf die Daten verweist, auf die reagiert werden soll, und/oder der MIME-Typ dieser Daten. Die Art der bereitgestellten Daten wird in der Regel durch die Aktion des Intents vorgegeben. Wenn die Aktion beispielsweise ACTION_EDIT ist, sollten die Daten den URI des zu bearbeitenden Dokuments enthalten.

Beim Erstellen eines Intents ist es oft wichtig, zusätzlich zum URI den Datentyp (MIME-Typ) anzugeben. Eine Aktivität, die Bilder anzeigen kann, kann beispielsweise wahrscheinlich keine Audiodatei abspielen, obwohl die URI-Formate ähnlich sein können. Wenn du den MIME-Typ deiner Daten angibst, kann das Android-System die beste Komponente für den Empfang deines Intents finden. Der MIME-Typ kann jedoch manchmal aus dem URI abgeleitet werden, insbesondere wenn es sich bei den Daten um einen content:-URI handelt. Ein content:-URI gibt an, dass sich die Daten auf dem Gerät befinden und von einem ContentProvider gesteuert werden, wodurch der MIME-Typ der Daten für das System sichtbar wird.

Wenn Sie nur den Daten-URI festlegen möchten, rufen Sie setData() auf. Wenn Sie nur den MIME-Typ festlegen möchten, rufen Sie setType() auf. Bei Bedarf können Sie beide explizit mit setDataAndType() festlegen.

Achtung:Wenn Sie sowohl den URI als auch den MIME-Typ festlegen möchten, rufen Sie nicht setData() und setType() auf, da sie jeweils den Wert des anderen aufheben. Verwenden Sie immer setDataAndType(), um sowohl den URI als auch den MIME-Typ festzulegen.

Kategorie

Ein String mit zusätzlichen Informationen zum Typ der Komponente, die den Intent verarbeiten soll. In einem Intent können beliebig viele Kategoriebeschreibungen platziert werden, aber für die meisten Intents ist keine Kategorie erforderlich. Hier einige gängige Kategorien:

CATEGORY_BROWSABLE

Die Zielaktivität kann von einem Webbrowser gestartet werden, um Daten anzuzeigen, auf die über einen Link verwiesen wird, z. B. ein Bild oder eine E-Mail-Nachricht.

CATEGORY_LAUNCHER

Die Aktivität ist die erste Aktivität einer Aufgabe und wird im Anwendungs-Launcher des Systems aufgeführt.

Eine vollständige Liste der Kategorien finden Sie in der Beschreibung der Klasse Intent.

Sie können eine Kategorie mit addCategory() angeben.

Die oben aufgeführten Eigenschaften (Komponentenname, Aktion, Daten und Kategorie) sind die definierenden Merkmale eines Intents. Durch das Lesen dieser Attribute kann das Android-System ermitteln, welche App-Komponente gestartet werden soll. Ein Intent kann jedoch zusätzliche Informationen enthalten, die sich nicht darauf auswirken, wie er in eine App-Komponente aufgelöst wird. Ein Intent kann auch die folgenden Informationen liefern:

Extras

Schlüssel/Wert-Paare, die zusätzliche Informationen enthalten, die zum Ausführen der angeforderten Aktion erforderlich sind. Genauso wie für einige Aktionen bestimmte Arten von Daten-URIs verwendet werden, werden für einige Aktionen auch bestimmte Extras verwendet.

Sie können zusätzliche Daten mit verschiedenen putExtra()-Methoden hinzufügen, die jeweils zwei Parameter akzeptieren: den Schlüsselnamen und den Wert. Sie können auch ein Bundle-Objekt mit allen zusätzlichen Daten erstellen und dann das Bundle mit putExtras() in das Intent einfügen.

Wenn Sie beispielsweise einen Intent zum Senden einer E-Mail mit ACTION_SEND erstellen, können Sie den Empfänger to mit dem Schlüssel EXTRA_EMAIL und den subject mit dem Schlüssel EXTRA_SUBJECT angeben.

Die Klasse Intent gibt viele EXTRA_*-Konstanten für standardisierte Datentypen an. Wenn du eigene zusätzliche Schlüssel deklarieren musst (für Intents, die deine App empfängt), musst du den Paketnamen deiner App als Präfix angeben, wie im folgenden Beispiel gezeigt:

Kotlin

const val EXTRA_GIGAWATTS = "com.example.EXTRA_GIGAWATTS"

Java

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

Achtung: Verwenden Sie keine Parcelable- oder Serializable-Daten, wenn Sie einen Intent senden, der von einer anderen App empfangen werden soll. Wenn eine App versucht, auf Daten in einem Bundle-Objekt zuzugreifen, aber keinen Zugriff auf die gepackte oder serialisierte Klasse hat, löst das System eine RuntimeException aus.

Flags

-Flags werden in der Klasse Intent definiert und dienen als Metadaten für den Intent. Die Flags können das Android-System anweisen, wie eine Aktivität gestartet werden soll (z. B. zu welcher Aufgabe die Aktivität gehören soll) und wie sie nach dem Start behandelt werden soll (z. B. ob sie in die Liste der letzten Aktivitäten aufgenommen werden soll).

Weitere Informationen finden Sie im Artikel zur Methode setFlags().

Beispiel für explizite Absicht

Ein expliziter Intent wird verwendet, um eine bestimmte App-Komponente zu starten, z. B. eine bestimmte Aktivität oder einen bestimmten Dienst in deiner App. Wenn du einen expliziten Intent erstellen möchtest, definiere den Komponentennamen für das Intent-Objekt. Alle anderen Intent-Eigenschaften sind optional.

Wenn Sie beispielsweise in Ihrer App einen Dienst mit dem Namen DownloadService erstellt haben, der eine Datei aus dem Web herunterladen soll, können Sie ihn mit dem folgenden Code starten:

// 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)

// 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);

Der Intent(Context, Class)-Konstruktor stellt der App Context und der Komponente ein Class-Objekt zur Verfügung. Daher wird mit diesem Intent die Klasse DownloadService in der App explizit gestartet.

Weitere Informationen zum Erstellen und Starten eines Dienstes finden Sie im Leitfaden zu Diensten.

Beispiel für implizite Absicht

Ein impliziter Intent gibt eine Aktion an, die jede App auf dem Gerät aufrufen kann, die die Aktion ausführen kann. Ein impliziter Intent ist nützlich, wenn deine App die Aktion nicht ausführen kann, andere Apps aber wahrscheinlich schon, und du möchtest, dass der Nutzer die zu verwendende App auswählt.

Wenn du beispielsweise Inhalte hast, die der Nutzer mit anderen teilen soll, erstelle einen Intent mit der Aktion ACTION_SEND und füge Extras hinzu, die die zu teilenden Inhalte angeben. Wenn Sie startActivity() mit diesem Intent aufrufen, kann der Nutzer eine App auswählen, über die er die Inhalte teilen möchte.

// 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.
}

// 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.
}

Wenn startActivity() aufgerufen wird, prüft das System alle installierten Apps, um festzustellen, welche diese Art von Intent verarbeiten können (ein Intent mit der Aktion ACTION_SEND, der „text/plain“-Daten enthält). Wenn es nur eine App gibt, die den Intent verarbeiten kann, wird diese App sofort geöffnet und erhält den Intent. Wenn keine anderen Apps die Anfrage verarbeiten können, kann Ihre App die auftretende ActivityNotFoundException abfangen. Wenn mehrere Aktivitäten den Intent akzeptieren, zeigt das System ein Dialogfeld wie in Abbildung 2 an, damit der Nutzer die gewünschte App auswählen kann.

Weitere Informationen zum Starten anderer Apps findest du im Leitfaden zum Weiterleiten des Nutzers an eine andere App.

Abbildung 2: Ein Auswahldialogfeld.

App-Auswahl erzwingen

Wenn mehrere Apps auf einen impliziten Intent reagieren, kann der Nutzer auswählen, welche App verwendet werden soll, und diese App als Standard für die Aktion festlegen. Die Möglichkeit, eine Standard-App auszuwählen, ist hilfreich, wenn eine Aktion ausgeführt wird, für die der Nutzer wahrscheinlich immer dieselbe App verwenden möchte, z. B. beim Öffnen einer Webseite (Nutzer bevorzugen oft nur einen Webbrowser).

Wenn jedoch mehrere Apps auf den Intent reagieren können und der Nutzer möglicherweise jedes Mal eine andere App verwenden möchte, sollten Sie explizit ein Dialogfeld zur Auswahl anzeigen. Im Auswahldialog wird der Nutzer aufgefordert, die App für die Aktion auszuwählen. Der Nutzer kann keine Standard-App für die Aktion auswählen. Wenn Ihre App beispielsweise die Aktion „Teilen“ mit der Aktion ACTION_SEND ausführt, möchten Nutzer je nach Situation möglicherweise eine andere App zum Teilen verwenden. Sie sollten daher immer das Dialogfeld zur Auswahl verwenden, wie in Abbildung 2 dargestellt.

Wenn Sie die Auswahl anzeigen möchten, erstellen Sie mit createChooser() einen Intent und übergeben Sie ihn an startActivity(), wie im folgenden Beispiel gezeigt. In diesem Beispiel wird ein Dialogfeld mit einer Liste von Apps angezeigt, die auf den Intent reagieren, der an die Methode createChooser() übergeben wurde. Der angegebene Text wird als Titel des Dialogfelds verwendet.

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)
}

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);
}

Starts mit unsicheren Intents erkennen

Ihre App kann Intents starten, um zwischen Komponenten in Ihrer App zu navigieren oder eine Aktion im Namen einer anderen App auszuführen. Zur Verbesserung der Plattformsicherheit bieten Android 12 (API-Level 31) und höher eine Debugging-Funktion, die Sie warnt, wenn Ihre App einen Intent unsicher startet. Ihre App könnte beispielsweise einen unsicheren Start eines verschachtelten Intents ausführen. Dies ist ein Intent, der als Extra in einem anderen Intent übergeben wird.

Wenn Ihre App beide der folgenden Aktionen ausführt, erkennt das System einen unsicheren Intent-Start und es kommt zu einem StrictMode-Verstoß:

1. Ihre App entpackt einen verschachtelten Intent aus den Extras eines zugestellten Intents.
2. Ihre App startet sofort eine App-Komponente mit diesem verschachtelten Intent, z. B. durch Übergabe des Intents an startActivity(), startService() oder bindService().

Weitere Informationen dazu, wie du diese Situation erkennst und Änderungen an deiner App vornimmst, findest du im Blogpost zu Android Nesting Intents auf Medium.

Nach unsicheren Intent-Starts suchen

Wenn Sie Ihre App auf unsichere Intent-Starts prüfen möchten, rufen Sie detectUnsafeIntentLaunch() auf, wenn Sie VmPolicy konfigurieren, wie im folgenden Code-Snippet gezeigt. Wenn Ihre App einen StrictMode-Verstoß erkennt, sollten Sie die Ausführung der App beenden, um potenziell vertrauliche Informationen zu schützen.

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

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

Intents verantwortungsbewusster verwenden

Folge diesen Best Practices, um die Wahrscheinlichkeit eines unsicheren Intent-Starts und eines StrictMode-Verstoßes zu minimieren.

Kopieren Sie nur die wesentlichen Extras innerhalb von Intents und führen Sie alle erforderlichen Bereinigungen und Validierungen durch. Ihre App kopiert möglicherweise die Extras von einem Intent in einen anderen Intent, der zum Starten einer neuen Komponente verwendet wird. Dies geschieht, wenn Ihre App putExtras(Intent) oder putExtras(Bundle) aufruft. Wenn Ihre App einen dieser Vorgänge ausführt, kopieren Sie nur die Extras, die die empfangende Komponente erwartet. Wenn der andere Intent (der die Kopie empfängt) eine Komponente startet, die nicht exportiert wird, bereinige und validiere die Extras, bevor du sie in den Intent kopierst, der die Komponente startet.

Exportieren Sie die Komponenten Ihrer App nicht unnötig. Wenn Sie beispielsweise eine App-Komponente mit einem internen verschachtelten Intent starten möchten, setzen Sie das Attribut android:exported dieser Komponente auf false.

Verwenden Sie stattdessen einen PendingIntent anstelle eines verschachtelten Intents. Wenn eine andere App das PendingIntent-Objekt des enthaltenen Intent-Objekts entpackt, kann sie das PendingIntent-Objekt mit der Identität Ihrer App starten. Mit dieser Konfiguration kann die andere App jede Komponente in Ihrer App sicher starten, einschließlich nicht exportierter Komponenten.

Das Diagramm in Abbildung 2 zeigt, wie das System die Steuerung von Ihrer (Client-)App an eine andere (Dienst-)App und zurück an Ihre App übergibt:

1. Ihre App erstellt einen Intent, der eine Aktivität in einer anderen App aufruft. Diesem Intent fügen Sie ein PendingIntent-Objekt als Extra hinzu. Dieser Pending Intent ruft eine Komponente in Ihrer App auf, die nicht exportiert wird.
2. Nachdem die andere App den Intent Ihrer App empfangen hat, extrahiert sie das verschachtelte PendingIntent-Objekt.
3. Die andere App ruft die Methode send() für das Objekt PendingIntent auf.
4. Nachdem die Steuerung an Ihre App zurückgegeben wurde, ruft das System den ausstehenden Intent im Kontext Ihrer App auf.

Abbildung 2: Diagramm der Kommunikation zwischen Apps bei Verwendung eines verschachtelten Pending Intent.

Impliziten Intent empfangen

Wenn Sie angeben möchten, welche impliziten Intents Ihre App empfangen kann, deklarieren Sie für jede Ihrer App-Komponenten einen oder mehrere Intent-Filter mit einem <intent-filter>-Element in Ihrer Manifestdatei. In jedem Intent-Filter wird der Typ der Intents angegeben, die er akzeptiert. Dies basiert auf der Aktion, den Daten und der Kategorie des Intents. Das System liefert einen impliziten Intent nur dann an deine App-Komponente, wenn der Intent einen deiner Intent-Filter passieren kann.

Hinweis:Ein expliziter Intent wird immer an sein Ziel übermittelt, unabhängig von den Intent-Filtern, die die Komponente deklariert.

Eine App-Komponente sollte für jede einzelne Aufgabe, die sie ausführen kann, separate Filter deklarieren. Eine Aktivität in einer Bildergalerie-App kann beispielsweise zwei Filter haben: einen Filter zum Ansehen eines Bildes und einen weiteren Filter zum Bearbeiten eines Bildes. Wenn die Aktivität gestartet wird, prüft sie den Intent und entscheidet anhand der Informationen im Intent, wie sie sich verhalten soll (z. B. ob die Editor-Steuerelemente angezeigt werden sollen oder nicht).

Jeder Intent-Filter wird durch ein <intent-filter>-Element in der Manifestdatei der App definiert, das in der entsprechenden App-Komponente (z. B. einem <activity>-Element) verschachtelt ist.

Legen Sie in jeder App-Komponente, die ein <intent-filter>-Element enthält, explizit einen Wert für android:exported fest. Dieses Attribut gibt an, ob andere Apps auf die App-Komponente zugreifen können. In einigen Situationen, z. B. bei Aktivitäten, deren Intent-Filter die Kategorie LAUNCHER enthalten, ist es sinnvoll, dieses Attribut auf true festzulegen. Andernfalls ist es sicherer, dieses Attribut auf false zu setzen.

Warnung:Wenn eine Aktivität, ein Dienst oder ein Übertragungsempfänger in Ihrer App Intent-Filter verwendet und den Wert für android:exported nicht explizit festlegt, kann Ihre App nicht auf einem Gerät mit Android 12 oder höher installiert werden.

In der <intent-filter> können Sie den Typ der Intents angeben, die akzeptiert werden sollen. Verwenden Sie dazu eines oder mehrere dieser drei Elemente:

<action>

Deklariert die akzeptierte Intent-Aktion im Attribut name. Der Wert muss der Literalstringwert einer Aktion sein, nicht die Klassenkonstante.

<data>

Gibt den akzeptierten Datentyp an. Dazu werden ein oder mehrere Attribute verwendet, die verschiedene Aspekte des Daten-URI (scheme, host, port, path) und des MIME-Typs angeben.

<category>

Gibt im Attribut name die akzeptierte Intent-Kategorie an. Der Wert muss der literale Stringwert einer Aktion sein, nicht die Klassenkonstante.

Hinweis:Damit implizite Intents empfangen werden können, muss die Kategorie CATEGORY_DEFAULT im Intent-Filter enthalten sein. Die Methoden startActivity() und startActivityForResult() behandeln alle Intents so, als ob sie die Kategorie CATEGORY_DEFAULT deklariert hätten. Wenn du diese Kategorie nicht in deinem Intent-Filter deklarierst, werden keine impliziten Intents in deine Aktivität aufgelöst.

Hier ist beispielsweise eine Aktivitätsdeklaration mit einem Intent-Filter, um einen ACTION_SEND-Intent zu empfangen, wenn der Datentyp „Text“ ist:

<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>

Sie können einen Filter erstellen, der mehr als eine Instanz von <action>, <data> oder <category> enthält. In diesem Fall müssen Sie sicher sein, dass die Komponente alle Kombinationen dieser Filterelemente verarbeiten kann.

Wenn du mehrere Arten von Intents verarbeiten möchtest, aber nur in bestimmten Kombinationen von Aktion, Daten und Kategorietyp, musst du mehrere Intent-Filter erstellen.

Ein impliziter Intent wird mit einem Filter getestet, indem der Intent mit jedem der drei Elemente verglichen wird. Damit der Intent an die Komponente übermittelt wird, muss er alle drei Tests bestehen. Wenn auch nur eine davon nicht übereinstimmt, wird der Intent vom Android-System nicht an die Komponente übermittelt. Da eine Komponente jedoch mehrere Intent-Filter haben kann, kann ein Intent, der einen der Filter einer Komponente nicht passiert, einen anderen Filter passieren. Weitere Informationen dazu, wie das System Intents auflöst, finden Sie im Abschnitt Intent-Auflösung unten.

Hinweis:Für alle Aktivitäten müssen Sie Ihre Intent-Filter in der Manifestdatei deklarieren. Filter für Übertragungsempfänger können jedoch dynamisch durch Aufrufen von registerReceiver() registriert werden. Anschließend können Sie die Registrierung des Empfängers mit unregisterReceiver() aufheben. So kann Ihre App nur während eines bestimmten Zeitraums, in dem sie ausgeführt wird, auf bestimmte Broadcasts warten.

Beispielfilter

Hier ist ein Beispiel aus der Manifestdatei einer App zum Teilen in sozialen Netzwerken, um einige der Verhaltensweisen von Intent-Filtern zu veranschaulichen:

<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>

Die erste Aktivität, MainActivity, ist der Haupteinstiegspunkt der App – die Aktivität, die geöffnet wird, wenn der Nutzer die App zum ersten Mal über das Launcher-Symbol startet:

• Die Aktion ACTION_MAIN gibt an, dass dies der Haupteinstiegspunkt ist und keine Intent-Daten erwartet werden.
• Die Kategorie CATEGORY_LAUNCHER gibt an, dass das Symbol dieser Aktivität im App Launcher des Systems platziert werden soll. Wenn im Element <activity> kein Symbol mit icon angegeben ist, verwendet das System das Symbol aus dem Element <application>.

Diese beiden müssen miteinander verknüpft sein, damit die Aktivität im App Launcher angezeigt wird.

Die zweite Aktivität, ShareActivity, soll das Teilen von Text- und Medieninhalten erleichtern. Nutzer können diese Aktivität zwar aufrufen, indem sie von MainActivity dorthin navigieren, aber sie können ShareActivity auch direkt über eine andere App aufrufen, die einen impliziten Intent ausgibt, der mit einem der beiden Intent-Filter übereinstimmt.

Hinweis:Der MIME-Typ application/vnd.google.panorama360+jpg ist ein spezieller Datentyp, der Panoramafotos angibt, die Sie mit den Google Panorama APIs verarbeiten können.

Intents mit Intent-Filtern anderer Apps abgleichen

Wenn eine andere App auf Android 13 (API-Level 33) oder höher ausgerichtet ist, kann sie den Intent Ihrer App nur verarbeiten, wenn Ihr Intent mit den Aktionen und Kategorien eines <intent-filter>-Elements in dieser anderen App übereinstimmt. Wenn das System keine Übereinstimmung findet, wird ein ActivityNotFoundException ausgegeben. Die sendende App muss diese Ausnahme verarbeiten.

Wenn Sie Ihre App so aktualisieren, dass sie auf Android 13 oder höher ausgerichtet ist, werden alle Intents, die von externen Apps stammen, nur dann an eine exportierte Komponente Ihrer App gesendet, wenn dieser Intent mit den Aktionen und Kategorien eines von Ihrer App deklarierten <intent-filter>-Elements übereinstimmt. Dieses Verhalten tritt unabhängig von der SDK-Zielversion der sendenden App auf.

In den folgenden Fällen wird die Intent-Abstimmung nicht erzwungen:

• Intents, die an Komponenten gesendet werden, die keine Intent-Filter deklarieren.
• Intents, die aus derselben App stammen.
• Intents, die vom System stammen, d. h. Intents, die von der „System-UID“ (uid=1000) gesendet werden. Zu den System-Apps gehören system_server und Apps, die android:sharedUserId auf android.uid.system festlegen.
• Intents, die vom Stamm stammen.

Weitere Informationen zum Intent-Matching

Pending Intent verwenden

Ein PendingIntent-Objekt ist ein Wrapper für ein Intent-Objekt. Der Hauptzweck eines PendingIntent besteht darin, einer fremden Anwendung die Berechtigung zu erteilen, den enthaltenen Intent so zu verwenden, als würde er vom eigenen Prozess Ihrer App ausgeführt.

Zu den wichtigsten Anwendungsfällen für einen Pending Intent gehören:

• Deklarieren eines Intents, der ausgeführt werden soll, wenn der Nutzer eine Aktion mit deiner Benachrichtigung ausführt (der NotificationManager des Android-Systems führt den Intent aus).
• Deklarieren eines Intents, der ausgeführt werden soll, wenn der Nutzer eine Aktion mit deinem App-Widget ausführt (die Startbildschirm-App führt den Intent aus).
• Deklarieren eines Intents, der zu einem bestimmten zukünftigen Zeitpunkt ausgeführt werden soll (der AlarmManager des Android-Systems führt den Intent aus).

So wie jedes Intent-Objekt für die Verarbeitung durch einen bestimmten Typ von App-Komponente (entweder Activity, Service oder BroadcastReceiver) konzipiert ist, muss auch ein PendingIntent mit derselben Überlegung erstellt werden. Wenn Sie einen ausstehenden Intent verwenden, führt Ihre App den Intent nicht mit einem Aufruf wie startActivity() aus. Stattdessen müssen Sie den gewünschten Komponententyp deklarieren, wenn Sie die PendingIntent erstellen, indem Sie die entsprechende Erstellungsmethode aufrufen:

• PendingIntent.getActivity() für ein Intent, das ein Activity startet.
• PendingIntent.getService() für einen Intent, der einen Service startet.
• PendingIntent.getBroadcast() für einen Intent, der einen BroadcastReceiver startet.

Wenn Ihre App keine Pending Intents von anderen Apps empfängt, sind die oben genannten Methoden zum Erstellen eines PendingIntent wahrscheinlich die einzigen PendingIntent-Methoden, die Sie jemals benötigen werden.

Jede Methode verwendet die aktuelle App Context, den Intent, den Sie verpacken möchten, und ein oder mehrere Flags, die angeben, wie der Intent verwendet werden soll (z. B. ob der Intent mehr als einmal verwendet werden kann).

Weitere Informationen zur Verwendung von Pending Intents finden Sie in der Dokumentation zu den jeweiligen Anwendungsfällen, z. B. in den API-Leitfäden zu Benachrichtigungen und App-Widgets.

Veränderbarkeit angeben

Wenn Ihre App auf Android 12 oder höher ausgerichtet ist, müssen Sie die Veränderlichkeit aller PendingIntent-Objekte angeben, die von Ihrer App erstellt werden. Wenn Sie deklarieren möchten, dass ein bestimmtes PendingIntent-Objekt änderbar oder unveränderlich ist, verwenden Sie das Flag PendingIntent.FLAG_MUTABLE bzw. PendingIntent.FLAG_IMMUTABLE.

Wenn Ihre App versucht, ein PendingIntent-Objekt zu erstellen, ohne eines der Änderbarkeits-Flags festzulegen, löst das System eine IllegalArgumentException aus und die folgende Meldung wird in Logcat angezeigt:

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.

Nach Möglichkeit unveränderliche ausstehende Intents erstellen

In den meisten Fällen sollte Ihre App unveränderliche PendingIntent-Objekte erstellen, wie im folgenden Code-Snippet gezeigt. Wenn ein PendingIntent-Objekt unveränderlich ist, können andere Apps den Intent nicht ändern, um das Ergebnis des Aufrufs des Intents anzupassen.

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

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

Für bestimmte Anwendungsfälle sind jedoch änderbare PendingIntent-Objekte erforderlich:

• Unterstützung von Direktantwortaktionen in Benachrichtigungen. Für die Direktantwort ist eine Änderung der Clipdaten im PendingIntent-Objekt erforderlich, das mit der Antwort verknüpft ist. In der Regel fordern Sie diese Änderung an, indem Sie FILL_IN_CLIP_DATA als Flag an die Methode fillIn() übergeben.
• Benachrichtigungen mit dem Android Auto-Framework verknüpfen, indem Instanzen von CarAppExtender verwendet werden.
• Unterhaltungen in Bubbles mit Instanzen von PendingIntent platzieren. Ein änderbares PendingIntent-Objekt ermöglicht es dem System, die richtigen Flags anzuwenden, z. B. FLAG_ACTIVITY_MULTIPLE_TASK und FLAG_ACTIVITY_NEW_DOCUMENT.
• Anfordern von Informationen zum Gerätestandort durch Aufrufen von requestLocationUpdates() oder ähnlichen APIs. Das änderbare PendingIntent-Objekt ermöglicht es dem System, Intent-Extras hinzuzufügen, die Standort-Lifecycle-Events darstellen. Zu diesen Ereignissen gehören eine Änderung des Standorts und die Verfügbarkeit eines Anbieters.
• Planen von Alarmen mit AlarmManager. Das änderbare PendingIntent-Objekt ermöglicht es dem System, das Intent-Extra EXTRA_ALARM_COUNT hinzuzufügen. Dieses Extra gibt an, wie oft ein sich wiederholender Wecker ausgelöst wurde. Durch diesen zusätzlichen Intent kann eine App genau darüber informiert werden, ob ein sich wiederholender Wecker mehrmals ausgelöst wurde, z. B. wenn sich das Gerät im Ruhemodus befand.

Wenn Ihre App ein änderbares PendingIntent-Objekt erstellt, sollten Sie unbedingt einen expliziten Intent verwenden und die ComponentName ausfüllen. So wird immer dieselbe Komponente in Ihrer App gestartet, wenn eine andere App den PendingIntent aufruft und die Kontrolle an Ihre App zurückgibt.

Explizite Intents in ausstehenden Intents verwenden

Wenn Sie genauer festlegen möchten, wie andere Apps die Pending Intents Ihrer App verwenden können, sollten Sie einen Pending Intent immer mit einem expliziten Intent umschließen. So können Sie diese Best Practice umsetzen:

1. Prüfe, ob die Felder für Aktion, Paket und Komponente des Basis-Intents festgelegt sind.

2. Verwende FLAG_IMMUTABLE, das in Android 6.0 (API-Level 23) hinzugefügt wurde, um Pending Intents zu erstellen. Dieses Flag verhindert, dass Apps, die einen PendingIntent empfangen, nicht festgelegte Attribute selbst festlegen. Wenn der minSdkVersion-Wert Ihrer App 22 oder niedriger ist, können Sie Sicherheit und Kompatibilität mit dem folgenden Code kombinieren:

   if (Build.VERSION.SDK_INT >= 23) {
     // Create a PendingIntent using FLAG_IMMUTABLE.
   } else {
     // Existing code that creates a PendingIntent.
   }

Intent-Auflösung

Wenn das System einen impliziten Intent zum Starten einer Aktivität empfängt, sucht es nach der besten Aktivität für den Intent. Dazu vergleicht es ihn anhand von drei Aspekten mit Intent-Filtern:

• Alles, was du brauchst –
• Daten (sowohl URI als auch Datentyp).
• Kategorie:

In den folgenden Abschnitten wird beschrieben, wie Intents gemäß der Intent-Filterdeklaration in der Manifestdatei einer App den entsprechenden Komponenten zugeordnet werden.

Aktionstest

Wenn Sie akzeptierte Intent-Aktionen angeben möchten, können Sie in einem Intent-Filter null oder mehr <action>-Elemente deklarieren, wie im folgenden Beispiel gezeigt:

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

Damit dieser Filter erfüllt wird, muss die im Intent angegebene Aktion mit einer der im Filter aufgeführten Aktionen übereinstimmen.

Wenn im Filter keine Aktionen aufgeführt sind, gibt es nichts, was mit einem Intent übereinstimmen könnte. Daher schlagen alle Intents beim Test fehl. Wenn in einem Intent jedoch keine Aktion angegeben ist, wird der Test bestanden, solange der Filter mindestens eine Aktion enthält.

Kategorietest

Wenn Sie akzeptierte Intent-Kategorien angeben möchten, kann ein Intent-Filter null oder mehr <category>-Elemente deklarieren, wie im folgenden Beispiel gezeigt:

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

Damit ein Intent den Kategorietest besteht, muss jede Kategorie in der Intent mit einer Kategorie im Filter übereinstimmen. Das Gegenteil ist nicht erforderlich. Der Intent-Filter kann mehr Kategorien deklarieren, als im Intent angegeben sind, und der Intent wird trotzdem übergeben. Daher besteht ein Intent ohne Kategorien diesen Test immer, unabhängig davon, welche Kategorien im Filter deklariert sind.

Hinweis: Android wendet die Kategorie CATEGORY_DEFAULT automatisch auf alle impliziten Intents an, die an startActivity() und startActivityForResult() übergeben werden. Wenn Ihre Aktivität implizite Intents empfangen soll, muss sie eine Kategorie für "android.intent.category.DEFAULT" in ihren Intent-Filtern enthalten, wie im vorherigen <intent-filter>-Beispiel gezeigt.

Datentest

Wenn Sie akzeptierte Intent-Daten angeben möchten, kann ein Intent-Filter null oder mehr <data>-Elemente deklarieren, wie im folgenden Beispiel gezeigt:

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

Jedes <data>-Element kann eine URI-Struktur und einen Datentyp (MIME-Medientyp) angeben. Jeder Teil des URI ist ein separates Attribut: scheme, host, port und path:

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

Das folgende Beispiel zeigt mögliche Werte für diese Attribute:

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

In diesem URI ist das Schema content, der Host com.example.project, der Port 200 und der Pfad folder/subfolder/etc.

Jedes dieser Attribute ist in einem <data>-Element optional, es gibt jedoch lineare Abhängigkeiten:

• Wenn kein Schema angegeben ist, wird der Host ignoriert.
• Wenn kein Host angegeben ist, wird der Port ignoriert.
• Wenn weder das Schema noch der Host angegeben ist, wird der Pfad ignoriert.

Wenn der URI in einem Intent mit einer URI-Spezifikation in einem Filter verglichen wird, wird er nur mit den Teilen des URI verglichen, die im Filter enthalten sind. Beispiel:

• Wenn ein Filter nur ein Schema angibt, entsprechen alle URIs mit diesem Schema dem Filter.
• Wenn ein Filter ein Schema und eine Authority, aber keinen Pfad angibt, werden alle URIs mit demselben Schema und derselben Authority vom Filter akzeptiert, unabhängig von ihren Pfaden.
• Wenn ein Filter ein Schema, eine Authority und einen Pfad angibt, werden nur URIs mit demselben Schema, derselben Authority und demselben Pfad durch den Filter zugelassen.

Hinweis: Eine Pfadspezifikation kann ein Platzhaltersternchen (*) enthalten, damit nur eine teilweise Übereinstimmung des Pfadnamens erforderlich ist.

Beim Datentest werden sowohl der URI als auch der MIME-Typ im Intent mit einem im Filter angegebenen URI und MIME-Typ verglichen. Die Regeln sind:

1. Ein Intent, der weder einen URI noch einen MIME-Typ enthält, besteht den Test nur, wenn im Filter keine URIs oder MIME-Typen angegeben sind.
2. Ein Intent, der einen URI, aber keinen MIME-Typ enthält (weder explizit noch aus dem URI ableitbar), besteht den Test nur, wenn sein URI mit dem URI-Format des Filters übereinstimmt und der Filter ebenfalls keinen MIME-Typ angibt.
3. Ein Intent, der einen MIME-Typ, aber keinen URI enthält, besteht den Test nur, wenn der Filter denselben MIME-Typ auflistet und kein URI-Format angibt.
4. Ein Intent, der sowohl einen URI als auch einen MIME-Typ enthält (entweder explizit oder aus dem URI ableitbar), besteht den MIME-Typ-Teil des Tests nur, wenn dieser Typ mit einem im Filter aufgeführten Typ übereinstimmt. Der URI-Teil des Tests wird bestanden, wenn der URI mit einem URI im Filter übereinstimmt oder wenn er einen content:- oder file:-URI hat und im Filter kein URI angegeben ist. Mit anderen Worten: Es wird davon ausgegangen, dass eine Komponente content:- und file:-Daten unterstützt, wenn in ihren Filtern nur ein MIME-Typ aufgeführt ist.

Hinweis:Wenn ein Intent einen URI oder MIME-Typ angibt, schlägt der Datentest fehl, wenn keine <data>-Elemente im <intent-filter> vorhanden sind.

Diese letzte Regel (d) spiegelt die Erwartung wider, dass Komponenten lokale Daten aus einer Datei oder einem Contentanbieter abrufen können. Daher können ihre Filter nur einen Datentyp auflisten und müssen die Schemas content: und file: nicht explizit benennen. Das folgende Beispiel zeigt einen typischen Fall, in dem ein <data>-Element Android mitteilt, dass die Komponente Bilddaten von einem Contentanbieter abrufen und anzeigen kann:

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

Filter, die einen Datentyp, aber keinen URI angeben, sind wahrscheinlich am häufigsten, da die meisten verfügbaren Daten von Contentanbietern bereitgestellt werden.

Eine weitere gängige Konfiguration ist ein Filter mit einem Schema und einem Datentyp. Ein <data>-Element wie das folgende teilt Android beispielsweise mit, dass die Komponente Videodaten aus dem Netzwerk abrufen kann, um die Aktion auszuführen:

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

Intent-Zuordnung

Intents werden nicht nur mit Intent-Filtern abgeglichen, um eine zu aktivierende Zielkomponente zu finden, sondern auch, um Informationen über die Komponenten auf dem Gerät zu erhalten. Die Home App füllt beispielsweise den App Launcher, indem sie alle Aktivitäten mit Intent-Filtern findet, die die Aktion ACTION_MAIN und die Kategorie CATEGORY_LAUNCHER angeben. Eine Übereinstimmung ist nur dann erfolgreich, wenn die Aktionen und Kategorien im Intent mit dem Filter übereinstimmen, wie in der Dokumentation für die Klasse IntentFilter beschrieben.

Deine Anwendung kann den Intent-Abgleich ähnlich wie die Home App verwenden. Der PackageManager verfügt über eine Reihe von query...()-Methoden, die alle Komponenten zurückgeben, die einen bestimmten Intent akzeptieren können, und eine ähnliche Reihe von resolve...()-Methoden, die die beste Komponente für die Antwort auf einen Intent bestimmen. Beispiel: queryIntentActivities() gibt eine Liste aller Aktivitäten zurück, die den als Argument übergebenen Intent ausführen können, und queryIntentServices() gibt eine ähnliche Liste von Diensten zurück. Keine der beiden Methoden aktiviert die Komponenten. Es werden nur die Komponenten aufgelistet, die antworten können. Für Übertragungsempfänger gibt es eine ähnliche Methode: queryBroadcastReceivers().