Un Android App Links est un type spécial de lien profond qui permet aux URL de votre site Web pour ouvrir immédiatement le contenu correspondant dans votre application Android, sans demander à l'utilisateur de sélectionner l'application. Android App Links utilise l'élément numérique API Links pour établir une relation de confiance que votre application a été approuvée par le site Web à ouvrir automatiquement des liens pour sur ce domaine. Si le système confirme que vous êtes bien le propriétaire des URL, le achemine automatiquement ces intents d'URL vers votre application.
Pour confirmer que vous êtes bien le propriétaire des URL de votre application et de votre site Web, remplissez la en suivant les étapes ci-dessous:
Ajoutez des filtres d'intent qui contiennent les
autoVerify
. . Cet attribut indique au système qu'il doit vérifier 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:
- Prise en charge des URL et de 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
Afin d'activer la validation de la gestion des liens pour votre appli, 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 un seul <intent-filter>
pour chaque hôte, même s'il est utilisé avec d'autres
, nous vous recommandons d'ajouter autoVerify
à chaque
<intent-filter>
pour plus de cohérence. Cela garantit également qu'après votre
supprimez ou refactorisez des éléments de votre fichier manifeste, votre application reste associée
avec tous les domaines que vous définissez.
Le processus de validation du domaine nécessite une connexion Internet et peut prendre
un certain temps pour terminer. Pour améliorer l'efficacité du processus, le système
valide un domaine pour une application qui cible Android 12 ou version ultérieure ;
que si ce domaine se trouve à l'intérieur d'un élément <intent-filter>
contenant le
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 être en mesure de valider l'hôte spécifié dans les données des filtres d'intent d'URL de l'application avec les fichiers Digital Asset Links qui sont hébergés sur leurs domaines Web respectifs, filtre d'intent intégré. Si la validation échoue, le système adopte le comportement standard par défaut. pour résoudre l'intent, comme décrit dans Créez des liens profonds vers le contenu de l'application. Toutefois, l'application peut toujours être validée en tant que gestionnaire par défaut pour tout format d'URL défini 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 type fichier Digital Asset Links pour tous les hôtes que vous définissez dans le d'un fichier manifeste.
Par exemple, une application avec l'intent suivant :
les filtres seraient validés uniquement pour https://www.example.com
si un fichier assetlinks.json
a été trouvé à l'adresse
https://www.example.com/.well-known/assetlinks.json
, mais pas
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>
dans le 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
. Toutefois, il est combiné à l'autre élément <data>
afin que le filtre d'intent prenne en charge à 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 uniques,
des hôtes distincts. Si votre intention
répertorie plusieurs hôtes avec des sous-domaines différents, vous devez publier un fichier
assetlinks.json
sur chaque domaine. Par exemple,
le filtre d'intent suivant inclut www.example.com
et
mobile.example.com
en tant qu'hôtes d'URL d'intent acceptés. Ainsi, une
assetlinks.json
doit être publié aux deux
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 (comme *.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 transmet
de validation pour tout sous-nom de example.com
(tel que foo.example.com
) comme
tant que le fichier assetlinks.json
est publié
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, peuvent tous être validés. Toutefois, si les applications peuvent résoudre le problème le même hôte et le même chemin d'accès, comme cela pourrait être le cas avec les versions allégées et complètes de une application, seule celle qui a été installée le plus récemment peut résoudre les intents Web pour ce domaine.
Dans un cas comme celui-ci, recherchez d'éventuelles
applications en conflit sur l'appareil de l'utilisateur,
à condition que vous disposiez des packages nécessaires
visibilité. Ensuite, dans votre application, affichez une
boîte de dialogue de sélection contenant les résultats des appels
queryIntentActivities()
L'utilisateur peut sélectionner l'application de son choix dans la liste des applications correspondantes qui s'affichent dans la boîte de dialogue.
Déclarer des associations de sites Web
Un asset numérique Liens : le fichier JSON doit être publié sur votre site Web pour indiquer les applications Android. associés 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 de l'application déclaré dans le fichierbuild.gradle
de 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 Java keytool: Ce champ accepte plusieurs empreintes digitales, qui peuvent être utilisées les différentes versions de votre application, comme les versions de débogage et de production.keytool -list -v -keystore my-release-key.keystore
Si vous utilisez la signature d'application Play pour votre application, le certificat l'empreinte numérique produite en exécutant
keytool
localement est généralement ne correspond pas à celle de l'utilisateur appareils. Vous pouvez vérifier si vous utilisez Signature d'application Play pour votre application dans votre compte de développeur Play Console sousRelease > Setup > App signing
; si vous le faites, alors vous recherchez l'extrait JSON Digital Asset Links correspondant à votre application sur le .
L'exemple de fichier assetlinks.json
suivant accorde des droits d'ouverture de lien à un
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 assetlinks.json
. La liste de fichiers suivante montre un exemple de fichier d'instruction qui déclare une association
avec deux applications, séparément,
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"] } }]
Différentes applications peuvent gérer des liens pour différentes ressources sur 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 nom différents certificats.
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
montrez un exemple de déclaration de l'association de example.com et
example.net avec app1. La première liste montre l'association de example.com à app1 :
[{ "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. Seuls les
l'emplacement où ces fichiers sont hébergés est différent (.com
et .net
):
[{ "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.json
est diffusé avec la valeur content-typeapplication/json
- Le fichier
assetlinks.json
doit ê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.json
doit être accessible sans aucune redirection les redirections 301 ou 302). - Si les liens vers votre application sont compatibles avec plusieurs domaines hôtes, vous devez publier le
assetlinks.json
sur chaque domaine. Voir Prise en charge de l'association d'applications pour plusieurs hôtes. - Ne publiez pas votre application avec des URL de développement/test dans le fichier manifeste être accessibles au public (par exemple, tous ceux qui ne sont accessibles qu'avec un VPN) ; A une solution alternative consiste à configurer des variantes 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 un intent de votre appli
en installant votre application sur un appareil équipé d'Android 6.0 (niveau d'API 23).
le système vérifie automatiquement les hôtes associés au
URL dans les filtres d'intent de votre application. Sur Android 12 ou version ultérieure,
pouvez également appeler la procédure de validation manuellement pour
et 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.BROWSABLE
etandroid.intent.category.DEFAULT
- Schéma de données:
http
ouhttps
- Action :
- Pour chaque nom d'hôte unique trouvé dans les filtres d'intent ci-dessus, les requêtes Android
les sites Web correspondants du fichier Digital Asset Links sur
https://hostname/.well-known/assetlinks.json
Après avoir confirmé la liste des sites Web à associer à votre application après avoir vérifié que le fichier JSON hébergé est valide, installez l'application sur votre appareil. Patientez au moins 20 secondes, le temps que le processus de validation asynchrone se termine. terminé. Utilisez la commande suivante pour vérifier si le système a validé votre application et définissez 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 un domaine pour une application installée sur un appareil. Vous pouvez effectuer cette procédure, que votre application cible Android 12 ou non.
Établir une connexion Internet
Pour 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 le la procédure de validation du domaine a été mise à jour automatiquement.
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 le 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 choisit 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 les 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 terminer ses requêtes, examinez les résultats de la validation. 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 validés sont associés à un état de validation.
sur verified
. Tout autre état indique que la validation du domaine n'a pas pu être effectuée. Plus spécifiquement, l'état none
indique que la vérification
l'agent n'a peut-être pas encore terminé la procédure de validation.
La liste suivante indique les valeurs de retour possibles pour la validation du domaine pour un domaine donné:
none
- Aucun enregistrement n'a été effectué pour ce domaine. Patientez encore quelques minutes, le temps que un agent de validation chargé de finaliser les demandes liées à la validation du domaine, puis à nouveau la procédure 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 qui utilisait l'ancienne vérification de domaine.
restored
- Le domaine a été approuvé après la restauration des données de l'utilisateur. Il est supposé que le domaine a déjà été validé.
legacy_failure
- Le domaine a été refusé par un ancien vérificateur. La raison spécifique de l'échec est inconnus.
system_configured
- Le domaine a été approuvé automatiquement par la configuration de l'appareil.
- Code d'erreur
1024
ou supérieur Code d'erreur personnalisé spécifique au vérificateur de l'appareil.
Vérifiez que vous avez établi un réseau connexion et appeler le domaine procédure de validation.
Demander à l'utilisateur d'associer votre application à un domaine
Une autre façon d'obtenir l'approbation d'un domaine consiste à demander à l'utilisateur 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 de
les domaines que vous définissez dans vos éléments <intent-filter>
. Vous pouvez interroger
l'état d'approbation en utilisant l'une des méthodes suivantes:
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 la classe
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 vérification de l'application a échoué pour "example.org" domaine, 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é. Vous trouverez une explication complète de ces commandes dans la sortie de adb shell pm
.
Fournir le contexte de la demande
Avant de demander l'approbation du domaine, fournissez un contexte à 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 expliquant à 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'objet
ACTION_APP_OPEN_BY_DEFAULT_SETTINGS
une action d'intent et une mise en correspondance de chaîne de données
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é Ouvrir par par défaut. Cet écran contient une case d'option intitulée Open supported links (Ouvrir les liens compatibles). comme illustré dans la figure 1.
Lorsque l'utilisateur active l'option Ouvrir les liens compatibles, plusieurs cases s'affichent. dans une section intitulée Liens à ouvrir dans cette application. De là, les utilisateurs peuvent sélectionner les domaines qu'ils souhaitent associer à votre application. Ils peuvent également sélectionnez Add link (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 le la possibilité de valider les domaines gérés. Si tel est le cas, expliquez aux utilisateurs qu'à ce moment-là, lorsqu'ils sélectionnent un lien Web, ils ne peuvent pas choisir votre application propriétaire et votre application (tierce). Les utilisateurs doivent associer manuellement avec votre application tierce.
En outre, envisagez de lancer une activité de dialogue ou de trampoline qui permet l'utilisateur à ouvrir le lien dans l'application propriétaire s'il préfère le faire, en tant que proxy. Avant de configurer ce type d'activité de boîte de dialogue ou de trampoline, configurer l'application de sorte qu'elle dispose de la visibilité du package ; dans les applications propriétaires qui correspondent au filtre d'intent Web de votre application.
Tester les liens vers une application
Lorsque vous implémentez la fonctionnalité d'association d'applications, testez-la 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'état existant, vous pouvez utiliser l'outil Générateur et testeur de liste d'états.
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 vérifier pour votre application. Dressez la liste de toutes les URL dont les filtres d'intent correspondants incluent les éléments suivants : attributs et éléments:
- Attribut
android:scheme
avec la valeurhttp
ouhttps
- Attribut
android:host
avec un format d'URL de domaine - Élément d'action
android.intent.action.VIEW
- Élément de catégorie
android.intent.category.BROWSABLE
Utilisez cette liste pour vérifier qu'un fichier JSON Digital Asset Links est fourni sur chaque hôte nommé et le sous-domaine.
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
Vérifier les règles concernant les 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 liens existantes pour toutes applications sur 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 afin que le système puisse terminer la procédure de vérification.
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, à l'aide de des espaces vides comme délimiteurs.Status
: affiche le paramètre actuel de gestion des associations pour cette application. Une application qui a a été validé, et dont le fichier manifeste contientandroid:autoVerify="true"
, affiche un état suralways
. Le nombre hexadécimal qui suit cet état est lié à l'enregistrement des préférences de l'utilisateur concernant l'association d'applications dans le système Android. Cette valeur n'indique pas si la validation a réussi.
Remarque:Si un utilisateur modifie les paramètres d'association d'applications pour une application avant la validation est terminée, il est possible qu'un faux positif s'affiche si la validation est réussie, même si la vérification a échoué. Toutefois, cet échec de validation n'a pas d'importance si l'utilisateur explicitement activé l'application à ouvrir les 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 été effectuée réussi.
Exemple de test
Pour que la validation des liens vers une application aboutisse, le système doit pouvoir valider votre application avec chacune des les sites Web que vous spécifiez dans un filtre d'intent donné qui répondent aux critères de l'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 de déclarations, consultez Créer une liste d'instructions
Corriger les erreurs d'implémentation courantes
Si vous ne parvenez pas à valider vos liens Android App Links, vérifiez les points communs suivants
les erreurs. Cette section utilise example.com
comme nom de domaine réservé. Quand
ces vérifications, remplacez example.com
par la valeur réelle de votre serveur
nom de domaine.
- Configuration du filtre d'intent incorrecte
- Vérifiez si vous incluez une URL dont votre application n'est pas propriétaire dans une
<intent-filter>
. - Configuration incorrecte du serveur
Vérifiez la configuration JSON de votre serveur et assurez-vous que la valeur SHA est Correct.
Vérifiez également que
example.com.
(avec le point final) diffuse les mêmes contenu en tant 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 la suivante :
- 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. Conserver n'oubliez pas que sur Android 11 ou version antérieure, ces liens entraînent système de validation de ne pas 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 la signature. votre application. Voici quelques erreurs courantes:
- Signer l'application avec un certificat de débogage et ne disposer que de la version
signature dans
assetlinks.json
. - Avoir une signature en minuscules dans
assetlinks.json
. La signature doit en majuscules. - Si vous utilisez la signature d'application Play, assurez-vous d'utiliser la signature que Google utilise pour signer chacune de vos sorties. Vous pouvez vérifier ces détails, y compris un extrait de code JSON complet, en suivant les instructions déclarer des associations de sites Web.
- Signer l'application avec un certificat de débogage et ne disposer que de la version
signature dans