App Links Android non verificati: diagnosi in cinque minuti con adb

L’app è installata. Il link apre comunque Chrome.

Di solito emerge come ticket di supporto, non come errore. Qualcuno tocca un link al tuo dominio, l’app è lì sul telefono, e si apre Chrome. Da Android 12, secondo la documentazione Android, un link https apre la tua app solo se il sistema ha verificato il dominio all’installazione — e quando quella verifica fallisce, fallisce in silenzio. Nessun crash, nessun avviso, niente nei tuoi pannelli.

Due proprietà rendono il debug faticoso. La verifica è per dominio: example.com può risultare verificato mentre promo.example.com no. Ed è per dispositivo: la stessa build può passare su un Pixel e fallire su un Samsung, una combinazione segnalata più volte nei forum sviluppatori Samsung. Se sei nel mezzo di un incidente, salta direttamente alla diagnosi.

Due domini, due verdetti

Cosa succede davvero all’installazione

All’installazione o all’aggiornamento, Android legge ogni dominio dichiarato con autoVerify e scarica https://tuodominio/.well-known/assetlinks.json per ciascuno. Secondo la documentazione Android, il file deve rispondere con un 200 diretto via HTTPS e content type application/json — il verificatore non segue i redirect. Il risultato viene messo in cache per dominio; per questo un sottodominio può essere verificato e il suo gemello no.

Nel file, sha256_cert_fingerprints deve corrispondere al certificato che ha firmato l’APK sul dispositivo. Il tranello numero uno: con Play App Signing quel certificato è la chiave di firma di Google — non la tua chiave di upload. L’impronta del keystore locale verifica benissimo le build installate a mano, e fallisce su ogni installazione arrivata dal Play Store.

Un’altra proprietà da conoscere: il verdetto è in cache. Correggere il JSON sul server non cambia nulla sui telefoni già in errore finché la verifica non gira di nuovo — cosa che, per fortuna, puoi forzare.

Collega un qualsiasi dispositivo Android 12+ con l’app installata ed esegui questi comandi in ordine. La maggior parte degli incidenti si risolve al passo tre.

Se preferisci non rileggere JSON a occhio durante un incidente, il nostro strumento di validazione link scarica il tuo assetlinks.json e controlla codice di stato, content type e formato delle impronte in un solo passaggio.

I soliti sospetti

Cinque cause coprono quasi tutte le segnalazioni. Causa a sinistra, rimedio a destra.

Cosa hanno cambiato Android 15 e 16

Due release recenti hanno spostato l’asticella nella stessa direzione: gli App Links https verificati sono la strada supportata, e tutto il resto si restringe.

Dove uno smart link sta onestamente

Uno smart link instrada sul server, prima che questa macchina entri in gioco: all’apertura di un link Appy, il redirect legge il dispositivo e manda visitatori Android, iOS e desktop verso destinazioni diverse. Quel routing funziona su ogni piano e non dipende dalla verifica sul dispositivo, perché avviene prima che l’OS veda il tuo dominio.

Chiarezza su cosa non fa: uno smart link non può aggirare la verifica degli App Links. Il redirect termina sul tuo dominio https, e lo stesso stato verified-o-none decide se si apre l’app o il browser. Ciò che ti dà durante l’incidente è una porta d’ingresso controllabile — punta il traffico Android alla scheda Play Store o al web mentre ripari assetlinks.json, poi riporta la destinazione com’era senza toccare nulla di stampato, perché i QR dinamici restano modificabili dopo la stampa. Le analytics mostrano quanto traffico Android è passato dal percorso rotto.

In ogni caso, sistema la verifica. Le destinazioni deeplink su Pro e il deferred deep linking su Enterprise sono utili, ma poggiano su un assetlinks.json funzionante — non lo sostituiscono.

Domande frequenti