App Links de Android sin verificar: diagnóstico en cinco minutos con adb

La app está instalada. El enlace abre Chrome igualmente.

Suele aparecer como un ticket de soporte, no como un error. Alguien toca un enlace a tu dominio, la app está en su teléfono, y se abre Chrome. Desde Android 12, según la documentación de Android, un enlace https solo abre tu app si el sistema verificó tu dominio al instalar — y cuando esa verificación falla, falla en silencio. Sin crash, sin aviso, nada en tus paneles.

Dos propiedades lo hacen difícil de depurar. La verificación es por dominio: example.com puede estar verificado mientras promo.example.com no lo está. Y es por dispositivo: la misma build puede pasar en un Pixel y fallar en un Samsung, una combinación reportada repetidamente en los foros de desarrolladores de Samsung. Si estás en medio de un incidente, salta al diagnóstico.

Dos dominios, dos veredictos

Qué ocurre realmente al instalar

Al instalar o actualizar tu app, Android lee cada dominio declarado con autoVerify y descarga https://tudominio/.well-known/assetlinks.json para cada uno. Según la documentación de Android, el archivo debe responder con un 200 directo por HTTPS y content type application/json — el verificador no sigue redirecciones. El resultado se cachea por dominio; por eso un subdominio puede estar verificado y su hermano no.

Dentro del archivo, sha256_cert_fingerprints debe coincidir con el certificado que firmó el APK del dispositivo. El error número uno: con Play App Signing, ese certificado es la clave de firma de Google — no tu clave de subida. La huella de tu keystore local verifica perfectamente las builds instaladas a mano, y falla en cada instalación que vino de Play Store.

Una propiedad más: el veredicto se cachea. Corregir el JSON en el servidor no cambia nada en los teléfonos que ya fallaron hasta que la verificación vuelva a ejecutarse — algo que, por suerte, puedes forzar.

Conecta cualquier dispositivo Android 12+ con la app instalada y ejecuta esto en orden. La mayoría de incidentes se resuelven en el paso tres.

Si prefieres no revisar JSON a ojo durante un incidente, nuestra herramienta de validación de enlaces descarga tu assetlinks.json y comprueba código de estado, content type y formato de huellas en una sola pasada.

Los sospechosos habituales

Cinco causas cubren casi todos los reportes. Causa a la izquierda, arreglo a la derecha.

Qué cambiaron Android 15 y 16

Dos versiones recientes movieron el listón en la misma dirección: los App Links https verificados son el camino soportado, y todo lo demás se estrecha.

Dónde encaja honestamente un smart link

Un smart link enruta en el servidor, antes de que nada de esta maquinaria actúe: al abrir un enlace de Appy, la redirección lee el dispositivo y envía a visitantes Android, iOS y desktop a destinos distintos. Ese enrutamiento funciona en todos los planes y no depende de la verificación en el dispositivo, porque ocurre antes de que el sistema vea tu dominio.

Seamos claros con lo que no hace: un smart link no puede saltarse la verificación de App Links. La redirección termina en tu dominio https, y el mismo estado verified-o-none decide si se abre la app o el navegador. Lo que te da en medio del incidente es una puerta de entrada controlable — apunta el tráfico Android a la ficha de Play Store o a la web mientras reparas assetlinks.json, y luego devuelve el destino sin tocar nada impreso, porque los QR dinámicos siguen siendo editables después de imprimir. La analítica muestra cuánto tráfico Android pasó por la ruta rota.

Arregla la verificación de todos modos. Los destinos deeplink en Pro y el deferred deep linking en Enterprise son útiles, pero se apoyan en un assetlinks.json que funciona, no lo sustituyen.

Preguntas frecuentes