Intent Filter : ce que c’est, comment ça fonctionne et son utilisation en développement

Qu’est-ce qu’un Intent Filter ?

Intent Filter est un élément de configuration d’une application Android qui informe le système de la capacité du composant à traiter certains types d’intentions implicites. Contrairement aux Intents explicites qui spécifient une classe concrète, les Intents implicites contiennent uniquement une description de l’action requise, et le système lui-même trouve un composant approprié en se basant sur les filtres enregistrés.

Les filtres sont déclarés à l’intérieur d’un composant — Activity, Service ou BroadcastReceiver — dans le fichier AndroidManifest.xml. Chaque filtre peut contenir plusieurs éléments action, category et data. Un composant peut avoir un nombre illimité d’Intent Filters, chacun décrivant un scénario de traitement distinct.

Rôle dans l’architecture Android

Intent Filter implémente le principe de couplage faible entre les composants d’applications. L’application A n’a pas besoin de connaître l’existence de l’application B — elle envoie simplement un Intent avec la description de l’action, et le système l’achemine en fonction des filtres. Ce mécanisme est à la base de Share Sheet, de la sélection du navigateur et du traitement des deep links.

Types d’Intent : explicites et implicites

Les Intents explicites spécifient une classe de composant concrète à lancer. Ils sont utilisés pour la navigation interne au sein d’une seule application lorsque le développeur sait exactement quelle Activity doit s’ouvrir. Les Intents implicites contiennent uniquement une description de l’action, et le composant est déterminé dynamiquement par le système.

Intent Filter fonctionne exclusivement avec les Intents implicites. Si un Intent spécifie une classe concrète, le système ignore tous les filtres et lance directement le composant spécifié. Les filtres ne sont vérifiés que lors de la résolution des appels implicites, ce qui en fait un élément clé de l’interaction entre applications.

Comparaison des Intents explicites et implicites

Structure d’Intent Filter dans le manifeste

Chaque Intent Filter se compose de trois groupes d’éléments — action, category et data — dont la combinaison détermine quels Intents le composant recevra. Un filtre est considéré comme satisfait si l’Intent correspond à au moins un élément de chaque groupe.

Action décrit l’action en cours d’exécution — afficher, modifier, envoyer. Category ajoute un contexte de traitement supplémentaire — par exemple, la possibilité de lancer depuis le navigateur. Data définit le format des informations traitées via l’URI ou le type MIME.

Composants de la balise intent-filter

Exemple d’un Intent Filter pour une Activity qui ouvre des liens vers des profils utilisateur. Le filtre inclut les trois groupes d’éléments pour un routage précis.

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

Notez la spécification obligatoire de category DEFAULT — sans elle, le système ne transmettra pas d’Intents implicites au composant. La catégorie BROWSABLE est ajoutée si le lien doit être traité depuis un navigateur.

Intent Filter pour les deep links

Un deep link sur Android se configure via un Intent Filter avec action VIEW et une balise data contenant le schéma, l’hôte et le chemin. En suivant un lien comme myapp://profile/42, le système trouve une Activity avec un filtre correspondant et la lance avec l’URI transmis. Il est important de configurer correctement pathPrefix, pathPattern ou path pour une correspondance exacte.

À partir d’Android 6 (API 23), la prise en charge des App Links a été ajoutée — des deep links vérifiés via HTTPS. Les App Links utilisent le même Intent Filter mais avec une vérification supplémentaire du domaine via Digital Asset Links. Après la vérification, le système ouvre automatiquement l’application sans boîte de dialogue de sélection.

Balise Data pour l’URL

Exemple de filtre pour App Link avec vérification via lien HTTPS. Dans ce cas, le schéma est toujours https et l’hôte correspond au domaine spécifié dans Digital Asset Links.

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

L’attribut autoVerify indique au système de vérifier les Digital Asset Links lors de l’installation de l’application. Si la vérification réussit, l’application devient automatiquement le gestionnaire par défaut pour le domaine et les chemins spécifiés.

Traitement d’Intent dans les composants d’application

Après que le système a sélectionné un composant pour traiter l’Intent, le développeur doit extraire les données de l’intent entrant à l’intérieur du composant cible. Pour Activity, la méthode getIntent() dans onCreate() est utilisée ; pour BroadcastReceiver, la méthode onReceive(), où Intent est passé en paramètre.

L’extraction des données comprend l’obtention de l’action pour déterminer le type d’opération, data pour l’URI et les paramètres supplémentaires pour les informations additionnelles. Chacun de ces éléments peut être absent, donc une vérification de null est obligatoire avant utilisation.

Code de traitement dans Activity

Exemple de traitement d’un deep link entrant dans une Activity en Kotlin. Le code extrait l’URI de l’Intent et prend des décisions de navigation en fonction de l’hôte et du chemin.

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

Il est recommandé d’utiliser l’opérateur safe call pour vérifier intent et data pour null, car l’activité peut être lancée sans deep link entrant. Vous devez également vérifier host et pathSegment pour null avant de les utiliser dans la navigation.

Priorité et résolution des conflits

Si plusieurs applications ont enregistré un Intent Filter correspondant au même Intent implicite, le système affiche à l’utilisateur une boîte de dialogue de sélection. L’utilisateur peut sélectionner une application pour une utilisation unique ou définir un gestionnaire par défaut. À partir d’Android 10, la boîte de dialogue de sélection n’est affichée que lors du premier appel, après quoi le système mémorise le choix de l’utilisateur.

Pour gérer la priorité, l’attribut android:priority dans la balise intent-filter est utilisé. Plus la valeur est élevée, plus la priorité du composant est grande lors de la résolution des conflits. Cependant, la priorité ne fonctionne pas pour les filtres de différentes applications — dans ce cas, une boîte de dialogue de sélection est toujours affichée si aucune application n’est définie par défaut.

Boîte de dialogue de sélection d’application

Le développeur peut appeler programmatiquement la boîte de dialogue de sélection via Intent.createChooser(), en passant l’Intent cible et un titre. Ceci est utile lorsqu’une application souhaite offrir explicitement à l’utilisateur le choix d’un gestionnaire, même si une application par défaut est définie. Par exemple, lors de l’envoi d’images aux réseaux sociaux via ACTION_SEND avec createChooser garantit l’affichage de la boîte de dialogue indépendamment des paramètres par défaut.

Erreurs courantes lors de la configuration d’Intent Filter

L’une des erreurs les plus fréquentes est l’absence de la catégorie DEFAULT dans l’Intent Filter. Les développeurs copient la configuration à partir d’exemples mais oublient d’ajouter cette catégorie, ce qui fait que l’Activity ne reçoit pas les Intents implicites. Le système ne voit tout simplement pas le filtre pour les appels implicites, bien que les Intents explicites continuent de fonctionner.

La deuxième erreur courante est la spécification incorrecte de scheme dans la balise data sans URI complet. Si seul le schéma est spécifié mais pas l’hôte, le filtre acceptera tous les liens avec ce schéma provenant de n’importe quelle source, ce qui peut conduire à des appels indésirables provenant de sources non fiables. Il est recommandé de toujours spécifier au moins scheme et host.

La troisième erreur est l’absence de vérification de null pour intent.data dans le code de l’Activity. Si l’Activity est lancée non pas via un deep link mais de manière standard depuis le lanceur, l’Intent ne contient pas d’URI. L’accès à intent.data sans vérification provoque une NullPointerException et un plantage de l’application. Utilisez toujours intent?.data?.toString() avec l’opérateur safe call.