App Links de Android sin verificar: diagnóstico en cinco minutos con adb
Desde Android 12, un App Link que falla la verificación de dominio se abre en el navegador en lugar de tu app — en silencio y no en todos los dispositivos. Esta es la lista adb que encuentra la causa rápido, incluido el desajuste de la clave de firma de Play detrás de la mayoría de estos incidentes.
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.
El diagnóstico de cinco minutos
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.
Lee el estado de verificación
adb shell pm get-app-links com.example.appImprime cada dominio declarado con su estado. verified significa que el handshake pasó; none, que el verificador nunca aprobó el dominio — ese es el que envía usuarios a Chrome. En dispositivos multiusuario, revisa también la sección por usuario al final.
Descarga assetlinks.json como lo hace el verificador
curl -sI https://example.com/.well-known/assetlinks.jsonQuieres un 200 directo. Cualquier 301 o 302 hace fallar la verificación, porque según la documentación de Android el verificador no sigue redirecciones. Confirma que content-type sea application/json, luego descarga el cuerpo y lee el package name y las huellas con tus propios ojos. Una protección anti-bots delante de /.well-known/ también cuenta como fallo.
Compara la huella con la clave de firma de Play
Play Console → App integrity → App signing key certificateAbre esa página de Play Console y pon el SHA-256 junto a tu JSON. Deben coincidir byte a byte. Si tu archivo lleva la huella de la clave de subida, encontraste el bug — añade la huella de la clave de firma de Play, y conserva ambas si también distribuyes builds fuera de Play Store.
Fuerza una nueva verificación
adb shell pm verify-app-links --re-verify com.example.appTras corregir el servidor, dile al dispositivo que lo intente de nuevo. El verificador es asíncrono: espera unos segundos, repite el paso uno y observa si none pasa a verified. En algunos Samsung el estado no se mueve hasta reiniciar — un patrón reportado en los foros de desarrolladores de Samsung.
Lanza el intent como un toque real
adb shell am start -a android.intent.action.VIEW -d "https://example.com/promo"Es la prueba de extremo a extremo. En un dominio verificado la app se abre directamente, sin selector. Si aparece el navegador o una hoja de desambiguación, el estado aún no cambió — revisa el paso uno antes de asumir que tu arreglo falló.
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.
El JSON lleva la huella de la clave de subida, no la de firma de Play
Copia el SHA-256 desde Play Console → App integrity → App signing key certificate. Conserva ambas huellas si también distribuyes builds firmadas con la clave de subida.
assetlinks.json responde con redirección o 404
Sirve el archivo directamente en /.well-known/assetlinks.json en cada host declarado. Para el verificador, www y el dominio raíz son dos dominios distintos.
Content type incorrecto, como text/html o text/plain
Configura el servidor o CDN para enviar application/json en esa ruta. Un JSON válido con la cabecera equivocada sigue fallando.
Varios flavors o package names, uno falta en el archivo
El archivo es un array: una declaración por package name, cada una con sus huellas. Un flavor ausente falla solo en ese flavor, lo que parece aleatorio en QA.
Un Samsung sigue en none tras corregir el JSON
La verificación retrasada en algunos modelos Samsung es un tema recurrente en sus foros de desarrolladores. Fuerza la re-verificación y reinicia el dispositivo antes de concluir otra cosa.
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.
Añadió Dynamic App Links, según las notas de la versión: las asociaciones de dominio pueden actualizarse sin publicar un nuevo APK, acortando el ciclo entre corregir tu JSON y que los dispositivos lo adopten.
Endureció la verificación de esquemas URI personalizados, según las notas de la versión. Si parte de tu flujo aún depende de esquemas myapp://, trátalos como legado y mueve esas entradas a enlaces https verificados.
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
¿Por qué el mismo enlace funciona en un dispositivo y no en otro?
La verificación se ejecuta en cada dispositivo al instalar, así que cada teléfono guarda su propio veredicto. Un fallo de red durante la instalación, un verificador OEM distinto — Samsung es el caso más reportado en sus foros de desarrolladores — o una instalación anterior a tu corrección del JSON producen estados distintos para la misma build.
¿Necesito publicar una actualización de la app?
Normalmente no. Si el manifest ya declara el dominio con autoVerify, el fallo está en el JSON o en la huella, ambos del lado del servidor. Corrige el archivo, fuerza la re-verificación y la build instalada empieza a abrir enlaces. Solo necesitas actualizar si el dominio nunca se declaró.
¿Un smart link se salta la verificación?
No, y desconfía de quien afirme lo contrario. La redirección elige el destino en el servidor, pero al aterrizar en tu dominio https, el sistema aplica el mismo estado de verificación de siempre. Un smart link cambia qué puedes hacer mientras está rota — enrutar a tienda o web — no si está rota.
¿Cuánto tarda la verificación en reintentarse sola?
Según la documentación de Android, el verificador reintenta dominios fallidos y vuelve a ejecutarse al actualizar la app, pero el calendario no está garantizado y varía por OEM. En la práctica: de horas a días. Forzar la re-verificación por adb o reinstalar la app es más rápido que esperar.
Seguir explorando
El plan gratis de AppsFlyer acaba de encogerse: qué pasó a ser de pago y cuáles son tus opciones
El deferred deep linking, los dominios de marca, Smart Banners, los enlaces masivos y la API salieron del plan gratuito Zero. Qué cambió, cuánto cuesta reemplazarlo y una migración que cabe en una tarde.
Reenvío de parámetros para deeplinks, Universal Links, tiendas de apps y web
Aprende a conservar parámetros de campaña y contexto en la app, las tiendas, Universal Links y destinos web sin sobrescribir valores fijos.
Deferred deep linking: cómo funciona y cuándo usarlo
Conserva la intención original del enlace tras la instalación para que los nuevos usuarios aterricen en la pantalla correcta y no en la home por defecto.
¿Buscas otra cosa? Explora todos los temas en el blog.
Dale al tráfico Android un sitio donde aterrizar
Crea un smart link que detecta el dispositivo en el servidor y enruta a los visitantes Android a la app, la tienda o la web — y cambia el destino después sin reimprimir un solo código QR.
Crear un smart link gratis