Valider Android App Links

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:

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

  2. 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:

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 fichier build.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:
    keytool -list -v -keystore my-release-key.keystore
    
    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.

    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 sous Release > 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 :

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. Seuls les 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.json est diffusé avec la valeur content-type application/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:

  1. 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 et android.intent.category.DEFAULT
    • Schéma de données: http ou https
  2. 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:

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.

Lorsque la case d&#39;option est activée, une section en bas de l&#39;écran
    comprend des cases à cocher, ainsi qu&#39;un bouton &quot;Ajouter un lien&quot;
Figure 1. Écran des paramètres système où les utilisateurs peuvent choisir quels liens s'ouvrent par défaut dans votre appli.
Chaque case à cocher représente un domaine que vous pouvez ajouter. La
    les boutons de la boîte de dialogue sont &quot;Annuler&quot; et sur &quot;Ajouter&quot;.
Figure 2. Boîte de dialogue permettant aux utilisateurs de choisir des domaines supplémentaires à associer à 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 valeur http ou https
  • 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

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 contient android:autoVerify="true", affiche un état sur always. 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 que example.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.

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.