Intents und Intent-Filter

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

• Aktivität starten

  Ein Activity steht für einen einzelnen Bildschirm in einer App. Sie können eine neue Instanz einer Activity starten, indem Sie eine Intent an startActivity() übergeben. Intent beschreibt die zu startende Aktivität und überträgt alle erforderlichen Daten.

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

• Dienst starten

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

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

  Wenn der Dienst mit einer Client-Server-Schnittstelle entworfen wurde, können Sie sich von einer anderen Komponente an den Dienst binden. Dazu übergeben Sie einen Intent an bindService(). Weitere Informationen finden Sie im Leitfaden Dienste.

• Übertragung starten

  Eine Übertragung ist eine Nachricht, die jede App empfangen kann. Das System sendet verschiedene Broadcasts für Systemereignisse, z. B. wenn das System hochfährt oder das Gerät aufgeladen wird. Sie können eine Übertragung an andere Apps senden, indem Sie Intent an sendBroadcast() oder sendOrderedBroadcast() übergeben.

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

Intent-Typen

Es gibt zwei Arten von Intents:

• Explizite Intents geben durch Angabe eines vollständigen ComponentName an, welche Komponente welcher Anwendung den Intent erfüllt. Normalerweise verwenden Sie einen expliziten Intent, um eine Komponente in Ihrer eigenen Anwendung zu starten, da Sie den Klassennamen der Aktivität oder des Dienstes kennen, den Sie starten möchten. Sie können beispielsweise als Reaktion auf eine Nutzeraktion eine neue Aktivität in Ihrer App starten oder einen Dienst starten, um eine Datei im Hintergrund herunterzuladen.
• Implizite Intents benennen eine bestimmte Komponente nicht, sondern deklarieren stattdessen eine allgemeine auszuführende Aktion, die es einer Komponente aus einer anderen App ermöglicht, diese auszuführen. Wenn Sie beispielsweise dem Nutzer einen Standort auf einer Karte zeigen möchten, können Sie mit einem impliziten Intent anfordern, dass eine andere App einen bestimmten Standort auf einer Karte anzeigt.

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

Abbildung 1: So wird ein impliziter Intent durch das System übermittelt, um eine andere Aktivität zu starten: [1] Aktivität A erstellt eine Intent mit einer Aktionsbeschreibung und übergibt sie 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). Dazu ruft es die Methode onCreate() auf und übergibt ihr Intent.

Wenn du einen impliziten Intent verwendest, vergleicht das Android-System zuerst die entsprechende Komponente. 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 sendet ihr das Objekt Intent. Wenn mehrere Intent-Filter kompatibel sind, zeigt das System ein Dialogfeld an, in dem der Nutzer die App auswählen kann.

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

Achtung:Damit Ihre Anwendung sicher ist, sollten Sie beim Starten von Service immer einen expliziten Intent verwenden und keine Intent-Filter für Ihre Dienste deklarieren. Die Verwendung eines impliziten Intents zum Starten eines Dienstes stellt ein Sicherheitsrisiko dar, da Sie nicht sicher sind, welcher Dienst auf den Intent reagiert, und der Nutzer nicht sehen kann, welcher Dienst gestartet wird. Ab Android 5.0 (API-Level 21) wird eine Ausnahme ausgelöst, wenn bindService() mit einem impliziten Intent aufgerufen wird.

Intent erstellen

Ein Intent-Objekt enthält Informationen, anhand derer das Android-System bestimmt, welche Komponente gestartet werden soll (z. B. der genaue Komponentenname oder die Komponentenkategorie, die den Intent empfangen soll). Außerdem enthält das Objekt Informationen, die die Empfängerkomponente zur ordnungsgemäßen Ausführung der Aktion verwendet (z. B. die auszuführende Aktion und die zu verarbeitenden Daten).

Die Hauptinformationen in einem Intent sind:

Komponentenname

Der Name der Komponente, die gestartet werden soll.

Dies ist optional, aber die wichtige Information, die einen Intent explizit macht. Der Intent sollte also nur an die App-Komponente gesendet werden, die durch den Komponentennamen definiert ist. Ohne einen Komponentennamen ist der Intent implizit und das System entscheidet anhand der anderen Intent-Informationen (wie 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 Namen der Komponente angeben.

Hinweis: Gib beim Starten eines Service 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 von Intent ist ein ComponentName-Objekt, das Sie mit einem vollständig 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 dem Konstruktor Intent festlegen.

Aktion

Ein String, der die auszuführende allgemeine Aktion angibt (z. B. view oder pick).

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

Sie können Ihre eigenen Aktionen für Intents in Ihrer Anwendung (oder für andere Anwendungen zum Aufrufen von Komponenten in Ihrer Anwendung) angeben. In der Regel geben Sie jedoch Aktionskonstanten an, die durch die Klasse Intent oder andere Framework-Klassen definiert werden. Hier sind einige gängige Aktionen zum Starten einer Aktivität:

ACTION_VIEW

Verwenden Sie diese Aktion in einem Intent mit startActivity(), wenn Sie Informationen haben, die eine Aktivität dem Nutzer anzeigen kann, z. B. ein Foto, das Sie in einer Galerie-App ansehen können, oder eine Adresse, die Sie in einer Karten-App ansehen können.

ACTION_SEND

Auch als share-Intent bezeichnet. Sie sollten diesen in einem Intent mit startActivity() verwenden, wenn Sie Daten haben, die der Nutzer über eine andere App teilen kann, z. B. eine E-Mail-App oder eine App zum Teilen in sozialen Netzwerken.

Weitere Konstanten zum Definieren generischer Aktionen 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, mit denen bestimmte Bildschirme in der App „Einstellungen“ des Systems geöffnet werden.

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 hinzufügen, 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 im Allgemeinen von der Aktion des Intents bestimmt. Wenn die Aktion beispielsweise ACTION_EDIT lautet, sollten die Daten den URI des Dokuments enthalten, das bearbeitet werden soll.

Beim Erstellen eines Intents ist es häufig wichtig, neben dem URI auch den Datentyp (seinen MIME-Typ) anzugeben. Beispielsweise kann eine Aktivität, mit der Bilder angezeigt werden können, wahrscheinlich keine Audiodatei abspielen, obwohl die URI-Formate ähnlich sein könnten. Wenn Sie den MIME-Typ Ihrer Daten angeben, kann das Android-System die beste Komponente für den Empfang Ihres Intents finden. Der MIME-Typ kann jedoch manchmal aus dem URI abgeleitet werden, insbesondere wenn die Daten ein content:-URI sind. Ein content:-URI gibt an, dass sich die Daten auf dem Gerät befinden und von einem ContentProvider gesteuert werden. Dadurch ist der Daten-MIME-Typ für das System sichtbar.

Wenn Sie nur den Daten-URI festlegen möchten, rufen Sie setData() auf. Um nur den MIME-Typ festzulegen, 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 setData() und setType() nicht auf, da beide den Wert des jeweils anderen auf null setzen. Verwenden Sie immer setDataAndType(), um sowohl den URI als auch den MIME-Typ festzulegen.

Kategorie

Ein String mit zusätzlichen Informationen zu der Art der Komponente, die den Intent verarbeiten soll. In einem Intent können beliebig viele Kategoriebeschreibungen eingefügt werden. Für die meisten Intents ist jedoch keine Kategorie erforderlich. Hier sind einige gängige Kategorien:

CATEGORY_BROWSABLE

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

CATEGORY_LAUNCHER

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

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

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

Die oben aufgeführten Attribute (Komponentenname, Aktion, Daten und Kategorie) stellen die definierenden Merkmale eines Intents dar. Anhand dieser Eigenschaften kann das Android-System erkennen, welche App-Komponente es starten soll. Ein Intent kann jedoch zusätzliche Informationen enthalten, die keinen Einfluss darauf haben, wie er in eine Anwendungskomponente aufgelöst wird. Ein Intent kann auch die folgenden Informationen bereitstellen:

Weitere Funktionen

Schlüssel/Wert-Paare, die zusätzliche Informationen enthalten, die erforderlich sind, um die angeforderte Aktion auszuführen. So wie bei einigen Aktionen bestimmte Arten von Daten-URIs verwendet werden, haben auch einige Aktionen bestimmte Extras.

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-Objekt mit putExtras() in die 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 Betreff mit dem Schlüssel EXTRA_SUBJECT angeben.

Die Klasse Intent gibt viele EXTRA_*-Konstanten für standardisierte Datentypen an. Wenn Sie Ihre eigenen zusätzlichen Schlüssel (für Intents, die Ihre App empfängt), angeben müssen, fügen Sie den Paketnamen Ihrer App als Präfix hinzu, 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, den eine andere Anwendung empfangen soll. Wenn eine Anwendung versucht, auf Daten in einem Bundle-Objekt zuzugreifen, aber keinen Zugriff auf die Paket- oder serialisierte Klasse hat, gibt das System den Fehler RuntimeException aus.

Meldungen

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 wird (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 gehört).

Weitere Informationen finden Sie in der setFlags()-Methode.

Beispiel für einen expliziten Intent

Ein expliziter Intent ist ein Intent, mit dem Sie eine bestimmte App-Komponente starten, z. B. eine bestimmte Aktivität oder einen bestimmten Dienst in Ihrer App. Um einen expliziten Intent zu erstellen, definieren Sie den Komponentennamen für das Intent-Objekt. Alle anderen Intent-Attribute sind optional.

Wenn Sie in Ihrer App beispielsweise einen Dienst namens DownloadService zum Herunterladen einer Datei aus dem Web erstellt haben, 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 Konstruktor Intent(Context, Class) stellt die Context der Anwendung und die Komponente ein Class-Objekt bereit. Daher startet dieser Intent explizit die DownloadService-Klasse in der App.

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

Beispiel für einen impliziten Intent

Ein impliziter Intent gibt eine Aktion an, mit der eine beliebige App auf dem Gerät aufgerufen werden kann, das die Aktion ausführen kann. Die Verwendung eines impliziten Intents ist nützlich, wenn Ihre App die Aktion nicht ausführen kann, aber andere Apps wahrscheinlich schon können und Sie möchten, dass der Nutzer die App auswählen kann, die verwendet werden soll.

Wenn der Nutzer beispielsweise Inhalte für andere Personen freigeben soll, erstellen Sie einen Intent mit der Aktion ACTION_SEND und fügen Sie Extras hinzu, die die freizugebenden Inhalte angeben. Wenn Sie startActivity() mit diesem Intent aufrufen, kann der Nutzer eine App auswählen, über die der Inhalt geteilt werden soll.

// 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 Anwendungen, um festzustellen, welche diese Art von Intent verarbeiten können (ein Intent mit der Aktion ACTION_SEND, der „Nur-Text“-Daten enthält). Wenn nur eine App hierfür geeignet ist, wird sie sofort geöffnet und erhält den Intent. Wenn keine andere App dies verarbeiten kann, kann Ihre App den auftretenden ActivityNotFoundException abfangen. Wenn mehrere Aktivitäten den Intent akzeptieren, zeigt das System ein Dialogfeld wie in Abbildung 2 an, damit der Nutzer auswählen kann, welche App verwendet werden soll.

Weitere Informationen zum Starten anderer Anwendungen findest du in der Anleitung zum Senden von Nutzern an eine andere App.

Abbildung 2: Ein Auswahldialogfeld.

Erzwingen einer App-Auswahl

Wenn es mehrere Anwendungen gibt, die auf Ihren impliziten Intent reagieren, kann der Nutzer auswählen, welche Anwendung verwendet werden soll, und diese Anwendung als Standardanwendung für die Aktion festlegen. Die Möglichkeit zur Auswahl einer Standardeinstellung ist hilfreich, wenn eine Aktion ausgeführt wird, bei der der Nutzer wahrscheinlich jedes Mal dieselbe Anwendung 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 Auswahldialogfeld anzeigen. Im Auswahldialogfeld wird der Nutzer aufgefordert, die App auszuwählen, die für die Aktion verwendet werden soll. Er kann keine Standard-App für die Aktion auswählen. Wenn Ihre App beispielsweise mit der Aktion ACTION_SEND „Teilen“ ausführt, kann es sein, dass Nutzer ihre Dateien je nach ihrer aktuellen Situation über eine andere App freigeben möchten. Sie sollten daher immer das Auswahldialogfeld verwenden, wie in Abbildung 2 dargestellt.

Um die Auswahl anzuzeigen, erstellen Sie mit createChooser() eine Intent und übergeben Sie sie an startActivity(), wie im folgenden Beispiel gezeigt. In diesem Beispiel wird ein Dialogfeld mit einer Liste von Apps angezeigt, die auf den an die Methode createChooser() übergebenen Intent reagieren und den bereitgestellten Text als Dialogfeldtitel verwenden.

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 unsicherer Intents erkennen

Ihre App kann Intents starten, um zwischen Komponenten in Ihrer App zu wechseln 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 unsicheren Start eines Intents ausführt. Ihre App kann beispielsweise einen unsicheren Start eines verschachtelten Intents ausführen. Dabei handelt es sich um einen Intent, der als zusätzlicher Intent in einem anderen Intent übergeben wird.

Wenn Ihre App die beiden folgenden Aktionen ausführt, erkennt das System einen unsicheren Intent-Start und tritt ein StrictMode-Verstoß auf:

1. Ihre Anwendung trennt einen verschachtelten Intent von den Extras eines übermittelten Intents.
2. Ihre App startet sofort eine App-Komponente mit diesem verschachtelten Intent und übergibt den Intent z. B. an startActivity(), startService() oder bindService().

Weitere Informationen dazu, wie Sie diese Situation erkennen und Änderungen an Ihrer App vornehmen können, finden Sie im Blogpost über Nesting Intents für Android auf Medium.

Nach Einführung unsicherer Intents suchen

Wenn Sie prüfen möchten, ob unsichere Intents in Ihrer App gestartet werden, rufen Sie beim Konfigurieren von VmPolicy wie im folgenden Code-Snippet gezeigt detectUnsafeIntentLaunch() auf. Wenn Ihre Anwendung einen Verstoß gegen den StrictMode erkennt, sollten Sie die Ausführung der Anwendung 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

Folgen Sie diesen Best Practices, um das Risiko eines unsicheren Intents und eines Verstoßes im StrictMode zu minimieren.

Kopieren Sie nur die wesentlichen Extras in Intents und führen Sie alle erforderlichen Bereinigungen und Validierungen durch. Ihre App kann die Extras von einem Intent in einen anderen Intent kopieren, der zum Starten einer neuen Komponente verwendet wird. Dies ist der Fall, wenn Ihre Anwendung putExtras(Intent) oder putExtras(Bundle) aufruft. Wenn Ihre Anwendung einen dieser Vorgänge ausführt, kopieren Sie nur die Extras, die die empfangende Komponente erwartet. Wenn der andere Intent, der die Kopie erhält, eine Komponente startet, die nicht exportiert wurde, bereinigen und validieren Sie die zusätzlichen Elemente, bevor Sie sie in den Intent kopieren, mit dem die Komponente gestartet wird.

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 PendingIntent anstelle eines verschachtelten Intents. Wenn eine andere Anwendung das PendingIntent der enthaltenden Intent entpackt, kann die andere Anwendung die PendingIntent anhand der Identität Ihrer Anwendung starten. Mit dieser Konfiguration kann die andere Anwendung jede Komponente in Ihrer Anwendung sicher starten, einschließlich einer nicht exportierten Komponente.

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 Anwendung erstellt einen Intent, der eine Aktivität in einer anderen Anwendung aufruft. Innerhalb dieses Intents fügen Sie als zusätzliches Objekt ein PendingIntent-Objekt hinzu. Dieser ausstehende Intent ruft eine Komponente in Ihrer App auf. Diese Komponente wird nicht exportiert.
2. Nach Empfang des Intents Ihrer App extrahiert die andere App das verschachtelte PendingIntent-Objekt.
3. Die andere App ruft die Methode send() für das PendingIntent-Objekt auf.
4. Nachdem die Steuerung an die Anwendung zurückgegeben wurde, ruft das System den ausstehenden Intent mithilfe des Anwendungskontexts auf.

Abbildung 2: Diagramm der Kommunikation zwischen Apps bei Verwendung eines verschachtelten ausstehenden Intents.

Impliziten Intent empfangen

Du kannst angeben, welche impliziten Intents deine App empfangen kann, indem du für jede deiner App-Komponenten einen oder mehrere Intent-Filter mit einem <intent-filter>-Element in deiner Manifestdatei deklarierst. In jedem Intent-Filter wird der Typ der Intents angegeben, die basierend auf der Aktion, den Daten und der Kategorie des Intents akzeptiert werden. Das System sendet nur dann einen impliziten Intent an Ihre App-Komponente, wenn der Intent einen Ihrer Intent-Filter passieren kann.

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

Für eine App-Komponente sollten für jeden einzelnen Job, den sie ausführen kann, separate Filter deklarieren. Eine Aktivität in einer Bildergalerie-App kann beispielsweise zwei Filter haben: einen Filter zum Anzeigen eines Bildes und einen zum Bearbeiten eines Bildes. Wenn die Aktivität beginnt, prüft sie das Intent und entscheidet anhand der Informationen im Intent, wie es 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 verschachtelt ist, z. B. einem <activity>-Element.

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

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 Geräten mit Android 12 oder höher installiert werden.

Im <intent-filter> können Sie mit einem oder mehreren dieser drei Elemente den Typ der zu akzeptierenden Intents angeben:

<action>

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

<data>

Gibt den zulässigen Datentyp mit einem oder mehreren Attributen an, 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 String-Literalwert einer Aktion sein, nicht die Klassenkonstante.

Hinweis:Um implizite Intents zu erhalten, müssen Sie die Kategorie CATEGORY_DEFAULT in den Intent-Filter aufnehmen. Die Methoden startActivity() und startActivityForResult() behandeln alle Intents so, als hätten sie die Kategorie CATEGORY_DEFAULT deklariert. Wenn du diese Kategorie nicht in deinem Intent-Filter angibst, werden keine impliziten Intents zu deiner Aktivität aufgelöst.

Hier sehen Sie als Beispiel 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 Sie mehrere Arten von Intents verarbeiten möchten, jedoch nur in bestimmten Kombinationen aus Aktion, Daten und Kategorietyp, müssen Sie mehrere Intent-Filter erstellen.

Ein impliziter Intent wird anhand eines Filters geprüft, indem der Intent mit jedem der drei Elemente verglichen wird. Damit der Intent an die Komponente übergeben werden kann, muss er alle drei Tests bestehen. Wenn auch nur eines davon nicht zugeordnet werden kann, sendet das Android-System den Intent nicht an die Komponente. Da eine Komponente jedoch mehrere Intent-Filter haben kann, gelangt ein Intent, der einen der Filter einer Komponente nicht durchläuft, möglicherweise auch einen anderen Filter. Weitere Informationen dazu, wie das System Intents auflöst, finden Sie unten im Abschnitt über Intent-Auflösung.

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 kannst du die Registrierung des Empfängers bei unregisterReceiver() aufheben. So kann Ihre App nur für einen bestimmten Zeitraum bestimmte Broadcasts empfangen, während sie ausgeführt wird.

Beispielfilter

Hier ist ein Beispiel aus der Manifestdatei einer App zum Teilen in sozialen Netzwerken, um einige der Intent-Filterverhalten 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. Sie wird geöffnet, wenn der Nutzer die App zum ersten Mal mit dem 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 für das Element <activity> kein Symbol mit icon angegeben ist, verwendet das System das Symbol des Elements <application>.

Diese beiden Elemente müssen gekoppelt 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 eingeben, indem sie sie von MainActivity aus aufrufen, aber sie können ShareActivity auch direkt aus einer anderen App eingeben, die einen impliziten Intent ausgibt, der einem der beiden Intent-Filter entspricht.

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

Ist eine andere App auf Android 13 (API-Level 33) oder höher ausgerichtet, kann der Intent der App nur dann verarbeitet werden, wenn dein Intent mit den Aktionen und Kategorien eines <intent-filter>-Elements in dieser anderen App übereinstimmt. Findet das System keine Übereinstimmung, wird ActivityNotFoundException ausgegeben. Die sendende App muss diese Ausnahme verarbeiten.

Wenn du deine App so aktualisierst, dass sie auf Android 13 oder höher ausgerichtet ist, werden alle von externen Apps stammenden Intents nur dann an eine exportierte Komponente deiner App gesendet, wenn dieser Intent mit den Aktionen und Kategorien eines von deiner 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 der Intent-Abgleich nicht erzwungen:

• Intents, die an Komponenten geliefert werden, die keine Intent-Filter deklarieren.
• Intents, die aus derselben App stammen.
• Intents, die aus dem 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 gesetzt haben.
• Intents aus dem Stammverzeichnis.

Weitere Informationen zum Intent-Abgleich

Ausstehenden Intent verwenden

Ein PendingIntent-Objekt ist ein Wrapper um ein Intent-Objekt. Der Hauptzweck eines PendingIntent besteht darin, einer fremden Anwendung die Berechtigung zu erteilen, das enthaltene Intent so zu verwenden, als ob es über den eigenen Prozess deiner App ausgeführt worden wäre.

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

• Intent deklarieren, der ausgeführt werden soll, wenn der Nutzer eine Aktion mit Ihrer Benachrichtigung ausführt (der NotificationManager des Android-Systems führt den Intent aus).
• Intent deklarieren, der ausgeführt werden soll, wenn der Nutzer eine Aktion mit Ihrem App-Widget ausführt (die Startbildschirm-App führt Intent aus).
• Intent zur Ausführung zu einem bestimmten zukünftigen Zeitpunkt deklarieren (der AlarmManager des Android-Systems führt den Intent aus).

So wie jedes Intent-Objekt von einem bestimmten Typ von Anwendungskomponente verarbeitet werden kann (entweder Activity, Service oder BroadcastReceiver), muss auch ein PendingIntent erstellt werden. Bei Verwendung eines ausstehenden Intents führt die App den Intent nicht mit einem Aufruf wie startActivity() aus. Stattdessen müssen Sie den gewünschten Komponententyp beim Erstellen der PendingIntent durch Aufrufen der entsprechenden Methode des Erstellers deklarieren:

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

Sofern Ihre App keine ausstehenden Intents von anderen Apps empfängt, sind die oben genannten Methoden zum Erstellen einer PendingIntent wahrscheinlich die einzigen PendingIntent-Methoden, die Sie benötigen.

Jede Methode verwendet die aktuelle Context der Anwendung, das Intent, das Sie zusammenfassen 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 ausstehender Intents finden Sie in der Dokumentation für den jeweiligen Anwendungsfall, z. B. in den API-Leitfäden für Benachrichtigungen und App Widgets.

Veränderlichkeit angeben

Wenn deine App auf Android 12 oder höher ausgerichtet ist, musst du die Veränderlichkeit aller PendingIntent-Objekte angeben, die von deiner App erstellt werden. Um anzugeben, dass ein bestimmtes PendingIntent-Objekt änderbar oder unveränderlich ist, verwenden Sie das Flag PendingIntent.FLAG_MUTABLE bzw. PendingIntent.FLAG_IMMUTABLE.

Wenn Ihre Anwendung versucht, ein PendingIntent-Objekt zu erstellen, ohne eines der Veränderlichkeits-Flags festzulegen, gibt das System 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 Anwendungen den Intent nicht ändern, um das Ergebnis des Intent-Aufrufs 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);

In bestimmten Anwendungsfällen sind stattdessen änderbare PendingIntent-Objekte erforderlich:

• Unterstützung von Direktantworten in Benachrichtigungen Für die Direktantwort müssen die Clipdaten im PendingIntent-Objekt geändert werden, das mit der Antwort verknüpft ist. Normalerweise fordern Sie diese Änderung an, indem Sie FILL_IN_CLIP_DATA als Flag an die Methode fillIn() übergeben.
• Benachrichtigungen werden über Instanzen von CarAppExtender mit dem Android Auto-Framework verknüpft.
• Unterhaltungen mithilfe von Instanzen von PendingIntent in Bubbles platzieren Mit einem änderbaren PendingIntent-Objekt kann das System die richtigen Flags anwenden, z. B. FLAG_ACTIVITY_MULTIPLE_TASK und FLAG_ACTIVITY_NEW_DOCUMENT.
• Gerätestandortinformationen durch Aufrufen von requestLocationUpdates() oder ähnlichen APIs anfordern Mit dem änderbaren PendingIntent-Objekt kann das System Intent-Extras hinzufügen, die Lebenszyklusereignisse von Standorten darstellen. Zu diesen Ereignissen gehören eine Standortänderung und die Verfügbarkeit eines Anbieters.
• Wecker werden mit AlarmManager geplant. Mit dem änderbaren Objekt PendingIntent kann das System den Intent EXTRA_ALARM_COUNT zusätzlich hinzufügen. Dieses Extra gibt an, wie oft ein sich wiederholender Wecker ausgelöst wurde. Dadurch kann der Intent eine App genau darüber informieren, ob ein sich wiederholender Wecker mehrmals ausgelöst wurde, z. B. während das Gerät schläft.

Wenn Ihre Anwendung ein änderbares PendingIntent-Objekt erstellt, wird dringend empfohlen, einen expliziten Intent zu verwenden und ComponentName auszufüllen. Auf diese Weise wird immer dann dieselbe Komponente in Ihrer Anwendung gestartet, wenn eine andere Anwendung PendingIntent aufruft und die Steuerung an Ihre Anwendung übergibt.

Explizite Intents in ausstehenden Intents verwenden

Damit Sie besser definieren können, wie andere Apps die ausstehenden Intents Ihrer App verwenden können, müssen Sie einen ausstehenden Intent immer um einen expliziten Intent umschließen. Gehen Sie so vor, um diese Best Practice umzusetzen:

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

2. Verwenden Sie FLAG_IMMUTABLE, das in Android 6.0 (API-Level 23) hinzugefügt wurde, um ausstehende Intents zu erstellen. Dieses Flag verhindert, dass Anwendungen, die eine PendingIntent erhalten, nicht ausgefüllte Attribute ausfüllen. Wenn das minSdkVersion deiner App 22 oder niedriger ist, kannst du mithilfe des folgenden Codes Sicherheit und Kompatibilität gemeinsam angeben:

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

Auflösung von Absichten

Wenn das System den impliziten Intent zum Starten einer Aktivität erhält, sucht es nach der besten Aktivität für den Intent, indem es sie anhand von drei Aspekten mit Intent-Filtern vergleicht:

• Action –
• 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

Ein Intent-Filter kann null oder mehr <action>-Elemente angeben, um zulässige Intent-Aktionen anzugeben. Beispiel:

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

Um diesen Filter zu übergeben, muss die in Intent angegebene Aktion einer der im Filter aufgeführten Aktionen entsprechen.

Wenn der Filter keine Aktionen auflistet, gibt es nichts für einen Intent, der mit dem Test übereinstimmt. Daher bestehen alle Intents den Test nicht. Wenn eine Intent jedoch keine Aktion angibt, besteht der Test, solange der Filter mindestens eine Aktion enthält.

Kategorietest

Um zulässige Intent-Kategorien anzugeben, können in einem Intent-Filter null oder mehr <category>-Elemente deklariert werden, 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 Intent einer Kategorie im Filter entsprechen. Umgekehrt ist das nicht notwendig. Der Intent-Filter kann mehr Kategorien deklarieren, als in Intent angegeben sind, aber der Intent besteht weiterhin. 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 in ihren Intent-Filtern eine Kategorie für "android.intent.category.DEFAULT" enthalten, wie im vorherigen <intent-filter>-Beispiel gezeigt.

Datentest

Um akzeptierte Intent-Daten anzugeben, kann ein Intent-Filter null oder mehr <data>-Elemente angeben, 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>

Für jedes <data>-Element können eine URI-Struktur und ein Datentyp (MIME-Medientyp) angegeben werden. 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 ist com.example.project, der Port ist 200 und der Pfad ist 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.
• Sind weder das Schema noch der Host angegeben, wird der Pfad ignoriert.

Wird der URI in einem Intent mit einer URI-Spezifikation in einem Filter verglichen, gilt das nur für die Teile des URI, die im Filter enthalten sind. Beispiel:

• Wenn ein Filter nur ein Schema angibt, entsprechen alle URIs mit diesem Schema dem Filter.
• Gibt ein Filter ein Schema und eine Berechtigung, aber keinen Pfad an, übergeben alle URIs mit demselben Schema und derselben Berechtigung den Filter, unabhängig von ihren Pfaden.
• Gibt ein Filter ein Schema, eine Zertifizierungsstelle und einen Pfad an, übergeben nur URIs mit demselben Schema, derselben Autorisierung und demselben Pfad den Filter.

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. Es gelten folgende Regeln:

1. Ein Intent, der weder einen URI noch einen MIME-Typ enthält, besteht den Test nur dann, wenn der Filter keine URIs oder MIME-Typen angibt.
2. Ein Intent, der einen URI, aber keinen MIME-Typ (weder explizit noch aus dem URI abgeleitet) enthält, besteht nur dann den Test, 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 dann, wenn der Filter den gleichen MIME-Typ auflistet und kein URI-Format angibt.
4. Ein Intent, der sowohl einen URI als auch einen MIME-Typ (entweder explizit oder aus dem URI abgeleitet) enthält, besteht den MIME-Typ-Teil des Tests nur dann, wenn dieser Typ mit einem im Filter aufgeführten Typ übereinstimmt. Der URI-Teil des Tests wird übergeben, wenn sein URI mit einem URI im Filter übereinstimmt oder wenn er einen content:- oder file:-URI enthält und im Filter kein URI angegeben ist. Mit anderen Worten: Es wird davon ausgegangen, dass eine Komponente content:- und file:-Daten unterstützt, wenn ihr Filter nur einen MIME-Typ auflistet.

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

Diese letzte Regel, Regel (d), spiegelt die Erwartung wider, dass Komponenten lokale Daten von einer Datei oder einem Inhaltsanbieter 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, mit denen ein Datentyp, aber kein URI angegeben wird, sind wahrscheinlich am häufigsten, da die meisten verfügbaren Daten von Contentanbietern ausgegeben werden.

Eine weitere gängige Konfiguration ist ein Filter mit einem Schema und einem Datentyp. Über ein <data>-Element wie das folgende wird Android beispielsweise mitgeteilt, dass die Komponente zum Ausführen der Aktion Videodaten aus dem Netzwerk abrufen kann:

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

Intent-Abgleich

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

Ihre App kann den Intent-Abgleich auf ähnliche Weise wie die Home App verwenden. PackageManager enthält 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. queryIntentActivities() gibt beispielsweise eine Liste aller Aktivitäten zurück, die den als Argument übergebenen Intent ausführen können. queryIntentServices() gibt eine ähnliche Liste von Diensten zurück. Keine der Methoden aktiviert die Komponenten. Es werden nur die Komponenten aufgelistet, die reagieren können. Es gibt eine ähnliche Methode, queryBroadcastReceivers(), für Übertragungsempfänger.