App Links Android non vérifiés : le diagnostic en cinq minutes avec adb
Depuis Android 12, un App Link dont la vérification de domaine échoue s’ouvre dans le navigateur au lieu de votre app — en silence, et pas sur tous les appareils. Voici la checklist adb qui trouve la cause vite, y compris le désaccord de clé de signature Play derrière la plupart de ces incidents.
L’app est installée. Le lien ouvre quand même Chrome.
Cela arrive en général sous forme de ticket support, pas d’erreur. Quelqu’un touche un lien vers votre domaine, l’app est bien sur son téléphone, et c’est Chrome qui s’ouvre. Depuis Android 12, selon la documentation Android, un lien https n’ouvre votre app que si le système a vérifié votre domaine à l’installation — et quand cette vérification échoue, elle échoue en silence. Pas de crash, pas de message, rien dans vos tableaux de bord.
Deux propriétés compliquent le débogage. La vérification est par domaine : example.com peut être vérifié pendant que promo.example.com ne l’est pas. Et elle est par appareil : la même build peut passer sur un Pixel et échouer sur un Samsung, une combinaison signalée à répétition sur les forums développeurs Samsung. En plein incident ? Passez directement au diagnostic.
Deux domaines, deux verdicts
Ce qui se passe vraiment à l’installation
À l’installation ou à la mise à jour, Android lit chaque domaine déclaré avec autoVerify et télécharge https://votredomaine/.well-known/assetlinks.json pour chacun. Selon la documentation Android, le fichier doit répondre par un 200 direct en HTTPS avec le content type application/json — le vérificateur ne suit pas les redirections. Le résultat est mis en cache par domaine ; c’est pourquoi un sous-domaine peut être vérifié et pas son voisin.
Dans le fichier, sha256_cert_fingerprints doit correspondre au certificat qui a signé l’APK de l’appareil. Le piège numéro un : avec Play App Signing, ce certificat est la clé de signature de Google — pas votre clé d’upload. L’empreinte de votre keystore local vérifie parfaitement vos builds installées à la main, et échoue sur chaque installation venue du Play Store.
Une propriété de plus : le verdict est mis en cache. Corriger le JSON côté serveur ne change rien sur les téléphones déjà en échec tant que la vérification n’a pas retourné — ce que, heureusement, vous pouvez forcer.
Le diagnostic en cinq minutes
Branchez n’importe quel appareil Android 12+ avec l’app installée et exécutez ceci dans l’ordre. La plupart des incidents se règlent à l’étape trois.
Lisez l’état de vérification
adb shell pm get-app-links com.example.appCette commande affiche chaque domaine déclaré avec son état. verified signifie que la poignée de main a réussi ; none, que le vérificateur n’a jamais approuvé le domaine — c’est lui qui envoie les utilisateurs vers Chrome. Sur les appareils multi-utilisateurs, vérifiez aussi la section par utilisateur en bas.
Téléchargez assetlinks.json comme le vérificateur
curl -sI https://example.com/.well-known/assetlinks.jsonIl faut un 200 direct. Tout 301 ou 302 fait échouer la vérification, car selon la documentation Android le vérificateur ne suit pas les redirections. Confirmez que content-type vaut application/json, puis téléchargez le corps et lisez le package name et les empreintes de vos propres yeux. Une protection anti-bots devant /.well-known/ compte aussi comme un échec.
Comparez l’empreinte à la clé de signature Play
Play Console → App integrity → App signing key certificateOuvrez cette page de la Play Console et posez le SHA-256 à côté de votre JSON. Ils doivent correspondre octet par octet. Si votre fichier porte l’empreinte de la clé d’upload, vous avez trouvé le bug — ajoutez l’empreinte de la clé de signature Play, et gardez les deux si vous distribuez aussi hors Play Store.
Forcez une re-vérification
adb shell pm verify-app-links --re-verify com.example.appAprès avoir corrigé le serveur, demandez à l’appareil de réessayer. Le vérificateur est asynchrone : patientez quelques secondes, répétez l’étape un et guettez le passage de none à verified. Sur certains Samsung, l’état ne bouge qu’après un redémarrage — un schéma signalé sur les forums développeurs Samsung.
Déclenchez l’intent comme un vrai tap
adb shell am start -a android.intent.action.VIEW -d "https://example.com/promo"C’est le test de bout en bout. Sur un domaine vérifié, l’app s’ouvre directement, sans sélecteur. Si le navigateur ou une feuille de choix apparaît, l’état n’a pas encore basculé — revérifiez l’étape un avant de conclure que votre correctif a échoué.
Si vous préférez ne pas relire du JSON à l’œil en plein incident, notre outil de validation de liens télécharge votre assetlinks.json et vérifie code de statut, content type et format des empreintes en une passe.
Les suspects habituels
Cinq causes couvrent presque tous les signalements. Cause à gauche, correctif à droite.
Le JSON porte l’empreinte de la clé d’upload, pas celle de signature Play
Copiez le SHA-256 depuis Play Console → App integrity → App signing key certificate. Gardez les deux empreintes si vous distribuez aussi des builds signées avec la clé d’upload.
assetlinks.json répond par une redirection ou un 404
Servez le fichier directement à /.well-known/assetlinks.json sur chaque hôte déclaré. Pour le vérificateur, www et le domaine nu sont deux domaines distincts.
Mauvais content type, comme text/html ou text/plain
Configurez le serveur ou le CDN pour envoyer application/json sur ce chemin. Un JSON valide avec le mauvais en-tête échoue quand même.
Plusieurs flavors ou package names, un absent du fichier
Le fichier est un tableau : une déclaration par package name, chacune avec ses empreintes. Un flavor manquant n’échoue que pour lui, ce qui paraît aléatoire en QA.
Un Samsung reste sur none après correction du JSON
La vérification retardée sur certains modèles Samsung revient souvent sur leurs forums développeurs. Forcez la re-vérification, puis redémarrez l’appareil avant toute autre conclusion.
Ce qu’Android 15 et 16 ont changé
Deux versions récentes ont déplacé les repères dans la même direction : les App Links https vérifiés sont la voie supportée, et tout le reste se rétrécit.
A introduit les Dynamic App Links, selon les notes de version : les associations de domaine peuvent être mises à jour sans publier un nouvel APK, ce qui raccourcit le délai entre votre correctif JSON et sa prise en compte par les appareils.
A durci la vérification des schémas URI personnalisés, selon les notes de version. Si une partie de votre parcours dépend encore de schémas myapp://, considérez-les comme hérités et déplacez ces entrées vers des liens https vérifiés.
Où un smart link trouve honnêtement sa place
Un smart link route côté serveur, avant que toute cette machinerie n’intervienne : à l’ouverture d’un lien Appy, la redirection lit l’appareil et envoie les visiteurs Android, iOS et desktop vers des destinations différentes. Ce routage fonctionne sur tous les plans et ne dépend pas de la vérification sur l’appareil, car il a lieu avant que l’OS ne voie votre domaine.
Soyons clairs sur ce qu’il ne fait pas : un smart link ne contourne pas la vérification des App Links. La redirection se termine sur votre domaine https, et le même état verified-ou-none décide si l’app ou le navigateur s’ouvre. Ce qu’il vous donne en plein incident, c’est une porte d’entrée pilotable — dirigez le trafic Android vers la fiche Play Store ou le web pendant que vous réparez assetlinks.json, puis rebasculez la destination sans toucher à rien d’imprimé, les QR dynamiques restant modifiables après impression. Les analytics montrent combien de trafic Android a traversé le chemin cassé.
Réparez la vérification dans tous les cas. Les destinations deeplink en Pro et le deferred deep linking en Enterprise sont utiles, mais ils reposent sur un assetlinks.json qui fonctionne — ils ne le remplacent pas.
Questions fréquentes
Pourquoi le même lien marche-t-il sur un appareil et pas un autre ?
La vérification s’exécute sur chaque appareil à l’installation ; chaque téléphone garde donc son propre verdict en cache. Un souci réseau pendant l’installation, un vérificateur OEM différent — Samsung étant le cas le plus signalé sur ses forums développeurs — ou une installation antérieure à votre correctif JSON produisent des états différents pour la même build.
Faut-il publier une mise à jour de l’app ?
En général non. Si le manifest déclare déjà le domaine avec autoVerify, la panne se trouve dans le JSON ou l’empreinte, tous deux côté serveur. Corrigez le fichier, forcez la re-vérification, et la build installée rouvre les liens. Une mise à jour n’est nécessaire que si le domaine n’a jamais été déclaré.
Un smart link contourne-t-il la vérification ?
Non, et méfiez-vous de qui prétend le contraire. La redirection choisit la destination côté serveur, mais une fois le visiteur sur votre domaine https, le système applique le même état de vérification que d’habitude. Un smart link change ce que vous pouvez faire pendant la panne — router vers le store ou le web — pas le fait qu’elle existe.
Au bout de combien de temps la vérification réessaie-t-elle seule ?
Selon la documentation Android, le vérificateur retente les domaines en échec et se relance à la mise à jour de l’app, mais le calendrier n’est pas garanti et varie selon les OEM. En pratique : de quelques heures à quelques jours. Forcer la re-vérification via adb ou réinstaller l’app va plus vite que d’attendre.
Continuer à explorer
Le plan gratuit d’AppsFlyer vient de rétrécir : ce qui passe au payant, et vos options
Le deferred deep linking, les domaines de marque, les Smart Banners, les liens en masse et l’API ont quitté le plan gratuit Zero. Ce qui a changé, le coût de remplacement et une migration qui tient dans une après-midi.
Transmission de paramètres pour deeplinks, Universal Links, stores et web
Découvrez comment préserver les paramètres de campagne et de contexte vers l’app, les stores, Universal Links et le web sans écraser les valeurs fixes.
Deferred deep linking : comment ça marche et quand l’utiliser
Transportez l’intention initiale du lien à travers l’installation pour que les nouveaux utilisateurs arrivent sur la bonne page et non sur la home par défaut.
Vous cherchez autre chose ? Parcourez tous les sujets sur le blog.
Donnez au trafic Android un endroit où atterrir
Créez un smart link qui détecte l’appareil côté serveur et route les visiteurs Android vers l’app, le store ou le web — puis changez la destination plus tard sans réimprimer un seul QR code.
Créer un smart link gratuit