Intent Filter: Was es ist, wie es funktioniert und in der Entwicklung verwendet wird

Was ist ein Intent Filter?

Intent Filter ist ein Konfigurationselement einer Android-Anwendung, das dem System mitteilt, dass die Komponente bestimmte Arten von impliziten Intents verarbeiten kann. Im Gegensatz zu expliziten Intents, die eine bestimmte Klasse angeben, enthalten implizite Intents nur eine Beschreibung der erforderlichen Aktion, und das System selbst findet eine geeignete Komponente basierend auf registrierten Filtern.

Filter werden innerhalb einer Komponente — Activity, Service oder BroadcastReceiver — in der Datei AndroidManifest.xml deklariert. Jeder Filter kann mehrere Action-, Category- und Data-Elemente enthalten. Eine Komponente kann eine unbegrenzte Anzahl von Intent Filtern haben, die jeweils ein separates Verarbeitungsszenario beschreiben.

Rolle in der Android-Architektur

Intent Filter implementiert das Prinzip der losen Kopplung zwischen Anwendungskomponenten. Anwendung A muss nicht von der Existenz der Anwendung B wissen — sie sendet einfach einen Intent mit einer Aktionsbeschreibung, und das System leitet ihn basierend auf Filtern weiter. Dieser Mechanismus liegt Share Sheet, Browserauswahl und Deep-Link-Verarbeitung zugrunde.

Arten von Intent: Explizite und implizite

Explizite Intents geben eine bestimmte zu startende Komponentenklasse an. Sie werden für die interne Navigation innerhalb einer einzelnen Anwendung verwendet, wenn der Entwickler genau weiß, welche Activity geöffnet werden soll. Implizite Intents enthalten nur eine Aktionsbeschreibung, und die Komponente wird dynamisch vom System bestimmt.

Intent Filter arbeitet ausschließlich mit impliziten Intents. Wenn ein Intent eine bestimmte Klasse angibt, ignoriert das System alle Filter und startet die angegebene Komponente direkt. Filter werden nur beim Auflösen impliziter Aufrufe überprüft, was sie zu einem Schlüsselelement der anwendungsübergreifenden Interaktion macht.

Vergleich von expliziten und impliziten Intents

Struktur des Intent Filter im Manifest

Jeder Intent Filter besteht aus drei Gruppen von Elementen — action, category und data — deren Kombination bestimmt, welche Intents die Komponente erhält. Ein Filter gilt als erfüllt, wenn der Intent mit mindestens einem Element jeder Gruppe übereinstimmt.

Action beschreibt die ausgeführte Aktion — Anzeigen, Bearbeiten, Senden. Category fügt zusätzlichen Verarbeitungskontext hinzu — zum Beispiel die Möglichkeit, aus einem Browser heraus zu starten. Data definiert das Format der verarbeiteten Informationen über URI oder MIME-Typ.

Komponenten des intent-filter-Tags

Beispiel für einen Intent Filter für eine Activity, die Links zu Benutzerprofilen öffnet. Der Filter enthält alle drei Gruppen von Elementen für eine präzise Weiterleitung.

<activity android:name=".ProfileActivity">
    <intent-filter>
        <action
            android:name="android.intent.action.VIEW" />
        <category
            android:name="android.intent.category.DEFAULT" />
        <category
            android:name="android.intent.category.BROWSABLE" />
        <data
            android:scheme="myapp"
            android:host="profile" />
    </intent-filter>
</activity>

Beachten Sie die obligatorische Angabe von category DEFAULT — ohne sie leitet das System keine impliziten Intents an die Komponente weiter. Die Kategorie BROWSABLE wird hinzugefügt, wenn der Link aus einem Browser heraus verarbeitet werden soll.

Intent Filter für Deep Links

Ein Deep Link auf Android wird über einen Intent Filter mit action VIEW und einem data-Tag mit Schema, Host und Pfad konfiguriert. Beim Folgen eines Links wie myapp://profile/42 findet das System eine Activity mit einem passenden Filter und startet sie mit der übergebenen URI. Es ist wichtig, pathPrefix, pathPattern oder path für eine genaue Übereinstimmung korrekt zu konfigurieren.

Ab Android 6 (API 23) wurde Unterstützung für App Links hinzugefügt — verifizierte Deep Links über HTTPS. App Links verwenden denselben Intent Filter, jedoch mit zusätzlicher Domain-Überprüfung über Digital Asset Links. Nach der Überprüfung öffnet das System die Anwendung automatisch ohne Auswahldialog.

Data-Tag für URL

Beispiel für einen Filter für App Link mit Verifizierung über HTTPS-Link. In diesem Fall ist das Schema immer https und der Host entspricht der in Digital Asset Links angegebenen Domain.

<intent-filter android:autoVerify="true">
    <action
        android:name="android.intent.action.VIEW" />
    <category
        android:name="android.intent.category.DEFAULT" />
    <category
        android:name="android.intent.category.BROWSABLE" />
    <data
        android:scheme="https"
        android:host="example.com"
        android:pathPrefix="/profile" />
</intent-filter>

Das Attribut autoVerify weist das System an, bei der Installation der Anwendung die Digital Asset Links zu überprüfen. Wenn die Verifizierung erfolgreich ist, wird die Anwendung automatisch zum Standard-Handler für die angegebene Domain und Pfade.

Intent-Verarbeitung in Anwendungskomponenten

Nachdem das System eine Komponente zur Verarbeitung des Intent ausgewählt hat, muss der Entwickler Daten aus dem eingehenden Intent innerhalb der Zielkomponente extrahieren. Für Activity wird die Methode getIntent() in onCreate() verwendet; für BroadcastReceiver die Methode onReceive(), wobei Intent als Parameter übergeben wird.

Die Datenextraktion umfasst das Abrufen der action zur Bestimmung des Vorgangstyps, data für die URI und extra-Parameter für zusätzliche Informationen. Jedes dieser Elemente kann fehlen, daher ist eine Null-Prüfung vor der Verwendung obligatorisch.

Verarbeitungscode in Activity

Beispiel für die Verarbeitung eines eingehenden Deep Links in einer Activity in Kotlin. Der Code extrahiert die URI aus dem Intent und trifft Navigationsentscheidungen basierend auf Host und Pfad.

class ProfileActivity : AppCompatActivity() {
    override fun onCreate(savedInstanceState: Bundle?) {
        super.onCreate(savedInstanceState)
        val uri = intent?.data
        if (uri?.host == "profile") {
            val userId = uri.lastPathSegment
            loadProfile(userId)
        }
    }
}

Es wird empfohlen, den Safe-Call-Operator zu verwenden, um intent und data auf null zu prüfen, da die Aktivitat auch ohne eingehenden Deep Link gestartet werden kann. Sie sollten auch host und pathSegment vor der Verwendung in der Navigation auf null prüfen.

Priorität und Konfliktlösung

Wenn mehrere Anwendungen einen Intent Filter registriert haben, der mit demselben impliziten Intent übereinstimmt, zeigt das System dem Benutzer einen Auswahldialog an. Der Benutzer kann eine Anwendung für die einmalige Verwendung auswählen oder einen Standard-Handler festlegen. Ab Android 10 wird der Auswahldialog nur beim ersten Aufruf angezeigt, danach merkt sich das System die Auswahl des Benutzers.

Zur Verwaltung der Priorität wird das Attribut android:priority im intent-filter-Tag verwendet. Je höher der Wert, desto höher die Priorität der Komponente bei der Konfliktlösung. Die Priorität funktioniert jedoch nicht für Filter aus verschiedenen Anwendungen — in diesem Fall wird immer ein Auswahldialog angezeigt, wenn keine Anwendung als Standard festgelegt ist.

Auswahldialog für Anwendung

Der Entwickler kann den Auswahldialog programmatisch über Intent.createChooser() aufrufen, indem er den Ziel-Intent und einen Titel übergibt. Dies ist nützlich, wenn eine Anwendung dem Benutzer explizit die Auswahl eines Handlers anbieten möchte, auch wenn eine Standardanwendung festgelegt ist. Zum Beispiel garantiert das Senden von Bildern an soziale Netzwerke über ACTION_SEND mit createChooser die Anzeige des Dialogs unabhängig von den Standardeinstellungen.

Häufige Fehler bei der Konfiguration von Intent Filter

Einer der häufigsten Fehler ist das Fehlen der DEFAULT-Kategorie im Intent Filter. Entwickler kopieren die Konfiguration aus Beispielen, vergessen aber, diese Kategorie hinzuzufügen, mit der Folge, dass die Activity keine impliziten Intents erhält. Das System sieht den Filter für implizite Aufrufe einfach nicht, obwohl explizite Intents weiterhin funktionieren.

Der zweite häufige Fehler ist die falsche Angabe von scheme im data-Tag ohne vollständige URI. Wenn nur das Schema angegeben, aber der Host nicht angegeben ist, akzeptiert der Filter alle Links mit diesem Schema aus jeder Quelle, was zu unerwünschten Aufrufen aus nicht vertrauenswürdigen Quellen führen kann. Es wird empfohlen, immer mindestens scheme und host anzugeben.

Der dritte Fehler ist das Fehlen einer Null-Prüfung für intent.data im Activity-Code. Wird die Activity nicht über einen Deep Link, sondern auf dem Standardweg aus dem Launcher gestartet, enthält der Intent keine URI. Der Zugriff auf intent.data ohne Prüfung verursacht eine NullPointerException und einen Absturz der Anwendung. Verwenden Sie immer intent?.data?.toString() mit dem Safe-Call-Operator.