Deep linking Android: setup (App Links)

Su Android i link che aprono l'app si chiamano App Links (verificati) o Deep Links (non verificati). Gli App Links sono l'equivalente delle Universal Links iOS: associati a un dominio HTTPS, verificati automaticamente, aprono direttamente l'app senza chooser.

App Links vs Deep Links

App Links: link https con dominio verificato tramite assetlinks.json; aprono direttamente l'app, niente chooser. Deep Links: schemi custom (es. myapp://) o https non verificati; mostrano il chooser ogni volta. Per UX premium scegli sempre App Links.

File assetlinks.json

JSON pubblicato su https://tuosito.it/.well-known/assetlinks.json. Contiene package_name dell'app e fingerprint SHA-256 della chiave di firma. Per Play App Signing usa il fingerprint generato da Google, non quello locale.

assetlinks.json multi-app

Un singolo file puo dichiarare più app (es. consumer app, internal admin app). Aggiungi più oggetti nell'array, ciascuno con package_name e SHA-256. Utile per organizzazioni con più app sullo stesso dominio. La verifica viene fatta indipendentemente per ciascuna.

Play App Signing

Con Play App Signing, Google firma le tue release con una chiave diversa da quella dell'upload. Devi inserire nel assetlinks.json il SHA-256 della "App signing key", visibile in Play Console -> Setup -> App integrity. Errore comune: usare la upload key, che fa fallire la verifica su device.

Domain verification API Android 12+

Da Android 12, l'utente puo gestire manualmente i domain verification nelle impostazioni di sistema. Se la verifica automatica fallisce, l'utente vede il chooser. Per debug: adb shell pm get-app-links com.tuoapp mostra lo stato; pm verify-app-links forza riverifica.

Intent filter avanzati

Usa autoVerify="true" solo per https intent filter. Per multiple schemes (https + myapp://) crea filter separati. Per host con wildcard usa android:host="*.tuosito.it". Path pattern supporta path, pathPrefix, pathPattern. Documenta nel codice per quali URL viene gestito ogni filter.

Test con adb

Comandi utili: adb shell am start -W -a android.intent.action.VIEW -d "https://example.com/path" com.tuoapp simula apertura link. adb shell dumpsys package domain-preferred-apps mostra app preferite per domini. adb shell pm get-app-links com.tuoapp mostra stato verifica. Strumenti indispensabili per debug pre-rilascio.

Chrome Custom Tabs

Per link che vuoi aprire in browser dentro l'app (es. termini, privacy), usa Chrome Custom Tabs invece di WebView: più sicuro, condivide sessione con Chrome, performance nativa. CustomTabsIntent.Builder() permette customizzazione (color toolbar, animation). Fallback automatico a WebView se Chrome non disponibile.

Procedura passo-passo

1. Crea il file assetlinks.json con package e SHA-256 fingerprint.
2. Pubblicalo sul dominio HTTPS, accessibile senza redirect.
3. Aggiungi intent-filter con autoVerify="true" nel manifest.
4. Specifica host e path negli intent-filter (data tag).
5. Gestisci l'intent nella Activity di destinazione.
6. Effettua il routing logico al fragment o screen.
7. Verifica con adb shell pm verify-app-links che la verifica sia riuscita.

Multi-domain support

Se la tua app gestisce più domini (es. app.example.com e app.example.it), serve assetlinks.json su ogni dominio con stessi package + SHA-256. Configura intent-filter per ogni dominio nel manifest. Verifica con pm get-app-links per ogni domain. Pattern comune per app con multi-tenancy o presenza multi-mercato.

Instant Apps

Android Instant Apps permettono di eseguire feature dell'app senza install via URL. Configurazione richiede module structure specifica. Use case: try-before-install, marketing flow. Riduce friction di acquisizione. La diffusione e calata negli ultimi anni a favore di PWA, ma resta valida per scenari specifici.

Test fingerprint corretto

Errore frequente: mettere il SHA-256 della upload keystore (locale dev) invece di quella della "App signing key" gestita da Play (Play App Signing). La fingerprint corretta e visibile in Play Console -> Setup -> App integrity. Includi SEMPRE entrambe per supportare sia release sia debug builds in caso di sideload.

Errori comuni e come risolverli

• SHA-256 sbagliato: usa quello di Play App Signing per release.
• assetlinks.json non accessibile: verifica con curl, no redirect.
• autoVerify mancante: senza, il link si apre con chooser.
• Cache: usa Domain Verification API per forzare il refresh.
• Test in debug: la verifica funziona solo con keystore firmato release.

Domande frequenti

D: Posso avere App Links e Deep Links insieme?
R: Si, configurando schemi diversi e gestendoli nello stesso intent-filter.

D: Funzionano da WhatsApp e altre app?
R: Si, sempre più app rispettano gli App Links verificati.

D: Cosa cambia con Android 12+?
R: Verifica più rigorosa; le app non verificate mostrano sempre il chooser.

D: I link aprono sempre l'app se installata?
R: Da Android 12+ solo se autoVerify e la verifica e riuscita. Altrimenti l'utente sceglie.

Best practice operative

Mantieni assetlinks.json come parte della documentazione del progetto. Versione il file in git accanto al codice. Test ogni release con adb. Monitor link analytics per individuare cali di apertura (potenziali break). Coordina con marketing su campagne che usano deep link per garantire copertura.

Quando un link e troppo lungo o complesso per essere condiviso facilmente, considera servizi shortener custom (es. yourapp.link) che mantengono deep linking. Branch.io e Bitly Enterprise offrono custom domain con deep linking integrato. URL corti aumentano conversion in scenari social e offline.

Hai bisogno di aiuto?

Se vuoi sviluppare la tua app con G Tech Group, scrivici tramite il modulo di contatto.