Structure de l'application et navigation
Liens profonds
Ouvrir des pages précises depuis des URL et des notifications
1Qu'est-ce qu'un lien profond ?#
Les liens profonds permettent à des sources externes (navigateurs, SMS, e-mails, réseaux sociaux, notifications push, codes QR) d'ouvrir votre application directement sur une page précise plutôt que sur la page d'accueil.
Votre application prend en charge deux types, et ils ne sont PAS aussi faciles à mettre en place l'un que l'autre :
- ⚡ Schéma personnalisé (myapp://path) - fonctionne immédiatement, rien à configurer. Idéal pour les notifications push et les codes QR.
- 🌐 Liens https:// (https://mysite.com/page) - nécessitent UN fichier téléversé sur votre site web. Sans lui, Android garde le lien dans le navigateur et votre application ne s'ouvre jamais. C'est la raison la plus courante pour laquelle les liens profonds « ne fonctionnent pas ».
Les deux sont couverts ci-dessous. Si vous voulez seulement quelque chose qui marche dès aujourd'hui, utilisez le schéma personnalisé.
2Comment fonctionnent les URL à schéma personnalisé#
Lorsqu'un lien à schéma personnalisé est touché (par ex. myapp://products/shoes), l'application :
- Reçoit l'URL du schéma personnalisé
- La fait correspondre automatiquement à l'URL de votre site web
- Ouvre le WebView sur la bonne page
✅ Le schéma est dérivé du nom de votre application (minuscules, lettres uniquement).
✅ Exemple de correspondance :
myapp://products/shoes
→ https://mysite.com/products/shoes
Les segments de chemin après le schéma sont conservés et ajoutés au domaine de votre site web.
Custom scheme format:
<appname>://<path>
Examples:
myshop://cart
→ https://myshop.com/cart
puma://in/en/help
→ https://in.puma.com/in/en/help3Liens https:// - un fichier doit être placé sur votre site web#
C'est la partie que beaucoup manquent, alors lisez-la avant de tester.
AppMint place automatiquement votre domaine dans l'application. Mais Android N'ouvrira PAS votre application depuis un lien https:// tant que votre SITE WEB n'a pas prouvé que l'application vous appartient. Sur Android 12 et versions ultérieures, un lien non prouvé ouvre simplement le navigateur - sans boîte de dialogue, sans choix. C'est pourquoi un lien peut sembler « ne rien faire ».
La preuve tient en un petit fichier. AppMint l'a déjà créé pour vous : après la compilation, cherchez assetlinks.json dans Téléchargements. Il contient le nom du package et l'empreinte de signature de votre application.
Téléversez-le sur votre site web à EXACTEMENT cette adresse (le nom du dossier commence par un point) :
https://yoursite.com/.well-known/assetlinks.json
Rules — all four must be true:
1. Served over https (not http)
2. Content-Type: application/json
3. NO redirect (a redirect to www breaks it)
4. Reachable publicly — no login, no Cloudflare challenge
Check it from any computer:
curl -i https://yoursite.com/.well-known/assetlinks.json4Vous publiez sur Google Play ? Utilisez l'empreinte de Play#
Google Play re-signe votre application avec SA propre clé. L'empreinte dans l'assetlinks.json généré par AppMint - qui correspond à votre clé locale - ne correspondra donc pas à ce que les utilisateurs installent réellement depuis Play.
Si vous publiez sur Play, remplacez l'empreinte :
- Play Console → votre application → Test et publication → Configuration → Intégrité de l'application
- Copiez le SHA-256 depuis « Certificat de clé de signature de l'application »
- Mettez cette valeur dans assetlinks.json et téléversez-le à nouveau
Vous pouvez indiquer LES DEUX empreintes dans le même fichier - celle locale pour les APK que vous partagez directement, et celle de Play pour les installations depuis Play. Ainsi, les deux fonctionnent.
[{
"relation": ["delegate_permission/common.handle_all_urls"],
"target": {
"namespace": "android_app",
"package_name": "com.yourapp.name",
"sha256_cert_fingerprints": [
"AA:BB:...", // your local key (direct APK)
"11:22:..." // Play App Signing key
]
}
}]5Vérifier si Android l'a accepté#
Après avoir téléversé le fichier, RÉINSTALLEZ l'application (Android ne vérifie qu'à l'installation, et cela peut prendre une minute).
La commande ci-dessous vous dit la vérité. Cherchez votre domaine avec « verified ». S'il indique « legacy_failure » ou si le domaine est absent, le fichier n'est pas lu correctement - revenez en arrière et vérifiez les quatre règles.
# Does Android consider your domain verified?
adb shell pm get-app-links com.yourapp.name
# Force a re-check without reinstalling (Android 12+):
adb shell pm verify-app-links --re-verify com.yourapp.name
# Google's own checker (open in a browser):
https://digitalassetlinks.googleapis.com/v1/statements:list?
source.web.site=https://yoursite.com&
relation=delegate_permission/common.handle_all_urls6Pourquoi cela échoue généralement#
Par ordre de fréquence de chaque cause :
- Le fichier n'est pas téléversé ou se trouve au mauvais chemin. Il doit être à /.well-known/assetlinks.json - avec le point.
- www ou sans www. Android considère https://example.com et https://www.example.com comme des domaines DIFFÉRENTS. AppMint enregistre l'hôte exact de l'URL de votre site web. Si vous utilisez les deux, placez le fichier sur les deux et indiquez-nous quel hôte vous avez saisi.
- Une redirection. De nombreux hébergeurs redirigent le domaine racine vers www. Cela casse la vérification même si le fichier se charge dans un navigateur.
- Publié sur Play mais avec l'empreinte locale - voir l'étape précédente.
- Non réinstallée après le téléversement. Android vérifie à l'installation.
Les liens à schéma personnalisé (myapp://...) n'ont besoin de RIEN de tout cela et fonctionnent toujours - utilisez-les pour les notifications push et les codes QR si vous voulez quelque chose qui marche dès aujourd'hui.
7Tester les liens profonds via ADB#
Testez vos liens profonds depuis un PC connecté via le débogage USB :
- Activez le débogage USB sur votre téléphone
- Connectez-vous en USB
- Exécutez les commandes ci-dessous.
⚠️ Important : « am start » avec un lien https peut ouvrir votre application même lorsque la vérification a ÉCHOUÉ, car vous transmettez le lien directement à Android. Cela ne prouve pas qu'un vrai appui dans Gmail ou Chrome fonctionnera. Seul « pm get-app-links » (étape précédente) vous le dit. Utilisez am start pour vérifier le routage de vos PAGES, pas la configuration de votre domaine.
# Test custom scheme:
adb shell am start -a android.intent.action.VIEW \
-d "myapp://some/page"
# Test website URL:
adb shell am start -a android.intent.action.VIEW \
-d "https://mysite.com/some/page"
# Verify which app handles it:
adb shell cmd package resolve-activity --brief \
-a android.intent.action.VIEW \
-d "myapp://some/page"8Liens profonds dans les notifications push#
Lorsque vous envoyez une notification push via OneSignal, collez n'importe quelle URL de lien profond dans le champ « Launch URL ». L'application s'ouvrira et naviguera directement vers cette page.
Les deux types d'URL fonctionnent :
✅ https://mysite.com/flash-sale
✅ myapp://flash-sale
OneSignal Dashboard → New Push:
Launch URL: https://mysite.com/flash-sale
OR
Launch URL: myapp://flash-sale
Both will open the app on the sale page.9Important : comportement au lancement à chaud#
Si votre application est déjà en cours d'exécution en arrière-plan lorsqu'un lien profond est déclenché, Android transmet le lien directement sans redémarrer l'application - c'est ce qu'on appelle un « lancement à chaud ».
✅ Votre application gère cela automatiquement. Le WebView naviguera vers la nouvelle page même lorsque l'application est déjà ouverte.
⚠️ Si les liens profonds n'ouvrent que la page d'accueil, vérifiez que :
- L'URL de votre site web dans la configuration correspond au domaine du lien profond
- Le chemin dans l'URL du schéma personnalisé est correct
⚠️ Si les liens https:// n'ouvrent PAS DU TOUT l'application, ce n'est pas un problème de lancement à chaud - c'est l'étape assetlinks.json ci-dessus. Des liens à schéma personnalisé qui fonctionnent alors que les liens https ne font rien : c'est le signe classique.
Warm launch works automatically.
No extra setup needed.