Un Android App Link 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. Les Android App Links utilisent l'API Digital Asset Links pour établir la confiance 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 le propriétaire des URL, il redirige automatiquement ces intents d'URL vers votre application.
Pour vérifier que vous êtes le propriétaire de votre application et des URL de votre 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:
- Prise en charge des URL et de l'indexation des applications dans Android Studio
- Créer une liste de relevés
Ajouter des filtres d'intent pour la validation des liens d'application
Pour activer la vérification 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". -->
<!-- Do not include other schemes. -->
<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 suffise 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> pour plus de cohérence. Cela garantit également que, après avoir supprimé ou refactorisé des éléments dans votre fichier manifeste, votre application reste associée à tous les domaines que vous définissez toujours.
La procédure 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 vérifie 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.
Par exemple, les schémas autres que "http" et "https", tels que <data android:scheme="custom" />, empêchent un <intent-filter> de déclencher la validation du domaine.
Prise en charge de 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 dans ce filtre d'intent. Si la validation échoue, le système utilise 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 de l'application. Toutefois, l'application peut toujours être validée en tant que gestionnaire par défaut pour l'un des modèles d'URL définis dans les autres filtres d'intent de l'application.
Remarque:Sous Android 11 (niveau d'API 30) ou version antérieure, le système ne vérifie 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 passerait la validation que pour https://www.example.com si un fichier assetlinks.json était trouvé 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> d'un 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 combiné à l'autre élément <data> afin que le filtre d'intent soit compatible avec 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.
Prise en charge de l'association d'applications pour plusieurs sous-domaines
Le protocole Digital Assets 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 liste 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. Par conséquent, un assetlinks.json valide doit ê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 au niveau du nom d'hôte racine (example.com). Par exemple, une application avec le filtre d'intent suivant passera la validation pour tout sous-nom de example.com (par exemple, foo.example.com) tant que le fichier assetlinks.json est publié à l'emplacement 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, elles peuvent toutes être validées. Toutefois, si les applications peuvent résoudre exactement le même hôte et le même chemin de domaine, comme cela peut être le cas avec les versions allégée et complète d'une application, seule l'application installée le plus récemment peut résoudre les intents Web pour ce domaine.
Dans ce cas, recherchez d'éventuelles applications en conflit sur l'appareil de l'utilisateur, à condition que vous disposiez de la visibilité du package nécessaire. Ensuite, dans votre application, affichez une boîte de dialogue de sélecteur personnalisée contenant les résultats de l'appel de 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 fichier JSON Digital Asset Links doit être publié sur votre site Web pour indiquer les applications Android associées au site Web et valider 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.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
Si vous utilisez la signature d'applications Play pour votre application, l'empreinte de 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 pour votre application dans votre compte de développeur Play Console sousRelease > Setup > App signing. Si c'est le cas, vous trouverez également l'extrait JSON Digital Asset Links qui correspond à votre application sur la même page.
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 montre un exemple de fichier d'instructions 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"] } }]
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 les mêmes ou 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 montrent comment déclarer l'association de example.com et example.net avec app1. La première liste montre 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 liste 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 que:
- 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 HTTPS comme schéma de données ou non. - Le fichier
assetlinks.jsondoit être accessible sans aucune redirection (pas de redirections 301 ou 302). - Si vos liens d'application sont compatibles avec plusieurs domaines d'hôte, vous devez publier le fichier
assetlinks.jsonsur chaque domaine. Consultez la section Assurer la liaison d'applications pour plusieurs hôtes. - Ne publiez pas votre application avec des URL de développement/test dans le fichier manifeste qui ne sont pas accessibles au public (par exemple, celles qui ne sont accessibles qu'avec un VPN). Dans ce cas, vous pouvez configurer des variantes de compilation pour générer un fichier manifeste différent pour les builds de développement.
Validation des liens vers une application Android
Lorsque android:autoVerify="true" est présent dans au moins l'un des filtres d'intent de votre application, l'installation de votre application sur un appareil exécutant Android 6.0 (niveau d'API 23) ou version ultérieure entraîne la vérification automatique des hôtes associés aux URL dans les filtres d'intent de votre application. Sous Android 12 et versions ultérieures, vous pouvez également appeler manuellement la procédure de validation pour tester la logique de validation.
Validation automatique
La validation automatique du système implique les éléments suivants:
- 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 pour le fichier Digital Asset Links à l'emplacement
https://hostname/.well-known/assetlinks.json.
Une fois que vous avez confirmé la liste des sites Web à associer à votre application et que vous avez 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 de 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.
Prendre en charge le nouveau processus de validation de domaine
Si votre application cible Android 12 ou version ultérieure, le système utilise automatiquement le processus de validation de 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 des liens d'application Android sur un appareil
Avant d'appeler manuellement la validation de domaine sur un appareil, vous devez réinitialiser l'état des liens d'application Android 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 le même état qu'avant que l'utilisateur ne choisisse les applications par défaut pour les domaines.
Appeler la procédure de validation du domaine
Une fois que vous avez réinitialisé l'état des liens d'application Android sur un appareil, vous pouvez effectuer la vérification vous-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
La sortie de cette commande ressemble à ceci:
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 qui réussissent la validation ont un état de validation de domaine de verified. Tout autre état indique que la validation du domaine n'a pas pu être effectuée. Plus précisément, un état none indique que l'agent de validation n'a peut-être pas encore terminé le processus de validation.
La liste suivante répertorie les valeurs de retour possibles que la validation de domaine peut renvoyer pour un domaine donné:
none- Rien n'a été enregistré pour ce domaine. Attendez encore quelques minutes pour 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 a bien été validé pour l'application déclarante.
approved- Le domaine a été approuvé de force, généralement en exécutant 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 que l'utilisateur a effectué une restauration de données. On suppose que le domaine a déjà été validé.
legacy_failure- Le domaine a été refusé par un ancien outil de validation. La raison spécifique de l'échec est inconnue.
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, puis lancez à nouveau la procédure de validation du domaine.
Demander à l'utilisateur d'associer votre application à un domaine
Pour que votre application soit approuvée pour un domaine, vous pouvez également demander à l'utilisateur de l'associer à ce domaine.
Vérifier si votre application est déjà approuvée pour le domaine
Avant d'inviter l'utilisateur, vérifiez si votre application est le gestionnaire par défaut des 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).
DomainVerificationManager
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 sortie 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 dans lequel 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 lui présenter un écran de démarrage, une boîte de dialogue ou un élément d'interface utilisateur similaire qui explique pourquoi votre application doit être le gestionnaire par défaut pour un domaine particulier.
Envoyer la requête
Une fois que l'utilisateur a compris ce que votre application lui demande de faire, envoyez la requête.
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 intitulé Ouvrir par défaut. Cet écran contient une case d'option intitulée 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 sous 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é à 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 des domaines dans votre application que votre application ne peut pas valider
La fonction principale de votre application peut être d'ouvrir des liens en tant que tiers, sans pouvoir vérifier les domaines gérés. Si tel est le cas, expliquez aux utilisateurs qu'au moment où 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 boîte de dialogue ou une activité de trampoline permettant à l'utilisateur d'ouvrir le lien dans l'application propriétaire s'il préfère le faire, en agissant en tant que proxy. Avant de configurer une telle boîte de dialogue ou une telle activité de trampoline, configurez votre application pour qu'elle dispose d'une visibilité de package dans les applications propriétaires correspondant au filtre d'intent Web de votre application.
Tester les liens vers une application
Lorsque vous implémentez la fonctionnalité d'association d'applications, vous devez tester la fonctionnalité d'association 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 à valider
Lors des tests, vous devez confirmer la liste des hôtes associés que le système doit vérifier pour votre application. Faites 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
Utilisez cette liste pour vérifier qu'un fichier JSON Digital Asset Links est fourni sur 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
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 les applications de votre appareil connecté:
adb shell dumpsys package domain-preferred-apps
Vous pouvez également procéder comme suit:
adb shell dumpsys package d
Remarque:Veillez à attendre au moins 20 secondes après l'installation de votre application pour permettre au système de terminer la procédure de validation.
La commande renvoie la liste de chaque utilisateur ou profil défini sur l'appareil, précédée 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 lister 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 liste indique les applications associées aux domaines pour cet utilisateur:
Package: identifie une application par son nom de package, tel que déclaré dans son fichier manifeste.Domains: affiche la liste complète des hôtes dont les liens Web sont gérés par cette application, en utilisant des espaces vides comme séparateurs.Status: affiche le paramètre de gestion des liens actuel pour cette application. Une application ayant réussi la validation et dont le fichier manifeste contientandroid:autoVerify="true"affiche un état dealways. 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 de liaison d'une application avant la fin de la validation, vous pouvez constater un faux positif indiquant une validation réussie, 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 les liens compatibles sans le demander. En effet, les préférences utilisateur prévalent sur la validation programmatique (ou son absence). 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 pouvoir valider votre application avec chacun des sites Web que vous spécifiez dans un filtre d'intent donné qui répond aux critères des liens vers une application. L'exemple suivant présente une configuration de fichier manifeste avec plusieurs liens d'application 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 tenterait de valider à 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 valider à 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'énoncés, consultez la section Créer une liste d'énoncés.
Corriger les erreurs d'implémentation courantes
Si vous ne parvenez pas à valider vos liens vers des applications Android, vérifiez 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.
- Filtre d'intent incorrect configuré
- Vérifiez si vous incluez une URL qui n'appartient pas à votre application dans un élément
<intent-filter>. - Configuration incorrecte du serveur
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) affiche 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 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. N'oubliez pas que, sur Android 11 et versions antérieures, ces liens empêchent le système de valider tous les liens vers une application Android 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. Voici quelques erreurs courantes:
- Signature de l'application avec un certificat de débogage et signature de la version uniquement dans
assetlinks.json. - 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 JSON complet, en suivant les instructions sur la déclaration d'associations de sites Web.
- Signature de l'application avec un certificat de débogage et signature de la version uniquement dans