Android App Links est un type spécial de lien profond qui permet aux URL de votre site Web d'ouvrir immédiatement le contenu correspondant dans votre application Android, sans que l'utilisateur ait à sélectionner l'application. Android App Links utilise l'API Digital Asset Links pour établir que votre application a été approuvée par le site Web pour ouvrir automatiquement les liens de ce domaine. Si le système vérifie que vous êtes bien le propriétaire des URL, il achemine automatiquement ces intents d'URL vers votre application.
Pour confirmer que vous êtes le propriétaire de votre application et des URL du site Web, procédez comme suit:
Ajoutez des filtres d'intent contenant l'attribut
autoVerify. Cet attribut indique au système qu'il doit vérifier si votre application appartient aux domaines d'URL utilisés dans vos filtres d'intent.Déclarez l'association entre votre site Web et vos filtres d'intent en hébergeant un fichier JSON Digital Asset Links à l'emplacement suivant:
https://domain.name/.well-known/assetlinks.json
Vous trouverez des informations associées dans les ressources suivantes:
- Compatibilité avec les URL et l'indexation des applications dans Android Studio
- Créer une liste d'instructions
Ajouter des filtres d'intent pour la validation des liens d'application
Pour activer la validation de la gestion des liens pour votre application, ajoutez des filtres d'intent correspondant au format suivant:
<!-- Make sure you explicitly set android:autoVerify to "true". -->
<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" />
<!-- If a user clicks on a shared link that uses the "http" scheme, your
app should be able to delegate that traffic to "https". -->
<data android:scheme="http" />
<data android:scheme="https" />
<!-- Include one or more domains that should be verified. -->
<data android:host="..." />
</intent-filter>
Bien qu'il soit suffisant d'inclure autoVerify dans une seule déclaration <intent-filter> pour chaque hôte, même si cet hôte est utilisé dans d'autres déclarations non marquées, nous vous recommandons d'ajouter autoVerify à chaque élément <intent-filter> par souci de cohérence. Cela garantit également qu'après avoir supprimé ou refactorisé des éléments de votre fichier manifeste, votre application reste associée à tous les domaines que vous définissez encore.
Le processus de validation du domaine nécessite une connexion Internet et peut prendre un certain temps. Pour améliorer l'efficacité du processus, le système ne valide un domaine pour une application qui cible Android 12 ou version ultérieure que si ce domaine se trouve dans un élément <intent-filter> contenant le format exact spécifié dans l'extrait de code précédent.
Prendre en charge l'association d'applications pour plusieurs hôtes
Le système doit pouvoir vérifier l'hôte spécifié dans les éléments de données des filtres d'intent d'URL de l'application par rapport aux fichiers Digital Asset Links hébergés sur les domaines Web respectifs de ce filtre d'intent. Si la validation échoue, le système adopte par défaut son comportement standard pour résoudre l'intent, comme décrit dans la section Créer des liens profonds vers le contenu d'une application. Toutefois, l'application peut toujours être validée en tant que gestionnaire par défaut pour tous les formats d'URL définis dans les autres filtres d'intent de l'application.
Remarque:Sur Android 11 (niveau d'API 30) ou version antérieure, le système ne valide pas votre application en tant que gestionnaire par défaut, sauf s'il trouve un fichier Digital Asset Links correspondant pour tous les hôtes que vous définissez dans le fichier manifeste.
Par exemple, une application avec les filtres d'intent suivants ne réussirait la validation que pour https://www.example.com si un fichier assetlinks.json était détecté dans https://www.example.com/.well-known/assetlinks.json, mais pas dans https://www.example.net/.well-known/assetlinks.json:
<application>
<activity android:name=”MainActivity”>
<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="www.example.com" />
</intent-filter>
</activity>
<activity android:name=”SecondActivity”>
<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="https" />
<data android:host="www.example.net" />
</intent-filter>
</activity>
</application>
Remarque:Tous les éléments <data> du même filtre d'intent sont fusionnés pour prendre en compte toutes les variantes de leurs attributs combinés. Par exemple, le premier filtre d'intent ci-dessus inclut un élément <data> qui ne déclare que le schéma HTTPS. Toutefois, il est associé à l'autre élément <data> afin que le filtre d'intent accepte à la fois http://www.example.com et https://www.example.com.
Par conséquent, vous devez créer des filtres d'intent distincts lorsque vous souhaitez définir des combinaisons spécifiques de schémas d'URI et de domaines.
Permettre l'association d'applications pour plusieurs sous-domaines
Le protocole Digital Asset Links traite les sous-domaines de vos filtres d'intent comme des hôtes uniques et distincts. Par conséquent, si votre filtre d'intent répertorie plusieurs hôtes avec différents sous-domaines, vous devez publier un assetlinks.json valide sur chaque domaine. Par exemple, le filtre d'intent suivant inclut www.example.com et mobile.example.com comme hôtes d'URL d'intent acceptés. Un assetlinks.json valide doit donc être publié à la fois dans https://www.example.com/.well-known/assetlinks.json et https://mobile.example.com/.well-known/assetlinks.json.
<application>
<activity android:name=”MainActivity”>
<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" />
<data android:scheme="https" />
<data android:host="www.example.com" />
<data android:host="mobile.example.com" />
</intent-filter>
</activity>
</application>
Si vous déclarez votre nom d'hôte avec un caractère générique (par exemple, *.example.com), vous devez publier votre fichier assetlinks.json sur le nom d'hôte racine (example.com). Par exemple, une application avec le filtre d'intent suivant réussira la validation de tout sous-nom de example.com (tel que foo.example.com) tant que le fichier assetlinks.json est publié à l'adresse https://example.com/.well-known/assetlinks.json:
<application>
<activity android:name=”MainActivity”>
<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" />
<data android:host="*.example.com" />
</intent-filter>
</activity>
</application>
Rechercher plusieurs applications associées au même domaine
Si vous publiez plusieurs applications associées chacune au même domaine, chacune peut être validée. Toutefois, si les applications peuvent résoudre exactement le même hôte et le même chemin d'accès de domaine, comme cela pourrait être le cas avec les versions allégées et complètes d'une application, seule l'application qui a été installée le plus récemment peut résoudre les intents Web pour ce domaine.
Dans un tel cas, recherchez d'éventuelles applications en conflit sur l'appareil de l'utilisateur, à condition que vous disposiez de la visibilité nécessaire sur les packages. Ensuite, dans votre application, affichez une boîte de dialogue de sélecteur personnalisé contenant les résultats de l'appel de queryIntentActivities().
L'utilisateur peut sélectionner son application préférée dans la liste des applications correspondantes qui s'affiche dans la boîte de dialogue.
Déclarer des associations de sites Web
Un fichier JSON Digital Asset Links doit être publié sur votre site Web pour indiquer les applications Android associées au site Web et vérifier les intents d'URL de l'application. Le fichier JSON utilise les champs suivants pour identifier les applications associées:
package_name: ID d'application déclaré dans le fichierbuild.gradlede l'application.sha256_cert_fingerprints: empreintes SHA256 du certificat de signature de votre application. Vous pouvez utiliser la commande suivante pour générer l'empreinte via le keytool Java :keytool -list -v -keystore my-release-key.keystore
Ce champ accepte plusieurs empreintes, qui peuvent être utilisées pour prendre en charge différentes versions de votre application, telles que des versions de débogage et de production.Si vous utilisez la signature d'application Play pour votre application, l'empreinte du certificat générée en exécutant
keytoollocalement ne correspond généralement pas à celle qui se trouve sur les appareils des utilisateurs. Vous pouvez vérifier si vous utilisez la signature d'application Play dans votre compte de développeur Play Console sousRelease > Setup > App signing. Dans ce cas, vous trouverez également sur la même page l'extrait JSON Digital Asset Links correspondant à votre application.
L'exemple de fichier assetlinks.json suivant accorde des droits d'ouverture de lien à une application Android com.example:
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.example",
"sha256_cert_fingerprints":
["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
}
}]
Associer un site Web à plusieurs applications
Un site Web peut déclarer des associations avec plusieurs applications dans le même fichier assetlinks.json. La liste de fichiers suivante présente un exemple de fichier d'instruction qui déclare l'association à deux applications séparément et se trouve à l'emplacement https://www.example.com/.well-known/assetlinks.json:
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.example.puppies.app",
"sha256_cert_fingerprints":
["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
}
},
{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.example.monkeys.app",
"sha256_cert_fingerprints":
["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
}
}]
Chaque application peut gérer les liens de différentes ressources sous le même hôte Web. Par exemple, app1 peut déclarer un filtre d'intent pour https://example.com/articles et app2 peut déclarer un filtre d'intent pour https://example.com/videos.
Remarque:Plusieurs applications associées à un domaine peuvent être signées avec le même certificat ou des certificats différents.
Associer plusieurs sites Web à une seule application
Plusieurs sites Web peuvent déclarer des associations avec la même application dans leurs fichiers assetlinks.json respectifs. Les listes de fichiers suivantes montrent comment déclarer l'association de example.com et d'example.net à app1. La première fiche présente l'association de example.com à app1:
https://www.example.com/.well-known/assetlinks.json
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.mycompany.app1",
"sha256_cert_fingerprints":
["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
}
}]
La fiche suivante montre l'association de example.net à app1. Seul l'emplacement où ces fichiers sont hébergés est différent (.com et .net):
https://www.example.net/.well-known/assetlinks.json
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.mycompany.app1",
"sha256_cert_fingerprints":
["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
}
}]
Publier le fichier de validation JSON
Vous devez publier votre fichier de validation JSON à l'emplacement suivant:
https://domain.name/.well-known/assetlinks.json
Assurez-vous de ce qui suit:
- Le fichier
assetlinks.jsonest diffusé avec le type de contenuapplication/json. - Le fichier
assetlinks.jsondoit être accessible via une connexion HTTPS, que les filtres d'intent de votre application déclarent ou non HTTPS comme schéma de données. - Le fichier
assetlinks.jsondoit être accessible sans aucune redirection (pas de redirections 301 ou 302). - Si les liens vers votre application sont compatibles avec plusieurs domaines hôtes, vous devez publier le fichier
assetlinks.jsonsur chaque domaine. Consultez la section Prendre en charge l'association d'applications pour plusieurs hôtes. - Ne publiez pas votre application avec des URL de développement/test dans le fichier manifeste qui risquent de ne pas être accessibles au public (par exemple, celles accessibles uniquement avec un VPN). Dans ce cas, une solution consiste à configurer les variantes de compilation afin de générer un fichier manifeste différent pour les builds de développement.
Validation Android App Links
Lorsque android:autoVerify="true" est présent dans au moins l'un des filtres d'intent de votre application, si vous installez votre application sur un appareil exécutant Android 6.0 (niveau d'API 23) ou une version ultérieure, le système valide automatiquement les hôtes associés aux URL dans les filtres d'intent de votre application. Sur Android 12 et versions ultérieures, vous pouvez également appeler le processus de validation manuellement pour tester la logique de validation.
Validation automatique
La vérification automatique du système implique les opérations suivantes:
- Le système inspecte tous les filtres d'intent qui incluent l'un des éléments suivants :
- Action :
android.intent.action.VIEW - Catégories:
android.intent.category.BROWSABLEetandroid.intent.category.DEFAULT - Schéma de données:
httpouhttps
- Action :
- Pour chaque nom d'hôte unique trouvé dans les filtres d'intent ci-dessus, Android interroge les sites Web correspondants au fichier Digital Asset Links sur
https://hostname/.well-known/assetlinks.json.
Après avoir confirmé la liste des sites Web à associer à votre application et vérifié que le fichier JSON hébergé est valide, installez l'application sur votre appareil. Attendez au moins 20 secondes que le processus de validation asynchrone se termine. Utilisez la commande suivante pour vérifier si le système a validé votre application et défini les règles de gestion des liens appropriées:
adb shell am start -a android.intent.action.VIEW \
-c android.intent.category.BROWSABLE \
-d "http://domain.name:optional_port"
Vérification manuelle
À partir d'Android 12, vous pouvez appeler manuellement la validation du domaine pour une application installée sur un appareil. Vous pouvez effectuer ce processus, que votre application cible Android 12 ou non.
Établir une connexion Internet
Pour que vous puissiez effectuer la validation du domaine, votre appareil de test doit être connecté à Internet.
Assurer la compatibilité avec la nouvelle procédure de validation du domaine
Si votre application cible Android 12 ou une version ultérieure, le système utilise automatiquement le processus de validation du domaine mis à jour.
Sinon, vous pouvez activer manuellement la nouvelle procédure de validation. Pour ce faire, exécutez la commande suivante dans une fenêtre de terminal:
adb shell am compat enable 175408749 PACKAGE_NAME
Réinitialiser l'état d'Android App Links sur un appareil
Avant d'appeler manuellement la validation du domaine sur un appareil, vous devez réinitialiser l'état d'Android App Links sur l'appareil de test. Pour ce faire, exécutez la commande suivante dans une fenêtre de terminal:
adb shell pm set-app-links --package PACKAGE_NAME 0 all
Cette commande place l'appareil dans l'état dans lequel il se trouve avant que l'utilisateur ne sélectionne les applications par défaut pour tous les domaines.
Appeler la procédure de validation du domaine
Après avoir réinitialisé l'état d'Android App Links sur un appareil, vous pouvez effectuer la vérification elle-même. Pour ce faire, exécutez la commande suivante dans une fenêtre de terminal :
adb shell pm verify-app-links --re-verify PACKAGE_NAME
Examiner les résultats de la validation
Après avoir laissé à l'agent de validation le temps de terminer ses requêtes, examinez les résultats de la vérification. Pour ce faire, exécutez la commande suivante:
adb shell pm get-app-links PACKAGE_NAME
Le résultat de cette commande ressemble à ce qui suit:
com.example.pkg:
ID: 01234567-89ab-cdef-0123-456789abcdef
Signatures: [***]
Domain verification state:
example.com: verified
sub.example.com: legacy_failure
example.net: verified
example.org: 1026
Les domaines dont la validation a réussi présentent l'état de validation verified. Tout autre état indique que la validation du domaine n'a pas pu être effectuée. En particulier, l'état none indique que l'agent de validation n'a peut-être pas encore terminé le processus de validation.
La liste suivante indique les valeurs de retour possibles que la validation du domaine peut renvoyer pour un domaine donné:
none- Aucun enregistrement n'a été effectué pour ce domaine. Attendez quelques minutes de plus que l'agent de validation termine les requêtes liées à la validation du domaine, puis appelez à nouveau le processus de validation du domaine.
verified- Le domaine de l'application à l'origine de la déclaration a bien été validé.
approved- Le domaine a été approuvé d'office, généralement via l'exécution d'une commande shell.
denied- Le domaine a été refusé de force, généralement en exécutant une commande shell.
migrated- Le système a conservé le résultat d'un processus précédent utilisant la validation de l'ancien domaine.
restored- Le domaine a été approuvé après la restauration des données de l'utilisateur. Nous partons du principe que le domaine a déjà été validé.
legacy_failure- Le domaine a été refusé par un ancien vérificateur. Le motif spécifique de l'échec est inconnu.
system_configured- Le domaine a été approuvé automatiquement par la configuration de l'appareil.
- Code d'erreur
1024ou supérieur Code d'erreur personnalisé spécifique au vérificateur de l'appareil.
Vérifiez que vous avez établi une connexion réseau et appelez à nouveau le processus de validation du domaine.
Demander à l'utilisateur d'associer votre application à un domaine
Une autre façon d'approuver votre application pour un domaine consiste à demander à l'utilisateur d'associer votre application à ce domaine.
Vérifier si votre application est déjà approuvée pour le domaine
Avant d'envoyer une invite à l'utilisateur, vérifiez si votre application est le gestionnaire par défaut pour les domaines que vous définissez dans vos éléments <intent-filter>. Vous pouvez interroger l'état d'approbation à l'aide de l'une des méthodes suivantes:
- L'API
DomainVerificationManager(au moment de l'exécution) - Un programme de ligne de commande (lors des tests)
Gestionnaire de validation du domaine
L'extrait de code suivant montre comment utiliser l'API DomainVerificationManager:
Kotlin
val context: Context = TODO("Your activity or fragment's Context")
val manager = context.getSystemService(DomainVerificationManager::class.java)
val userState = manager.getDomainVerificationUserState(context.packageName)
// Domains that have passed Android App Links verification.
val verifiedDomains = userState?.hostToStateMap
?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_VERIFIED }
// Domains that haven't passed Android App Links verification but that the user
// has associated with an app.
val selectedDomains = userState?.hostToStateMap
?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_SELECTED }
// All other domains.
val unapprovedDomains = userState?.hostToStateMap
?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_NONE }
Java
Context context = TODO("Your activity or fragment's Context");
DomainVerificationManager manager =
context.getSystemService(DomainVerificationManager.class);
DomainVerificationUserState userState =
manager.getDomainVerificationUserState(context.getPackageName());
Map<String, Integer> hostToStateMap = userState.getHostToStateMap();
List<String> verifiedDomains = new ArrayList<>();
List<String> selectedDomains = new ArrayList<>();
List<String> unapprovedDomains = new ArrayList<>();
for (String key : hostToStateMap.keySet()) {
Integer stateValue = hostToStateMap.get(key);
if (stateValue == DomainVerificationUserState.DOMAIN_STATE_VERIFIED) {
// Domain has passed Android App Links verification.
verifiedDomains.add(key);
} else if (stateValue == DomainVerificationUserState.DOMAIN_STATE_SELECTED) {
// Domain hasn't passed Android App Links verification, but the user has
// associated it with an app.
selectedDomains.add(key);
} else {
// All other domains.
unapprovedDomains.add(key);
}
}
Programme de ligne de commande
Lorsque vous testez votre application pendant le développement, vous pouvez exécuter la commande suivante pour interroger l'état de validation des domaines appartenant à votre organisation:
adb shell pm get-app-links --user cur PACKAGE_NAME
Dans l'exemple de résultat suivant, même si la validation de l'application a échoué pour le domaine "example.org", l'utilisateur 0 a approuvé manuellement l'application dans les paramètres système, et aucun autre package n'est validé pour ce domaine.
com.example.pkg:
ID: ***
Signatures: [***]
Domain verification state:
example.com: verified
example.net: verified
example.org: 1026
User 0:
Verification link handling allowed: true
Selection state:
Enabled:
example.org
Disabled:
example.com
example.net
Vous pouvez également utiliser des commandes shell pour simuler le processus où l'utilisateur sélectionne l'application associée à un domaine donné. Une explication complète de ces commandes est disponible dans la sortie de adb shell pm.
Fournir le contexte de la demande
Avant d'envoyer cette demande d'approbation de domaine, fournissez des informations contextuelles à l'utilisateur. Par exemple, vous pouvez leur montrer un écran de démarrage, une boîte de dialogue ou un élément d'interface utilisateur similaire qui explique à l'utilisateur pourquoi votre application doit être le gestionnaire par défaut pour un domaine particulier.
Envoyer la demande
Une fois que l'utilisateur a compris ce que votre application lui demande de faire, faites la demande.
Pour ce faire, appelez un intent qui inclut l'action d'intent ACTION_APP_OPEN_BY_DEFAULT_SETTINGS et une chaîne de données correspondant à package:com.example.pkg pour l'application cible, comme indiqué dans l'extrait de code suivant:
Kotlin
val context: Context = TODO("Your activity or fragment's Context")
val intent = Intent(Settings.ACTION_APP_OPEN_BY_DEFAULT_SETTINGS,
Uri.parse("package:${context.packageName}"))
context.startActivity(intent)
Java
Context context = TODO("Your activity or fragment's Context");
Intent intent = new Intent(Settings.ACTION_APP_OPEN_BY_DEFAULT_SETTINGS,
Uri.parse("package:" + context.getPackageName()));
context.startActivity(intent);
Lorsque l'intent est appelé, les utilisateurs voient un écran de paramètres appelé Open by default (Ouvrir par défaut). Cet écran contient une case d'option appelée Open supported links (Ouvrir les liens compatibles), comme illustré dans la figure 1.
Lorsque l'utilisateur active l'option Ouvrir les liens compatibles, un ensemble de cases à cocher s'affiche dans la section Liens à ouvrir dans cette application. À partir de là, les utilisateurs peuvent sélectionner les domaines qu'ils souhaitent associer à votre application. Ils peuvent également sélectionner Ajouter un lien pour ajouter des domaines, comme illustré dans la figure 2. Lorsque les utilisateurs sélectionnent ultérieurement un lien dans les domaines qu'ils ajoutent, le lien s'ouvre automatiquement dans votre application.
Ouvrir dans votre application des domaines que celle-ci ne peut pas valider
La fonction principale de votre application peut être d'ouvrir des liens en tant que tiers, sans pouvoir valider les domaines gérés. Dans ce cas, expliquez aux utilisateurs qu'à ce moment-là, lorsqu'ils sélectionnent un lien Web, ils ne peuvent pas choisir entre une application propriétaire et votre application (tierce). Les utilisateurs doivent associer manuellement les domaines à votre application tierce.
En outre, envisagez d'introduire une activité de boîte de dialogue ou de trampoline permettant à l'utilisateur d'ouvrir le lien dans l'application propriétaire s'il préfère le faire, en agissant comme un proxy. Avant de configurer une activité de boîte de dialogue ou de trampoline, configurez votre application de sorte qu'elle dispose de la visibilité du package sur les applications propriétaires qui correspondent au filtre d'intent Web de votre application.
Tester les liens vers l'application
Lorsque vous implémentez la fonctionnalité d'association d'applications, vous devez la tester pour vous assurer que le système peut associer votre application à vos sites Web et gérer les requêtes d'URL comme prévu.
Pour tester un fichier d'instructions existant, vous pouvez utiliser le générateur et le testeur de listes d'instructions.
Confirmer la liste des hôtes à vérifier
Lors des tests, vous devez confirmer la liste des hôtes associés que le système doit valider pour votre application. Dressez la liste de toutes les URL dont les filtres d'intent correspondants incluent les attributs et éléments suivants:
- Attribut
android:schemeavec la valeurhttpouhttps - Attribut
android:hostavec un format d'URL de domaine - Élément d'action
android.intent.action.VIEW - Élément de catégorie
android.intent.category.BROWSABLE
Cette liste vous permet de vérifier qu'un fichier JSON Digital Asset Links est fourni pour chaque hôte et sous-domaine nommé.
Confirmer les fichiers Digital Asset Links
Pour chaque site Web, utilisez l'API Digital Asset Links pour vérifier que le fichier JSON Digital Asset Links est correctement hébergé et défini:
https://digitalassetlinks.googleapis.com/v1/statements:list? source.web.site=https://domain.name:optional_port& relation=delegate_permission/common.handle_all_urls
Consulter les règles en matière de liens
Dans le cadre de votre processus de test, vous pouvez vérifier les paramètres système actuels pour la gestion des liens. Utilisez la commande suivante pour obtenir la liste des règles de gestion des associations existantes pour toutes les applications de votre appareil connecté:
adb shell dumpsys package domain-preferred-apps
Ou la commande suivante produit la même chose:
adb shell dumpsys package d
Remarque:Veillez à attendre au moins 20 secondes après l'installation de votre application pour que le système puisse terminer le processus de validation.
La commande renvoie une liste de chaque utilisateur ou profil défini sur l'appareil, précédé d'un en-tête au format suivant:
App linkages for user 0:
Après cet en-tête, la sortie utilise le format suivant pour répertorier les paramètres de gestion des liens pour cet utilisateur:
Package: com.android.vending Domains: play.google.com market.android.com Status: always : 200000002
Cette fiche indique quelles applications sont associées à quels domaines pour cet utilisateur:
Package: identifie une application grâce à son nom de package, tel qu'indiqué dans son fichier manifeste.Domains: affiche la liste complète des hôtes dont cette application gère les liens Web, en utilisant des espaces vides comme délimiteurs.Status: affiche le paramètre actuel de gestion des associations pour cette application. Une application qui a été validée et dont le fichier manifeste contientandroid:autoVerify="true"affiche l'étatalways. Le nombre hexadécimal après cet état est lié à l'enregistrement par le système Android des préférences d'association d'applications de l'utilisateur. Cette valeur n'indique pas si la validation a réussi.
Remarque:Si un utilisateur modifie les paramètres de lien d'application pour une application avant la fin de la validation, vous verrez peut-être un faux positif si la validation aboutit, même si la validation a échoué. Toutefois, cet échec de validation n'a pas d'importance si l'utilisateur a explicitement autorisé l'application à ouvrir des liens compatibles sans demander d'autorisation. En effet, les préférences utilisateur prévalent sur la validation programmatique (ou l'absence de validation). Par conséquent, le lien redirige directement vers votre application, sans afficher de boîte de dialogue, comme si la validation avait réussi.
Exemple de test
Pour que la validation des liens vers une application aboutisse, le système doit être en mesure de valider votre application auprès de chacun des sites Web que vous spécifiez dans un filtre d'intent donné et répondant aux critères concernant les liens d'application. L'exemple suivant présente une configuration de fichier manifeste dans laquelle plusieurs liens d'application sont définis:
<application>
<activity android:name=”MainActivity”>
<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" />
<data android:scheme="https" />
<data android:host="www.example.com" />
<data android:host="mobile.example.com" />
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="https" />
<data android:host="www.example2.com" />
</intent-filter>
</activity>
<activity android:name=”SecondActivity”>
<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="https" />
<data android:host="account.example.com" />
</intent-filter>
</activity>
<activity android:name=”ThirdActivity”>
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.DEFAULT" />
<data android:scheme="https" />
<data android:host="map.example.com" />
</intent-filter>
<intent-filter>
<action android:name="android.intent.action.VIEW" />
<category android:name="android.intent.category.BROWSABLE" />
<data android:scheme="market" />
<data android:host="example.com" />
</intent-filter>
</activity>
</application>
Voici la liste des hôtes que la plate-forme tentera de vérifier à partir du fichier manifeste ci-dessus:
www.example.com mobile.example.com www.example2.com account.example.com
Voici la liste des hôtes que la plate-forme ne tenterait pas de vérifier à partir du fichier manifeste ci-dessus:
map.example.com (it does not have android.intent.category.BROWSABLE) market://example.com (it does not have either an "http" or "https" scheme)
Pour en savoir plus sur les listes d'instructions, consultez la section Créer une liste d'instructions.
Corriger les erreurs d'implémentation courantes
Si vous ne parvenez pas à valider vos liens Android App Links, recherchez les erreurs courantes suivantes. Cette section utilise example.com comme nom de domaine d'espace réservé. Lorsque vous effectuez ces vérifications, remplacez example.com par le nom de domaine réel de votre serveur.
- Configuration du filtre d'intent incorrecte
- Vérifiez si vous incluez dans un élément
<intent-filter>une URL dont votre application n'est pas propriétaire. - Configuration du serveur incorrecte
Vérifiez la configuration JSON de votre serveur et assurez-vous que la valeur SHA est correcte.
Vérifiez également que
example.com.(avec le point final) diffuse le même contenu queexample.com.- Redirections côté serveur
Le système ne vérifie aucun Android App Links pour votre application si vous configurez une redirection telle que celle-ci:
- De
http://example.comàhttps://example.com - De
example.comàwww.example.com
Ce comportement protège la sécurité de votre application.
- De
- Robustesse du serveur
Vérifiez si votre serveur peut se connecter à vos applications clientes.
- Liens non vérifiables
À des fins de test, vous pouvez ajouter intentionnellement des liens non vérifiables. Gardez à l'esprit que, sur Android 11 ou version antérieure, ces liens empêchent le système de valider tous les liens Android App Links pour votre application.
- Signature incorrecte dans assetlinks.json
Vérifiez que votre signature est correcte et qu'elle correspond à celle utilisée pour signer votre application. Les erreurs courantes incluent:
- Il doit signer l'application avec un certificat de débogage et ne disposer que de la signature de version dans
assetlinks.json. - Avoir une signature en minuscules dans
assetlinks.json. La signature doit être en majuscules. - Si vous utilisez la signature d'application Play, assurez-vous d'utiliser la signature que Google utilise pour signer chacune de vos versions. Vous pouvez vérifier ces informations, y compris un extrait de code JSON complet, en suivant les instructions pour déclarer des associations de sites Web.
- Il doit signer l'application avec un certificat de débogage et ne disposer que de la signature de version dans