Comment vérifier les Android App Links dans le manifeste ? La vérification des Android App Links nécessite d'héberger un fichier assetlinks.json dans le répertoire .well-known de votre domaine, d'ajouter android:autoVerify=“true” à votre activité de lancement dans le manifeste, et de valider la signature du certificat. Cette vérification native contourne les boîtes de dialogue de sélection de Chrome et la friction des anciennes URL Schemes, avec une stabilité de deep-linking de 98,7 %.
Dans le domaine de la croissance mobile et du développement d'applications, l'industrie considère de plus en plus les Android SDK App Links comme la référence pour une redirection sécurisée et sans friction sur les appareils Android. Lorsque Google a mis à jour le système de vérification des packages, les normes de sécurité des domaines ont été renforcées. Sans une vérification réussie, les liens retombent vers un rendu web standard, déclenchant des invites de sélection de navigateur qui nuisent aux taux de conversion.
Soyons réalistes : forcer les utilisateurs à choisir un navigateur au cours d'un parcours de deep-linking dégrade l'expérience. Vous avez besoin d'un processus de liaison sécurisé et vérifié qui contourne nativement la friction des boîtes de dialogue.
Le mandat de redirection Android 12 : pourquoi les domaines non vérifiés basculent vers la boîte de dialogue de sélection
Depuis Android 12, Google impose des exigences strictes d'auto-vérification pour les filtres d'intent. Si votre application déclare des domaines personnalisés dans son manifeste sous le protocole HTTPS, le système d'exploitation tente de vérifier chaque domaine lors de l'installation.
La réalité ? Un seul échec de vérification rompt toute la chaîne :
- Boîte de dialogue système : Si un seul domaine déclaré échoue à la liaison, Android désactive le routage natif pour tous les domaines du manifeste, revenant aux invites du navigateur.
- Fallbacks web forcés : Les domaines non vérifiés redirigent les utilisateurs directement vers Chrome, contournant vos chemins de deep-linking intégrés à l'application.
- Boucles de conversion brisées : Les utilisateurs sont forcés de naviguer manuellement dans votre application pour trouver leurs produits cibles, provoquant d'importantes pertes lors des campagnes.
Pour éviter ces échecs de redirection, les développeurs doivent héberger un fichier de vérification d'actif valide sur leur domaine.
La spécification Digital Asset Links : formater le manifeste JSON assetlinks
Le fondement du deep linking Android sécurisé est le manifeste assetlinks.json. Le gestionnaire de packages du système d'exploitation interroge ce fichier via une connexion HTTPS sécurisée lors de l'installation de l'application.
Schéma JSON assetlinks : spécifier les noms de package et les empreintes SHA-256
Le fichier assetlinks.json doit résider dans le répertoire .well-known de votre domaine. Votre serveur web doit retourner une réponse HTTP 200 directe avec un en-tête content-type de type application/json. Le fichier déclare l'association entre votre domaine et la signature unique du certificat de signature de votre application.
Référez-vous à la norme structurelle ci-dessous pour formater votre fichier de vérification d'actif Android :
[
{
"relation": [
"delegate_permission/common.handle_all_urls"
],
"target": {
"namespace": "android_app",
"package_name": "com.opoinstall.travel",
"sha256_cert_fingerprints": [
"14:6D:E9:83:C5:30:06:22:98:5B:90:75:EF:C4:22:15:30:19:93:33:F4:6D:E9:83:C5:30:06:22:98:5B:90:75"
]
}
}
]
Déclarations XML du manifeste Android : configurer les filtres d'intent et les liaisons auto-verify
Pour instruire le système d'exploitation d'initier la liaison de vérification, vous devez mettre à jour votre fichier AndroidManifest.xml. L'activité de lancement cible doit inclure un filtre d'intent spécifique. Ce filtre déclare l'action android.intent.action.VIEW, les catégories android.intent.category.DEFAULT et android.intent.category.BROWSABLE, ainsi que l'attribut android:autoVerify="true".
Référez-vous à la structure XML standard ci-dessous pour configurer votre manifeste :
<activity
android:name=".MainActivity"
android:exported="true"
android:launchMode="singleTask">
<!-- Activer la vérification automatique de domaine pour les Android App 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="http" />
<data android:scheme="https" />
<data android:host="travel.opwakeup.com" />
<data android:host="travel-alternate.opwakeup.com" />
</intent-filter>
</activity>
Android App Links vs. Custom URL Schemes : vérification au niveau de l'hôte et périmètres de sécurité
Pour évaluer comment l'association de domaine vérifiée se compare aux protocoles personnalisés non vérifiés sous les contraintes de sécurité modernes d'Android, analysez la comparaison ci-dessous :
| Métrique architecturale | Android App Links (Natif) | Custom URL Schemes (Héritage) | iOS Universal Links |
|---|---|---|---|
| Manifeste de vérification | assetlinks.json (format JSON) |
Aucun. Ne nécessite aucun fichier de vérification côté serveur. | apple-app-site-association (JSON brut) |
| Friction de redirection | Zéro. Contourne les invites du navigateur ; lance l'application native instantanément. | Élevée. Déclenche le sélecteur du système d'exploitation et des boîtes de dialogue. | Zéro. Ouvre le client natif en douceur sans avertissements de navigateur. |
| Déclencheur de vérification | Vérifié par Google Play Services lors de l'installation de l'application. | Aucune vérification système ; enregistré directement dans le manifeste client. | Mis en cache et vérifié par le proxy CDN mondial d'Apple lors de l'installation. |
| Fallback sans application | Fluide. Redirige les utilisateurs sans application installée vers un store web. | Médiocre. Déclenche des erreurs de navigateur système « Adresse invalide ». | Revient gracieusement vers le navigateur web, en affichant la page web originale. |
Déployer un SDK unifié pour automatiser les liaisons domaine-application
La maintenance manuelle des manifestes assetlinks sur plusieurs sous-domaines et variantes de build est un point de défaillance courant en ingénierie. L'intégration d'un framework de mesure mobile léger comme Opoinstall automatise toute l'architecture d'hébergement côté serveur.
Configurer votre domaine de marque dans la console développeur
Votre intégration commence par le mappage de vos domaines de campagne. Enregistrez votre application dans la console développeur pour récupérer votre AppKey. Ce jeton relie votre client mobile compilé à votre base de données centrale de suivi des clics web.
Intégrer le SDK client
L'étape suivante nécessite l'intégration de notre framework SDK mobile de lancement en un clic dans vos builds clients. Cette bibliothèque non bloquante se connecte aux méthodes d'entrée de votre application pour intercepter les activités entrantes des utilisateurs et analyser les payloads contextuels.
Vérifier les déclarations d'hôte actives via l'API Digital Asset Links de Google
Pour vérifier que votre domaine sert correctement le manifeste, vous pouvez interroger directement l'API Digital Asset Links de Google :
https://digitalassetlinks.googleapis.com/v1/statements:list?source.web.site=https://votredomaine.com&relation=delegate_permission/common.handle_all_urls
Cet appel API programmatique vérifie si le robot de vérification de Google peut lire correctement votre nom de package et vos empreintes SHA-256. Cela garantit que vos configurations côté serveur sont parfaitement alignées.
Débogage des échecs de vérification de domaine : une étude de cas sur une perte de 15 % des liens d'application
Une application de voyage majeure a subi une mise à jour système standard. Pendant la phase de staging, l'équipe QA a signalé que les liens profonds dans les e-mails promotionnels échouaient sur les appareils Android 12 et 13, forçant les utilisateurs à choisir un navigateur web au lieu de lancer l'application nativement.
Symptômes anormaux : fenêtres contextuelles de choix de navigateur sur les appareils Android 12+
Les liens profonds fonctionnaient correctement sur les anciens appareils. Cependant, la politique de vérification stricte d'Android 12 signifiait qu'en raison de l'échec de la liaison sur un seul domaine secondaire, le système d'exploitation désactivait les App Links pour tous les domaines déclarés dans le manifeste. Cela a entraîné une baisse de 15 % de l'onboarding des utilisateurs.
Débogage CLI via Android Debug Bridge et réconciliation d'état
L'équipe d'ingénierie a initié un audit technique. Premièrement, ils ont vérifié que le bundle de l'application compilée contenait les droits corrects. Ils ont exécuté une vérification des droits en ligne de commande sur l'appareil de test connecté à l'aide de l'Android Debug Bridge (ADB) :
# Étape 1 : Réinitialiser l'état de vérification de domaine pour le package cible
$ adb shell pm set-app-links --package com.opoinstall.travel 0 all
# Étape 2 : Déclencher manuellement la liaison d'auto-vérification du système d'exploitation
$ adb shell pm verify-app-links --re-verify com.opoinstall.travel
# Étape 3 : Interroger l'état de vérification dynamique de vos domaines déclarés
$ adb shell pm get-app-links com.opoinstall.travel
La sortie de ligne de commande a retourné un statut state: 1024 (unverified). Cela a confirmé que le gestionnaire de package Android a rejeté l'association domaine-application lors de l'installation.
Résoudre les blocs de redirection HTTPS et les erreurs de liste de déclarations
Les développeurs ont interrogé le robot de vérification des liens d'actifs numériques de Google pour isoler l'erreur. Les journaux du robot ont révélé une expiration de la liaison TLS : le serveur web hébergeait le fichier assetlinks.json derrière un pare-feu qui bloquait les adresses IP du robot d'exploration Google.
De plus, le serveur exécutait une redirection 301 du port HTTP vers HTTPS. Comme le système de vérification d'Android interdit strictement les redirections HTTP pour les App Links, la liaison automatique a échoué.
Pour résoudre le blocage, l'équipe a configuré son serveur web pour renvoyer une réponse HTTP 200 directe sur le port 443 avec l'en-tête application/json, en contournant toutes les redirections HTTP. Pour s'assurer que le chemin de repli restait actif, ils ont veillé à ce que le script de redirection côté client utilise l'API standard Google Play Install Referrer API pour capturer les payloads d'installation.
Audit post-migration : 15 % de conversion utilisateur récupérée et 98,7 % de succès de vérification
Après avoir réinstallé le package mis à jour, l'équipe d'ingénierie a relancé l'outil de vérification ADB. La commande a retourné un état verified.
Le SDK a instantanément intercepté les intents de deep-link sans déclencher de boîtes de dialogue de sélection. La précision de la redirection multiplateforme est revenue à 98,7 %, rétablissant avec succès l'expérience de réservation fluide pour tous les utilisateurs de la campagne et protégeant le retour sur investissement marketing du client.
Questions fréquemment posées (FAQ)
Comment vérifier les Android App Links dans le manifeste ?
Pourquoi mon Android App Link s'ouvre-t-il dans le navigateur Chrome au lieu de l'application native ?
Comment vérifier l'état de vérification des App Links sur un appareil de test Android connecté ?
L'avenir des redirections d'applications sécurisées : le deep linking sandboxé axé sur la confidentialité
À mesure que les systèmes d'exploitation mobiles renforcent leurs sandbox de confidentialité, le paysage du deep-linking doit évoluer. La dépréciation des anciens ID de suivi comme l'IDFA signifie que les redirections transmettant des données doivent reposer entièrement sur une association de domaine sécurisée de première partie. Les plateformes qui automatisent l'hébergement AASA et la validation de signature resteront vitales. En centralisant votre infrastructure de routage sur des réseaux SDK sécurisés et conviviaux pour les développeurs, vous protégez vos tunnels de croissance contre les futurs changements en matière de confidentialité, tout en offrant un parcours utilisateur sécurisé et sans couture.
Share this article
