Valider Android App Links

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. Android App Links utilise l'API Digital Asset Links pour s'assurer que votre application a été approuvée par le site Web pour ouvrir automatiquement les liens pour ce domaine. Si le système valide la propriété des URL, il achemine automatiquement ces intents d'URL vers votre application.

Pour vérifier que vous êtes propriétaire à la fois de votre application et des URL du site Web, procédez comme suit:

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

  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 connexes dans les ressources suivantes:

Ajouter des filtres d'intent pour la validation des liens d'application

Pour activer la validation de la gestion des liens pour votre application, ajoutez des filtres d'intent correspondant au format suivant:

<!-- Make sure you explicitly set android:autoVerify to "true". -->
<intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />

    <!-- If a user clicks on a shared link that uses the "http" scheme, your
         app should be able to delegate that traffic to "https". -->
    <data android:scheme="http" />
    <data android:scheme="https" />

    <!-- Include one or more domains that should be verified. -->
    <data android:host="..." />
</intent-filter>

Bien qu'il soit suffisant d'inclure autoVerify dans une seule déclaration <intent-filter> pour chaque hôte, même si cet hôte est utilisé dans d'autres déclarations non marquées, nous vous recommandons d'ajouter autoVerify à chaque élément <intent-filter> pour plus de cohérence. Cela garantit également qu'après avoir supprimé ou refactorisé des éléments de votre fichier manifeste, votre application reste associée à tous les domaines que vous définissez encore.

Le processus de validation du domaine nécessite une connexion Internet et peut prendre un certain temps. Pour améliorer l'efficacité du processus, le système ne valide un domaine pour une application qui cible Android 12 ou version ultérieure que si ce domaine se trouve dans un élément <intent-filter> contenant le format exact spécifié dans l'extrait de code précédent.

Permettre l'association d'applications pour plusieurs hôtes

Le système doit être en mesure de valider l'hôte spécifié dans les éléments de données des filtres d'intent d'URL de l'application par rapport aux fichiers Digital Asset Links hébergés sur les domaines Web respectifs de ce filtre d'intent. Si la validation échoue, le système applique 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 tous les formats d'URL définis dans les autres filtres d'intent de l'application.

Remarque:Sur Android 11 (niveau d'API 30) ou version antérieure, le système ne valide pas votre application en tant que gestionnaire par défaut, sauf s'il trouve un fichier Digital Asset Links correspondant pour tous les hôtes que vous définissez dans le fichier manifeste.

Par exemple, une application avec les filtres d'intent suivants ne réussirait la validation que pour https://www.example.com si un fichier assetlinks.json a été 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. Cependant, il est associé à l'autre élément <data> afin que le filtre d'intent accepte à la fois http://www.example.com et https://www.example.com. Par conséquent, vous devez créer des filtres d'intent distincts lorsque vous souhaitez définir des combinaisons spécifiques de schémas et de domaines d'URI.

Permettre l'association d'applications pour plusieurs sous-domaines

Le protocole Digital Asset Links traite les sous-domaines de vos filtres d'intent comme des hôtes uniques et distincts. Ainsi, si votre filtre d'intent répertorie plusieurs hôtes avec différents sous-domaines, vous devez publier un élément assetlinks.json valide 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. Par conséquent, un assetlinks.json valide doit être publié à la fois sur https://www.example.com/.well-known/assetlinks.json et sur 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 (tel que *.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 passera la validation pour n'importe quel sous-nom de example.com (comme foo.example.com) tant que le fichier assetlinks.json est publié à l'adresse https://example.com/.well-known/assetlinks.json:

<application>
  <activity android:name=”MainActivity”>
    <intent-filter android:autoVerify="true">
      <action android:name="android.intent.action.VIEW" />
      <category android:name="android.intent.category.DEFAULT" />
      <category android:name="android.intent.category.BROWSABLE" />
      <data android:scheme="https" />
      <data android:host="*.example.com" />
    </intent-filter>
  </activity>
</application>

Rechercher plusieurs applications associées au même domaine

Si vous publiez plusieurs applications qui sont chacune associées 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 d'accès de domaine, comme c'est peut-être le cas avec les versions allégées et complètes d'une application, seule l'application installée la 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é sur le package nécessaire. Dans votre application, affichez ensuite une boîte de dialogue de sélection personnalisée contenant les résultats de l'appel de queryIntentActivities(). L'utilisateur peut sélectionner son application préférée dans la liste des applications correspondantes qui s'affiche dans la boîte de dialogue.

Déclarer des associations de sites Web

Vous devez publier un fichier JSON Digital Asset Links sur votre site Web pour indiquer les applications Android associées au site et valider les intents d'URL de l'application. Le fichier JSON identifie les applications associées à l'aide des champs suivants:

  • package_name: ID 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 le keytool Java :
    keytool -list -v -keystore my-release-key.keystore
    
    Ce champ accepte plusieurs empreintes, qui peuvent être utilisées pour différentes versions de votre application, telles que les builds de débogage et de production.

    Si vous utilisez la signature d'application Play pour votre application, l'empreinte du certificat générée en exécutant keytool localement ne correspond généralement pas à celle 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 sous Release > Setup > App signing. Dans ce cas, vous trouverez également sur la même page l'extrait JSON Digital Asset Links approprié pour votre application.

L'exemple de fichier assetlinks.json suivant accorde des droits d'ouverture de liens à 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 suivante montre un exemple de fichier d'instruction qui déclare l'association à deux applications séparément et qui 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"]
  }
}]

Plusieurs applications peuvent gérer les liens de différentes ressources associées au 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 des certificats identiques ou différents.

Associer plusieurs sites Web à une seule application

Plusieurs sites Web peuvent déclarer des associations avec la même application dans leurs fichiers assetlinks.json respectifs. Les listes de fichiers suivantes montrent comment déclarer l'association entre example.com et example.net et app1. La première liste montre l'association du site example.com avec 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 entre example.net et app1. Seul l'emplacement où ces fichiers sont hébergés est différent (.com et .net):

https://www.example.net/.well-known/assetlinks.json

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.mycompany.app1",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
}]

Publier le fichier de validation JSON

Vous devez publier votre fichier de validation JSON à l'emplacement suivant:

https://domain.name/.well-known/assetlinks.json

Assurez-vous de ce qui suit:

  • Le fichier assetlinks.json est diffusé avec le type de contenu application/json.
  • Le fichier assetlinks.json doit ê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.json doit être accessible sans aucune redirection (pas de redirections 301 ou 302).
  • Si vos liens d'application sont compatibles avec plusieurs domaines hôtes, vous devez publier le fichier assetlinks.json sur chaque domaine. Consultez Prendre en charge l'association d'applications pour plusieurs hôtes.
  • Ne publiez pas votre application avec des URL de développement/test dans le fichier manifeste qui pourraient ne pas être accessibles au public (par exemple, celles qui ne sont accessibles qu'avec un VPN). Dans ce cas, une solution de contournement consiste à configurer les variantes de compilation afin de générer un fichier manifeste différent pour les builds de développement.

Validation Android App Links

Lorsque android:autoVerify="true" est présent dans au moins l'un des filtres d'intent de votre application, l'installation de celle-ci sur un appareil exécutant Android 6.0 (niveau d'API 23) ou une version ultérieure entraîne la validation automatique des hôtes associés aux URL dans les filtres d'intent de votre application. Sur Android 12 ou version ultérieure, vous pouvez également appeler manuellement le processus de validation pour tester la logique de validation.

Validation automatique

La validation 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, Android interroge les sites Web correspondants pour le fichier Digital Asset Links sur https://hostname/.well-known/assetlinks.json.

Après avoir confirmé la liste des sites Web à associer à votre application et vérifié que le fichier JSON hébergé est valide, installez l'application sur votre appareil. Attendez au moins 20 secondes pour 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 bonnes règles de gestion des liens:

adb shell am start -a android.intent.action.VIEW \
    -c android.intent.category.BROWSABLE \
    -d "http://domain.name:optional_port"

Vérification manuelle

À partir d'Android 12, vous pouvez appeler manuellement la validation du domaine pour une application installée sur un appareil. Vous pouvez effectuer ce processus que votre application cible Android 12 ou non.

Établir une connexion Internet

Pour effectuer la validation du domaine, votre appareil de test doit être connecté à Internet.

Prendre en charge le nouveau processus de validation du domaine

Si votre application cible Android 12 ou une 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 d'Android App Links sur un appareil

Avant d'appeler manuellement la validation du domaine sur un appareil, vous devez réinitialiser l'état d'Android App Links sur l'appareil de test. Pour ce faire, exécutez la commande suivante dans une fenêtre de terminal:

adb shell pm set-app-links --package PACKAGE_NAME 0 all

Cette commande place l'appareil dans le même état qu'avant avant que l'utilisateur ne choisisse des applications par défaut pour tous les domaines.

Appeler le processus de validation du domaine

Après avoir réinitialisé l'état d'Android App Links sur un appareil, vous pouvez effectuer la validation 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

Attendez que l'agent de validation termine ses requêtes, puis examinez les résultats. Pour ce faire, exécutez la commande suivante:

adb shell pm get-app-links PACKAGE_NAME

Le résultat de cette commande ressemble à ce qui suit:

com.example.pkg:
    ID: 01234567-89ab-cdef-0123-456789abcdef
    Signatures: [***]
    Domain verification state:
      example.com: verified
      sub.example.com: legacy_failure
      example.net: verified
      example.org: 1026

Les domaines dont la validation a réussi sont associés à l'état de validation 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 l'agent de validation n'a peut-être pas encore terminé le processus de validation.

La liste suivante présente les valeurs renvoyées que la validation du domaine peut renvoyer pour un domaine donné:

none
Aucun enregistrement n'a été effectué pour ce domaine. Attendez quelques minutes de plus que l'agent de validation termine les requêtes liées à la validation du domaine, puis appelez à nouveau le processus de validation du domaine.
verified
Le domaine a bien été validé pour l'application à l'origine de la déclaration.
approved
Le domaine a été approuvé d'office, généralement à l'aide d'une commande shell.
denied
Le domaine a été refusé de force, généralement à l'aide d'une commande shell.
migrated
Le système a conservé le résultat d'un processus précédent qui utilisait l'ancienne validation de domaine.
restored
Le domaine a été approuvé après que l'utilisateur a effectué une restauration des données. Nous supposons que le domaine a déjà été validé.
legacy_failure
Le domaine a été refusé par un ancien vérificateur. Le motif spécifique de l'échec est inconnu.
system_configured
Le domaine a été approuvé automatiquement par la configuration de l'appareil.
Code d'erreur 1024 ou supérieur

Code d'erreur personnalisé spécifique au vérificateur de l'appareil.

Vérifiez que vous avez établi une connexion réseau et appelez à nouveau le processus de validation du domaine.

Demander à l'utilisateur d'associer votre application à un domaine

Une autre façon pour votre application d'être approuvée pour un domaine consiste à demander à l'utilisateur d'associer votre application à ce domaine.

Vérifier si votre application est déjà approuvée pour le domaine

Avant d'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:

Gestionnaire de validation de domaine

L'extrait de code suivant montre comment utiliser l'API DomainVerificationManager:

Kotlin

val context: Context = TODO("Your activity or fragment's Context")
val manager = context.getSystemService(DomainVerificationManager::class.java)
val userState = manager.getDomainVerificationUserState(context.packageName)

// Domains that have passed Android App Links verification.
val verifiedDomains = userState?.hostToStateMap
    ?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_VERIFIED }

// Domains that haven't passed Android App Links verification but that the user
// has associated with an app.
val selectedDomains = userState?.hostToStateMap
    ?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_SELECTED }

// All other domains.
val unapprovedDomains = userState?.hostToStateMap
    ?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_NONE }

Java

Context context = TODO("Your activity or fragment's Context");
DomainVerificationManager manager =
        context.getSystemService(DomainVerificationManager.class);
DomainVerificationUserState userState =
        manager.getDomainVerificationUserState(context.getPackageName());

Map<String, Integer> hostToStateMap = userState.getHostToStateMap();
List<String> verifiedDomains = new ArrayList<>();
List<String> selectedDomains = new ArrayList<>();
List<String> unapprovedDomains = new ArrayList<>();
for (String key : hostToStateMap.keySet()) {
    Integer stateValue = hostToStateMap.get(key);
    if (stateValue == DomainVerificationUserState.DOMAIN_STATE_VERIFIED) {
        // Domain has passed Android App Links verification.
        verifiedDomains.add(key);
    } else if (stateValue == DomainVerificationUserState.DOMAIN_STATE_SELECTED) {
        // Domain hasn't passed Android App Links verification, but the user has
        // associated it with an app.
        selectedDomains.add(key);
    } else {
        // All other domains.
        unapprovedDomains.add(key);
    }
}

Programme de ligne de commande

Lorsque vous testez votre application pendant le développement, vous pouvez exécuter la commande suivante pour interroger l'état de validation des domaines appartenant à votre organisation:

adb shell pm get-app-links --user cur PACKAGE_NAME

Dans l'exemple de résultat suivant, même si la validation de l'application a échoué pour le domaine "example.org", l'utilisateur 0 l'a approuvée manuellement 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é. Une explication complète de ces commandes est disponible à partir de la sortie de adb shell pm.

Fournir le contexte de la demande

Avant d'envoyer cette demande d'approbation de domaine, fournissez des informations contextuelles à l'utilisateur. Par exemple, vous pouvez afficher un écran de démarrage, une boîte de dialogue ou un élément d'interface utilisateur similaire qui explique à l'utilisateur pourquoi votre application doit être le gestionnaire par défaut d'un domaine particulier.

Envoyer la requête

Une fois que l'utilisateur a compris ce que votre application lui demande de faire, envoyez la demande. Pour ce faire, appelez un intent qui inclut l'action d'intent ACTION_APP_OPEN_BY_DEFAULT_SETTINGS et une chaîne de données correspondant à package:com.example.pkg pour l'application cible, comme indiqué dans l'extrait de code suivant:

Kotlin

val context: Context = TODO("Your activity or fragment's Context")
val intent = Intent(Settings.ACTION_APP_OPEN_BY_DEFAULT_SETTINGS,
    Uri.parse("package:${context.packageName}"))
context.startActivity(intent)

Java

Context context = TODO("Your activity or fragment's Context");
Intent intent = new Intent(Settings.ACTION_APP_OPEN_BY_DEFAULT_SETTINGS,
    Uri.parse("package:" + context.getPackageName()));
context.startActivity(intent);

Lorsque l'intent est appelé, les utilisateurs voient un écran de paramètres intitulé Open by default (Ouvrir par défaut). Cet écran contient une case d'option appelée Open supported links (Ouvrir les liens compatibles), comme illustré dans la figure 1.

Lorsque l'utilisateur active l'option Ouvrir les liens compatibles, une série de cases à cocher s'affiche dans une section intitulée Liens à ouvrir dans cette application. À partir de là, les utilisateurs peuvent sélectionner les domaines qu'ils souhaitent associer à votre application. Ils peuvent également sélectionner Ajouter un lien pour ajouter des domaines, comme illustré dans la figure 2. Lorsque les utilisateurs sélectionnent ultérieurement un lien dans les domaines qu'ils ajoutent, celui-ci s'ouvre automatiquement dans votre application.

Lorsque la case d&#39;option est activée, la section en bas de l&#39;écran comprend des cases à cocher et un bouton intitulé &quot;Ajouter un lien&quot;.
Figure 1. Écran des paramètres système où les utilisateurs peuvent choisir les liens à ouvrir par défaut dans votre application.
Chaque case à cocher représente un domaine que vous pouvez ajouter. Les boutons de la boîte de dialogue sont &quot;Annuler&quot; et &quot;Ajouter&quot;.
Figure 2. Boîte de dialogue dans laquelle les utilisateurs peuvent choisir d'autres domaines à associer à votre application.

Ouvrir des domaines dans votre application que celle-ci ne peut pas valider

La fonction principale de votre application peut être d'ouvrir des liens en tant que tiers, sans pouvoir vérifier les domaines qu'il gère. Dans ce cas, expliquez aux utilisateurs qu'à ce moment-là, lorsqu'ils sélectionnent un lien Web, ils ne peuvent pas choisir entre une application propriétaire et votre application (tierce). Les utilisateurs doivent associer manuellement les domaines à votre application tierce.

En outre, envisagez d'introduire une boîte de dialogue ou une activité de trampoline qui permet à l'utilisateur d'ouvrir le lien dans l'application propriétaire s'il préfère le faire, en tant que proxy. Avant de configurer une boîte de dialogue ou une activité de trampoline, configurez votre application de sorte qu'elle ait la visibilité du package dans les applications propriétaires qui correspondent au filtre d'intent Web de votre application.

Tester les liens vers l'application

Lorsque vous implémentez la fonctionnalité d'association d'applications, vous devez la tester pour vous assurer que le système peut associer votre application à vos sites Web et gérer les requêtes d'URL comme prévu.

Pour tester un fichier d'instruction existant, vous pouvez utiliser le générateur et testeur de liste d'instructions.

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 valider pour votre application. Dressez la liste de toutes les URL dont les filtres d'intent correspondants incluent les attributs et éléments suivants:

  • Attribut android: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 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

Dans le cadre de votre processus de test, vous pouvez vérifier les paramètres système actuels concernant la gestion des liens. Utilisez la commande suivante pour obtenir la liste des règles de gestion des associations existantes pour toutes les applications de votre appareil connecté:

adb shell dumpsys package domain-preferred-apps

La commande suivante produit la même chose:

adb shell dumpsys package d

Remarque:Veillez à attendre au moins 20 secondes après l'installation de votre application pour que le système puisse finaliser la procédure de validation.

La commande renvoie une liste de chaque utilisateur ou profil défini sur l'appareil, précédé d'un en-tête au format suivant:

App linkages for user 0:

Après cet en-tête, la sortie utilise le format suivant pour 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 de cet utilisateur:

  • Package : identifie une application par son nom de package, tel qu'indiqué 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 les séparant par des espaces.
  • Status : affiche le paramètre de gestion des liens actuel pour cette application. Une application qui a réussi le processus de validation et dont le fichier manifeste contient android:autoVerify="true" affiche l'état always. Le nombre hexadécimal après cet état est lié à l'enregistrement par le système Android des préférences d'association d'applications de l'utilisateur. Cette valeur n'indique pas si la validation a réussi.

Remarque:Si un utilisateur modifie les paramètres de lien d'une application avant la fin de la validation, vous verrez peut-être un faux positif pour une validation réussie, même si celle-ci 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 abouti.

Exemple de test

Pour que la validation des liens d'application aboutisse, le système doit être en mesure de valider votre application pour chacun des sites Web que vous spécifiez dans un filtre d'intent donné et qui répond aux critères des liens d'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>

La liste des hôtes que la plate-forme tenterait de valider à partir du fichier manifeste ci-dessus est la suivante:

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'instructions, consultez la page Créer une liste d'instructions.

Corriger les erreurs d'implémentation courantes

Si vous ne parvenez pas à valider Android App Links, recherchez les erreurs courantes suivantes. Cette section utilise example.com comme nom de domaine d'espace réservé. Lorsque vous effectuez ces vérifications, remplacez example.com par le véritable nom de domaine de votre serveur.

Configuration du filtre d'intent incorrecte
Vérifiez si vous incluez une URL dont votre application n'est pas propriétaire dans un élément <intent-filter>.
Configuration du serveur incorrecte

Vérifiez la configuration JSON de votre serveur et assurez-vous que la valeur SHA est correcte.

Vérifiez également que example.com. (avec le point final) diffuse le même contenu que example.com.

Redirections côté serveur

Le système ne valide aucun Android App Links pour votre application si vous configurez une redirection comme celle-ci:

  • Du http://example.com au https://example.com
  • Du example.com au 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 intentionnellement ajouter des liens non vérifiables. Gardez à l'esprit que, sur Android 11 et versions antérieures, ces associations empêchent le système de valider tous les liens Android App Links pour votre application.

Signature incorrecte dans le fichier 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 version uniquement dans assetlinks.json.
  • Utiliser une signature en minuscules dans assetlinks.json La signature doit être en majuscules.
  • Si vous utilisez la signature d'application Play, assurez-vous d'utiliser la signature utilisée par Google pour signer chacune de vos versions. Vous pouvez vérifier ces informations, y compris un extrait JSON complet, en suivant les instructions pour déclarer des associations de sites Web.