Intents und Intent-Filter

Ein Intent ist ein Messaging-Objekt, 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 stellt einen einzelnen Bildschirm in einer App dar. Sie können eine neue Instanz eines Activity starten, indem Sie startActivity() eine Intent übergeben. Die 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() an. 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 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 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 auszuführen (z. B. das Herunterladen einer Datei), indem Sie Intent an startService() übergeben. Die 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 sich von einer anderen Komponente an den Dienst binden. Dazu übergeben Sie einen Intent an bindService(). Weitere Informationen finden Sie im Leitfaden Dienste.

• Broadcasts senden

  Eine Broadcast-Nachricht kann von jeder App empfangen werden. Das System sendet verschiedene Broadcasts für Systemereignisse, z. B. wenn das System gestartet wird oder das Gerät geladen wird. Sie können eine Übertragung an andere Apps senden, indem Sie eine 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 teilen.

Intent-Typen

Es gibt zwei Arten von Intents:

• Bei expliziten Intents wird angegeben, welche Komponente welcher Anwendung den Intent erfüllt. Dazu wird eine vollständige ComponentName angegeben. 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. So können Sie beispielsweise als Reaktion auf eine Nutzeraktion eine neue Aktivität in Ihrer App starten oder einen Dienst zum Herunterladen einer Datei im Hintergrund starten.
• 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.

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

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

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, wird ein Dialogfeld angezeigt, in dem der Nutzer auswählen kann, welche App verwendet werden soll.

Ein Intent-Filter ist ein Ausdruck in der Manifestdatei einer App, der den Typ der Intents angibt, die die Komponente empfangen soll. 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. 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 App sicher ist, sollten Sie beim Starten einer Service immer eine explizite Absicht verwenden und keine Intent-Filter für Ihre Dienste deklarieren. Die Verwendung einer impliziten Intent-Aktion zum Starten eines Dienstes stellt ein Sicherheitsrisiko dar, da Sie nicht sicher sein können, welcher Dienst auf die Intent-Aktion 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 festlegt, welche Komponente gestartet werden soll (z. B. der genaue Komponentenname oder die Komponentenkategorie, die den Intent erhalten soll). Außerdem enthält es Informationen, die die Empfängerkomponente verwendet, um die Aktion korrekt auszuführen (z. B. die auszuführende Aktion und die Daten, auf die sie angewendet werden soll).

Die wichtigsten Informationen in einer Intent sind:

Name der Komponente

Der Name der Komponente, die gestartet werden soll.

Diese Angabe ist optional, aber sie ist die wichtigste Information, die einen Intent explizit macht. Das bedeutet, dass der Intent nur an die App-Komponente gesendet werden sollte, die durch den Komponentennamen definiert ist. Ohne einen Komponentennamen ist die Absicht implizit und das System entscheidet anhand der anderen Absichtsinformationen (z. B. Aktion, Daten und Kategorie, siehe unten), welche Komponente die Absicht erhalten soll. Wenn Sie eine bestimmte Komponente in Ihrer App starten möchten, sollten Sie den Komponentennamen 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 mit dem Konstruktor Intent festlegen.

Aktion

Ein String, der die auszuführende allgemeine Aktion angibt, z. B. Ansehen oder Auswählen.

Bei einer Übertragungsabsicht ist dies die Aktion, die stattgefunden hat und gemeldet wird. Die Aktion bestimmt weitgehend, wie der Rest der Absicht strukturiert ist, insbesondere die Informationen in den Daten und Extras.

Sie können eigene Aktionen für die Verwendung durch Intents in Ihrer App (oder für die Verwendung durch andere Apps zum Aufrufen von Komponenten in Ihrer App) angeben. Normalerweise geben Sie jedoch Aktionskonstanten an, die von der Klasse Intent oder anderen Framework-Klassen definiert sind. 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 einem Nutzer in einer Aktivität angezeigt werden können, 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

Diese Intent-Art wird auch als Teilen-Intent bezeichnet. Sie sollten sie in einer Intent-Definition 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 für die Freigabe in sozialen Netzwerken.

Weitere Konstanten zum Definieren generischer Aktionen finden Sie in der Intent-Klassenreferenz. Andere Aktionen werden an anderer Stelle im Android-Framework definiert, z. B. unter Settings für Aktionen, die bestimmte Bildschirme in den 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, geben Sie den Paketnamen Ihrer App als Präfix an, 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 zu verarbeitenden Daten verweist, 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 ist, sollten die Daten die URI des zu bearbeitenden Dokuments enthalten.

Beim Erstellen einer Intent-Anfrage ist es oft wichtig, zusätzlich zum URI den Datentyp (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 zum Empfangen Ihrer 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 verwaltet 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. Falls erforderlich, können Sie beides mit setDataAndType() explizit 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 die URI als auch den MIME-Typ festzulegen.

Category

Ein String mit zusätzlichen Informationen zu der Art der Komponente, die den Intent verarbeiten soll. In einer Absicht können beliebig viele Kategoriebeschreibungen platziert werden. Für die meisten Absichten 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.

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 Intent-Klassenbeschreibung.

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

Die oben aufgeführten Eigenschaften (Name der Komponente, Aktion, Daten und Kategorie) sind die Merkmale, die eine Absicht definieren. Anhand dieser Eigenschaften 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 enthalten:

Extras

Schlüssel/Wert-Paare mit zusätzlichen Informationen, die für die Ausführung der angeforderten Aktion erforderlich sind. Genau wie einige Aktionen bestimmte Arten von Daten-URIs verwenden, werden für einige Aktionen auch bestimmte Extras verwendet.

Sie können zusätzliche Daten mit verschiedenen putExtra()-Methoden hinzufügen. Jede Methode akzeptiert zwei Parameter: 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 eigene zusätzliche Schlüssel deklarieren müssen (für Intents, die Ihre App empfängt), geben Sie den Paketnamen Ihrer App als Präfix an, 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 eine Intent senden, die eine andere App erhalten soll. Wenn eine App versucht, auf Daten in einem Bundle-Objekt zuzugreifen, aber keinen Zugriff auf die geparcellte 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 die Absicht. Die Flags können das Android-System anweisen, wie eine Aktivität gestartet werden soll (z. B. zu welcher Aufgabe sie 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 eine explizite Absicht

Mit einem expliziten Intent können 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-Eigenschaften sind optional.

Wenn Sie beispielsweise in Ihrer App einen Dienst namens 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 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 impliziten Intent

Ein impliziter Intent gibt eine Aktion an, die eine beliebige App auf dem Gerät aufrufen kann, die die Aktion ausführen kann. Die Verwendung eines impliziten Intents ist nützlich, wenn Ihre App die Aktion nicht ausführen kann, andere Apps dies aber wahrscheinlich tun können und Sie möchten, dass der Nutzer auswählt, welche App er verwenden möchte.

Wenn Sie beispielsweise Inhalte haben, die der Nutzer mit anderen teilen soll, erstellen Sie eine Intent-Aktion vom Typ ACTION_SEND und fügen Sie Extras hinzu, in denen die zu teilenden Inhalte angegeben werden. Wenn Sie startActivity() mit dieser Absicht 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 (Intent mit der Aktion ACTION_SEND und mit „text/plain“-Daten). Wenn es nur eine App gibt, die die Anfrage verarbeiten kann, wird diese App sofort geöffnet und erhält die Intent-Aktion. Wenn keine anderen Apps damit umgehen können, kann Ihre App die ActivityNotFoundException erfassen, die auftritt. Wenn mehrere Aktivitäten die Absicht 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 Apps finden Sie auch im Leitfaden zum Weiterleiten des Nutzers zu einer anderen 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, eine Standardeinstellung auszuwählen, ist hilfreich, wenn eine Aktion ausgeführt wird, für die der Nutzer wahrscheinlich jedes Mal dieselbe App verwenden möchte, z. B. beim Öffnen einer Webseite. Nutzer bevorzugen oft nur einen Webbrowser.

Wenn jedoch mehrere Apps auf die Absicht reagieren können und der Nutzer möglicherweise jedes Mal eine andere App verwenden möchte, sollten Sie ausdrücklich 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 die Aktion „Teilen“ mit der Aktion ACTION_SEND ausführt, möchten Nutzer möglicherweise je nach aktueller Situation die Freigabe über eine andere App vornehmen. Verwenden Sie daher immer das Auswahldialogfeld, wie in Abbildung 2 dargestellt.

Wenn Sie die Auswahl anzeigen möchten, erstellen Sie eine Intent mit createChooser() 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);
}

Gefährliche Intent-Ausführungen erkennen

Ihre App kann Intents starten, um zwischen Komponenten innerhalb 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 Debug-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 beide der folgenden Aktionen ausführt, erkennt das System einen unsicheren Intent-Start und es liegt ein Verstoß gegen den StrictMode vor:

1. Ihre Anwendung trennt einen verschachtelten Intent von den Extras eines übermittelten Intents.
2. Ihre App startet sofort eine App-Komponente mit dieser verschachtelten Absicht, indem sie die Absicht an startActivity(), startService() oder bindService() weitergibt.

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.

Auf unsichere Intent-Ausführungen prüfen

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 App einen StrictMode-Verstoß erkennt, sollten Sie die App-Ausführung beenden, um potenziell vertrauliche Daten 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());
}

Verantwortlichere Verwendung von Intents

Befolgen Sie diese 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. Das passiert, wenn Ihre App putExtras(Intent) oder putExtras(Bundle) aufruft. Wenn Ihre App einen dieser Vorgänge ausführt, kopieren Sie nur die Extras, die von der empfangenden Komponente erwartet werden. 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, legen Sie das android:exported-Attribut dieser Komponente auf false fest.

Verwenden Sie eine PendingIntent anstelle einer verschachtelten Absicht. Wenn eine andere App die PendingIntent aus der enthaltenen Intent entpackt, kann sie die PendingIntent mit der Identität Ihrer App starten. Mit dieser Konfiguration kann die andere App jede Komponente, einschließlich einer nicht exportierten Komponente, in Ihrer App sicher starten.

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

1. Ihre App erstellt einen Intent, der eine Aktivität in einer anderen App aufruft. In diesem Intent fügen Sie ein PendingIntent-Objekt als Extra hinzu. Dieses PendingIntent ruft eine Komponente in Ihrer App auf, die nicht exportiert wird.
2. Sobald die andere App den Intent Ihrer App empfängt, extrahiert sie das verschachtelte PendingIntent-Objekt.
3. Die andere App ruft die send()-Methode auf dem 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

Wenn Sie angeben möchten, welche impliziten Intents Ihre App empfangen kann, deklarieren Sie einen oder mehrere Intent-Filter für jede Ihrer App-Komponenten mit einem <intent-filter>-Element in Ihrer Manifestdatei. Mit 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.

Eine App-Komponente sollte separate Filter für jede einzelne Aufgabe angeben, die sie ausführen kann. Zum Beispiel kann eine Aktivität in einer Bildergalerie-App zwei Filter haben: einen Filter zum Ansehen eines Bildes und einen anderen Filter 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. ein <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 Fällen, 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 angeben, welche Art von Intents akzeptiert werden sollen:

<action>

 Definiert im name-Attribut, dass die Intent-Aktion akzeptiert wurde. Der Wert muss der Stringwert einer Aktion sein, nicht die Klassenkonstante.

<data>

Hier wird der akzeptierte Datentyp mit einem oder mehreren Attributen deklariert, die verschiedene Aspekte des Daten-URIs (scheme, host, port, path) und des MIME-Typs angeben.

<category>

 Definiert die Intent-Kategorie im Attribut name als akzeptiert. Der Wert muss der Stringwert einer Aktion sein, nicht die Klassenkonstante.

Hinweis:Wenn Sie implizite Intents erhalten möchten, müssen Sie die Kategorie CATEGORY_DEFAULT in den Intent-Filter aufnehmen. Bei den Methoden startActivity() und startActivityForResult() werden alle Intents so behandelt, als wäre die Kategorie CATEGORY_DEFAULT deklariert. Wenn Sie diese Kategorie nicht in Ihrem Intent-Filter angeben, werden keine impliziten Intents auf Ihre Aktivität angewendet.

Hier ist beispielsweise eine Aktivitätsdeklaration mit einem Intent-Filter, um eine 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 mehrere Instanzen 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, aber nur in bestimmten Kombinationen von 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 gesendet werden kann, muss er alle drei Tests bestehen. Wenn keine Übereinstimmung gefunden wird, sendet das Android-System die Intent nicht an die Komponente. Da eine Komponente jedoch mehrere Intent-Filter haben kann, kann ein Intent, der einen der Filter einer Komponente nicht besteht, möglicherweise durch einen anderen Filter passieren. Weitere Informationen dazu, wie das System Intents auflöst, finden Sie unten im Abschnitt Intent-Auflösung.

Hinweis:Sie müssen Ihre Intent-Filter für alle Aktivitäten in der Manifestdatei deklarieren. Filter für Broadcastempfänger können jedoch dynamisch registriert werden, indem registerReceiver() aufgerufen wird. Sie können den Empfänger dann bei unregisterReceiver() abmelden. So kann Ihre App nur während eines bestimmten Zeitraums auf bestimmte Übertragungen warten, während sie ausgeführt wird.

Beispielfilter

Hier ein Beispiel aus der Manifestdatei einer App für die soziale Medien-Teilen-Funktion, das einige der Verhaltensweisen von Intent-Filtern veranschaulicht:

<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 ü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 für diese Aktivität im App Launcher des Systems platziert werden sollte. Wenn für das Element <activity> kein Symbol mit icon angegeben ist, verwendet das System das Symbol aus dem Element <application>.

Diese beiden müssen zusammengeführt werden, 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

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

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 <intent-filter>-Elements übereinstimmt, das in Ihrer App deklariert ist. Dieses Verhalten tritt unabhängig von der Ziel-SDK-Version der sendenden App auf.

In den folgenden Fällen wird der Intent-Abgleich nicht erzwungen:

• Intents, die an Komponenten gesendet werden, für die keine Intent-Filter deklariert sind.
• Intents, die aus derselben App stammen.
• Vom System stammende Intents, 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 Abgleich nach Nutzerabsicht

Ausstehende Intents verwenden

Ein PendingIntent-Objekt ist ein Wrapper für ein Intent-Objekt. Der Hauptzweck einer PendingIntent besteht darin, einer externen Anwendung die Berechtigung zu erteilen, die darin enthaltenen Intent so zu verwenden, als würden sie über den Prozess Ihrer App ausgeführt.

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

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

Genauso wie jedes Intent-Objekt für die Verarbeitung durch eine bestimmte Art von App-Komponente (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 beim Erstellen der PendingIntent deklarieren, indem Sie die entsprechende Erstellungsmethode aufrufen:

• PendingIntent.getActivity() für einen Intent, der eine Activity startet.
• PendingIntent.getService() für einen Intent, der eine Service beginnt.
• 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 nimmt die aktuelle App-Context, die Intent, die Sie umschließen möchten, und eine oder mehrere Flags an, die angeben, wie der Intent verwendet werden soll, z. B. ob er mehrmals verwendet werden kann.

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

Mutabilität 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 angeben möchten, dass ein bestimmtes PendingIntent-Objekt verä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.

Erstellen Sie nach Möglichkeit unveränderliche ausstehende Intents.

In den meisten Fällen sollten Ihre Apps unveränderliche PendingIntent-Objekte erstellen, wie im folgenden Code-Snippet gezeigt. Wenn ein PendingIntent-Objekt unveränderlich ist, können andere Apps die Absicht nicht ändern, um das Ergebnis des Aufrufs der Absicht 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 wird diese Änderung angefordert, indem FILL_IN_CLIP_DATA als Flag an die Methode fillIn() übergeben wird.
• Benachrichtigungen mit dem Android Auto-Framework verknüpfen, indem Instanzen von CarAppExtender verwendet werden
• Unterhaltungen in Bubbles mithilfe von PendingIntent-Instanzen platzieren Mit einem veränderbaren PendingIntent-Objekt kann das System die richtigen Flags anwenden, z. B. FLAG_ACTIVITY_MULTIPLE_TASK und FLAG_ACTIVITY_NEW_DOCUMENT.
• Standortinformationen des Geräts anfordern, indem requestLocationUpdates() oder ähnliche APIs aufgerufen werden Mit dem veränderbaren PendingIntent-Objekt kann das System Intent-Extras hinzufügen, die Ereignisse des Standortlebenszyklus darstellen. Dazu gehören z. B. ein Standortwechsel und die Verfügbarkeit eines neuen Anbieters.
• Wecker mit AlarmManager planen Durch das veränderbare PendingIntent-Objekt kann das System die EXTRA_ALARM_COUNT-Intention zusätzlich hinzufügen. Diese Zusatzfunktion gibt an, wie oft ein wiederkehrender 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 App ein mutables PendingIntent-Objekt erstellt, sollten Sie unbedingt eine explizite Absicht verwenden und ComponentName ausfüllen. So wird immer dieselbe Komponente in Ihrer App gestartet, wenn eine andere App PendingIntent aufruft und die Steuerung an Ihre App zurückgibt.

Explizite Intents in ausstehenden Intents verwenden

Um besser zu definieren, wie andere Apps die ausstehenden Intents Ihrer App verwenden können, sollten Sie sie immer in einen expliziten Intent einbetten. Gehen Sie folgendermaßen vor, um diese Best Practice umzusetzen:

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

2. Verwenden Sie FLAG_IMMUTABLE, das in Android 6.0 (API-Ebene 23) hinzugefügt wurde, um ausstehende Intents zu erstellen. Dieses Flag verhindert, dass Anwendungen, die ein 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.
   }

Intent-Auflösung

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

• Aktion.
• Daten (URI und Datentyp)
• Kategorie:

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

Test für Aktion

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 für eine Intent jedoch keine Aktion angegeben ist, besteht der Test, sofern der Filter mindestens eine Aktion enthält.

Kategorietest

Um zulässige Intent-Kategorien anzugeben, kann ein Intent-Filter null oder mehr <category>-Elemente angeben, 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 mit einer Kategorie im Filter übereinstimmen. Umgekehrt ist das nicht notwendig. Der Intent-Filter kann mehr Kategorien angeben, als in der Intent angegeben sind, und die Intent wird trotzdem zugelassen. Daher besteht ein Intent ohne Kategorien diesen Test immer, unabhängig davon, welche Kategorien im Filter deklariert sind.

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

Datentest

Um zulässige 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 kann 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.
• Wenn weder das Schema noch der Host angegeben sind, 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.
• Wenn ein Filter ein Schema, eine Autorität und einen Pfad angibt, werden nur URIs mit demselben Schema, derselben Autorität und demselben Pfad durch den Filter gelassen.

Hinweis:Eine Pfadspezifikation kann einen Platzhalterstern (*) enthalten, um nur einen teilweisen Abgleich des Pfadnamens zu erfordern.

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 die folgenden Regeln:

1. Ein Intent, der weder einen URI noch einen MIME-Typ enthält, besteht den Test nur, wenn der Filter keine URIs oder MIME-Typen angibt.
2. Eine Intent-Anfrage, die einen URI, aber keinen MIME-Typ enthält (weder explizit noch aus dem URI ableitbar), besteht den Test nur, wenn ihr URI mit dem URI-Format des Filters übereinstimmt und der Filter ebenfalls keinen MIME-Typ angibt.
3. Eine Intent-Anfrage, die 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. Eine Intent-Anfrage, die sowohl einen URI als auch einen MIME-Typ enthält (entweder explizit oder aus dem URI ableitbar), besteht den Teil des Tests für den MIME-Typ nur, wenn dieser Typ mit einem im Filter aufgeführten Typ übereinstimmt. Der URI-Teil des Tests wird entweder übergeben, wenn sein 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: Eine Komponente wird als content:- und file:-kompatibel angesehen, wenn in ihrem Filter nur ein MIME-Typ aufgeführt ist.

Hinweis:Wenn in einer Intent-Definition ein URI oder MIME-Typ angegeben ist, schlägt der Datentest fehl, wenn die <intent-filter> keine <data>-Elemente enthält.

Diese letzte Regel (d) spiegelt die Erwartung wider, dass Komponenten lokale Daten von einem Datei- oder Inhaltsanbieter abrufen können. Daher können ihre Filter nur einen Datentyp enthalten und die content:- und file:-Schemata müssen nicht explizit genannt werden. 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. 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-Abgleich

Intents werden nicht nur mit Intent-Filtern abgeglichen, um eine zu aktivierende Zielkomponente zu finden, sondern auch, um etwas über die Komponenten auf dem Gerät zu erfahren. In der Home App werden beispielsweise alle Aktivitäten mit Intent-Filtern ermittelt, 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 IntentFilter-Klasse beschrieben.

Ihre Anwendung kann das Abgleichen von Intents ähnlich wie in der Home App verwenden. Der PackageManager hat 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 Beantwortung eines Intents ermitteln. Beispielsweise gibt queryIntentActivities() eine Liste aller Aktivitäten zurück, die den als Argument übergebenen Intent ausführen können, und queryIntentServices() eine ähnliche Liste von Diensten. Mit keiner der beiden Methoden werden die Komponenten aktiviert. Es werden nur die Komponenten aufgelistet, die antworten können. Es gibt eine ähnliche Methode, queryBroadcastReceivers(), für Übertragungsempfänger.