Cómo verificar Android App Links

Android App Link es un tipo especial de vínculo directo que permite que las URLs de tu sitio web abran de inmediato el contenido correspondiente en tu app para Android, sin que el usuario deba seleccionarla. Android App Links usa la API de Vínculos de recursos digitales para establecer la confianza de que el sitio web aprobó tu app para abrir automáticamente los vínculos de ese dominio. Si el sistema verifica correctamente que eres el propietario de las URLs, enruta automáticamente esos intents de URL a tu app.

Para verificar que eres el propietario de las URLs de la app y el sitio web, completa los siguientes pasos:

  1. Agrega filtros de intents que contengan el atributo autoVerify. Este atributo le indica al sistema que debe verificar si tu app pertenece a los dominios de URL que se usan en tus filtros de intents.

  2. Declara la asociación entre tu sitio web y tus filtros de intents. Para ello, aloja un archivo JSON de Vínculos de recursos digitales en la siguiente ubicación:

    https://domain.name/.well-known/assetlinks.json

Puedes encontrar información relacionada en los siguientes recursos:

Cómo agregar filtros de intents para la verificación de vínculos de apps

Si deseas habilitar la verificación de control de vínculos para tu app, agrega filtros de intents que coincidan con el siguiente formato:

<!-- Make sure you explicitly set android:autoVerify to "true". -->
<intent-filter android:autoVerify="true">
    <action android:name="android.intent.action.VIEW" />
    <category android:name="android.intent.category.DEFAULT" />
    <category android:name="android.intent.category.BROWSABLE" />

    <!-- If a user clicks on a shared link that uses the "http" scheme, your
         app should be able to delegate that traffic to "https". -->
    <data android:scheme="http" />
    <data android:scheme="https" />

    <!-- Include one or more domains that should be verified. -->
    <data android:host="..." />
</intent-filter>

Aunque es suficiente incluir autoVerify en una sola declaración <intent-filter> para cada host, incluso si ese host se usa en otras declaraciones sin marca, se recomienda agregar autoVerify a cada elemento <intent-filter> para mantener la coherencia. Esto también garantiza que, después de quitar o refactorizar elementos del archivo de manifiesto, la app permanezca asociada con todos los dominios que aún definas.

El proceso de verificación del dominio requiere una conexión a Internet y podría tardar un poco en completarse. Para ayudar a mejorar la eficiencia del proceso, el sistema verifica un dominio para una app que se orienta a Android 12 o versiones posteriores solo si ese dominio se encuentra dentro de un elemento <intent-filter> que contiene el formato exacto especificado en el fragmento de código anterior.

Cómo admitir vínculos de apps para varios hosts

El sistema debe poder verificar el host especificado en los elementos de datos de los filtros de intents de URL de la app con los archivos de Vínculos de recursos digitales alojados en los respectivos dominios web en ese filtro de intents. Si la verificación falla, el sistema establece de forma predeterminada su comportamiento estándar para resolver el intent, como se describe en Cómo crear vínculos directos al contenido de la app. Sin embargo, la app se puede verificar como un controlador predeterminado para cualquiera de los patrones de URL definidos en los otros filtros de intents de la app.

Nota: En Android 11 (nivel de API 30) y versiones anteriores, el sistema no verifica tu app como controlador predeterminado, a menos que encuentre un archivo de Vínculos de recursos digitales coincidente para todos los hosts que definas en el manifiesto.

Por ejemplo, una app con los siguientes filtros de intents aprobaría la verificación solo para https://www.example.com si se encontrara un archivo assetlinks.json en https://www.example.com/.well-known/assetlinks.json, pero no en https://www.example.net/.well-known/assetlinks.json:

<application>

  <activity android:name=”MainActivity”>
    <intent-filter android:autoVerify="true">
      <action android:name="android.intent.action.VIEW" />
      <category android:name="android.intent.category.DEFAULT" />
      <category android:name="android.intent.category.BROWSABLE" />
      <data android:scheme="http" />
      <data android:scheme="https" />
      <data android:host="www.example.com" />
    </intent-filter>
  </activity>
  <activity android:name=”SecondActivity”>
    <intent-filter>
      <action android:name="android.intent.action.VIEW" />
      <category android:name="android.intent.category.DEFAULT" />
      <category android:name="android.intent.category.BROWSABLE" />
      <data android:scheme="https" />
     <data android:host="www.example.net" />
    </intent-filter>
  </activity>

</application>

Nota: Se combinan todos los elementos <data> en el mismo filtro de intents para representar todas las variaciones de sus atributos combinados. Por ejemplo, el primer filtro de intents anterior incluye un elemento <data> que solo declara el esquema HTTPS. Sin embargo, se combina con el otro elemento <data> para que el filtro de intents sea compatible con http://www.example.com y https://www.example.com. Por lo tanto, debes crear filtros de intents separados cuando desees definir combinaciones específicas de dominios y esquemas de URI.

Cómo admitir vínculos de apps para varios subdominios

El protocolo de Vínculos de recursos digitales trata los subdominios de tus filtros de intents como hosts independientes y únicos. Por lo tanto, si tu filtro de intents enumera varios hosts con subdominios diferentes, debes publicar un assetlinks.json válido en cada dominio. Por ejemplo, el siguiente filtro de intents incluye www.example.com y mobile.example.com como hosts de URL de intents aceptados. Por lo tanto, un assetlinks.json válido debe publicarse en https://www.example.com/.well-known/assetlinks.json y https://mobile.example.com/.well-known/assetlinks.json.

<application>
  <activity android:name=”MainActivity”>
    <intent-filter android:autoVerify="true">
      <action android:name="android.intent.action.VIEW" />
      <category android:name="android.intent.category.DEFAULT" />
      <category android:name="android.intent.category.BROWSABLE" />
      <data android:scheme="https" />
      <data android:scheme="https" />
      <data android:host="www.example.com" />
      <data android:host="mobile.example.com" />
    </intent-filter>
  </activity>
</application>

Como alternativa, si declaras tu nombre de host con un comodín (como *.example.com), debes publicar el archivo assetlinks.json en el nombre de host raíz (example.com). Por ejemplo, una app con el siguiente filtro de intents pasará la verificación de cualquier subnombre de example.com (como foo.example.com) siempre que el archivo assetlinks.json esté publicado en https://example.com/.well-known/assetlinks.json:

<application>
  <activity android:name=”MainActivity”>
    <intent-filter android:autoVerify="true">
      <action android:name="android.intent.action.VIEW" />
      <category android:name="android.intent.category.DEFAULT" />
      <category android:name="android.intent.category.BROWSABLE" />
      <data android:scheme="https" />
      <data android:host="*.example.com" />
    </intent-filter>
  </activity>
</application>

Verifica si hay varias apps asociadas al mismo dominio

Si publicas varias apps asociadas con el mismo dominio, cada una puede verificarse de manera correcta. Sin embargo, si las apps pueden resolver exactamente el mismo host del dominio y la misma ruta de acceso, como puede suceder con las versiones básica y completa de una app, solo la última que se instaló puede resolver intents web para ese dominio.

En un caso como este, verifica si es posible que, en el dispositivo del usuario, existan apps en conflicto, siempre que cuentes con la visibilidad del paquete necesaria. Luego, en la app, muestra un diálogo personalizado del selector que incluya los resultados de las llamadas a queryIntentActivities(). El usuario puede seleccionar su app preferida de la lista de apps que coinciden y aparecen en el diálogo.

.

Cómo declarar la asociación de sitios web

Debes publicar un archivo JSON de Vínculos de recursos digitales en tu sitio web para indicar las apps para Android que están asociadas con el sitio web y verificar los intents de URL de la app. El archivo JSON usa los siguientes campos para identificar aplicaciones asociadas:

  • package_name: Es el ID de aplicación declarado en el archivo build.gradle de la app.
  • sha256_cert_fingerprints: Son las huellas digitales SHA256 del certificado de firma de tu app. Puedes usar el siguiente comando para generar la huella digital mediante la herramienta Keytool de Java:
    keytool -list -v -keystore my-release-key.keystore
    
    Este campo admite varias huellas digitales, que pueden usarse para brindar compatibilidad con diferentes versiones de tu app, como depuración y compilaciones de producción.

    Si usas la firma de apps de Play para tu app, por lo general, la huella digital del certificado que se produce cuando ejecutas keytool de forma local, no coincide con la de los dispositivos de los usuarios. Puedes verificar si usas la firma de apps de Play para tu app en tu cuenta de desarrollador de Play Console en Release > Setup > App signing. Si lo haces, también encontrarás el fragmento JSON de Vínculos de recursos digitales correcto para tu app en la misma página.

En el siguiente archivo assetlinks.json de ejemplo, se otorgan derechos de apertura de vínculos a una app para Android com.example:

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
}]

Cómo asociar un sitio web a varias apps

Un sitio web puede declarar asociaciones con varias apps dentro del mismo archivo assetlinks.json. En la siguiente lista de archivos, se muestra un ejemplo de un archivo de instrucción que declara asociación con dos apps por separado, y se encuentra en https://www.example.com/.well-known/assetlinks.json:

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.puppies.app",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
  },
  {
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.example.monkeys.app",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
}]

Distintas apps pueden manejar los vínculos para recursos diferentes en el mismo host web. Por ejemplo, la app1 puede declarar un filtro de intents para https://example.com/articles y la app2 puede declarar un filtro de intents para https://example.com/videos.

Nota: Varias apps asociadas a un dominio pueden firmarse con el mismo o con diferentes certificados.

Cómo asociar varios sitios web a una sola app

Varios sitios web pueden declarar asociaciones con la misma app en sus respectivos archivos assetlinks.json. En las siguientes listas de archivos, se muestra un ejemplo de cómo declarar la asociación de example.com y example.net con app1. La primera ficha muestra la asociación de example.com con la app1:

https://www.example.com/.well-known/assetlinks.json

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.mycompany.app1",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
}]

En la siguiente lista, se muestra la asociación de example.net con la app1. Solo la ubicación donde se alojan estos archivos es diferente (.com y .net):

https://www.example.net/.well-known/assetlinks.json

[{
  "relation": ["delegate_permission/common.handle_all_urls"],
  "target": {
    "namespace": "android_app",
    "package_name": "com.mycompany.app1",
    "sha256_cert_fingerprints":
    ["14:6D:E9:83:C5:73:06:50:D8:EE:B9:95:2F:34:FC:64:16:A0:83:42:E6:1D:BE:A8:8A:04:96:B2:3F:CF:44:E5"]
  }
}]

Publicación del archivo de verificación JSON

Debes publicar tu archivo de verificación JSON en la siguiente ubicación:

https://domain.name/.well-known/assetlinks.json

Asegúrate de lo siguiente:

  • El archivo assetlinks.json se publica con el tipo de contenido application/json.
  • Se debe poder acceder al archivo assetlinks.json con una conexión HTTPS, independientemente de si los filtros de intents de la app declaran HTTPS como el esquema de datos.
  • Se debe poder acceder al archivo assetlinks.json sin redireccionamientos (sin redireccionamientos 301 o 302).
  • Si los vínculos de tu app admiten varios dominios de host, debes publicar el archivo assetlinks.json en cada dominio. Consulta Cómo admitir vínculos de apps para varios hosts.
  • No publiques tu app con URLs de desarrollo y prueba en el archivo de manifiesto al que podría no acceder el público (como los que solo pueden acceder con una VPN). En esos casos, una solución es configurar variantes de compilación para generar un archivo de manifiesto diferente para las compilaciones de desarrollo.

Verificación de Android App Links

Cuando android:autoVerify="true" está presente en al menos uno de los filtros de intents de tu app, instalarla en un dispositivo que ejecute Android 6.0 (nivel de API 23) o una versión posterior hace que el sistema verifique automáticamente los hosts asociados con las URLs en los filtros de intents de tu app. En Android 12 y versiones posteriores, también puedes invocar el proceso de verificación de forma manual para probar la lógica de verificación.

Verificación automática

La verificación automática del sistema implica lo siguiente:

  1. El sistema inspecciona todos los filtros de intents que incluyen cualquiera de los siguientes elementos:
    • Acción: android.intent.action.VIEW
    • Categorías: android.intent.category.BROWSABLE y android.intent.category.DEFAULT
    • Esquema de datos: http o https
  2. Por cada nombre de host único que se encuentra en los filtros de intents anteriores, Android consulta los sitios web correspondientes para el archivo de Vínculos de recursos digitales en https://hostname/.well-known/assetlinks.json.

Una vez que confirmes la lista de sitios web asociados con tu app y confirmes que el archivo JSON alojado es válido, instala la app en tu dispositivo. Espera al menos 20 segundos para que se complete el proceso de verificación asíncrono. Usa el siguiente comando para comprobar si el sistema verificó tu app y configura las políticas de control de vínculos correctas:

adb shell am start -a android.intent.action.VIEW \
    -c android.intent.category.BROWSABLE \
    -d "http://domain.name:optional_port"

Verificación manual

A partir de Android 12, puedes invocar de forma manual la verificación del dominio para una app instalada en un dispositivo. Puedes realizar este proceso independientemente de si tu app se orienta a Android 12.

Establece una conexión a Internet

Para realizar la verificación del dominio, el dispositivo de prueba debe estar conectado a Internet.

Admite el proceso actualizado de verificación del dominio

Si tu app se orienta a Android 12 o versiones posteriores, el sistema usa automáticamente el proceso de verificación del dominio actualizado.

De lo contrario, puedes habilitarlo de forma manual. Para ello, ejecuta el siguiente comando en una ventana de la terminal:

adb shell am compat enable 175408749 PACKAGE_NAME

Restablece el estado de Android App Links en un dispositivo

Antes de invocar de forma manual la verificación del dominio en un dispositivo, debes restablecer el estado de Android App Links en el dispositivo de prueba. Para ello, ejecuta el siguiente comando en una ventana de la terminal:

adb shell pm set-app-links --package PACKAGE_NAME 0 all

Este comando coloca el dispositivo en el mismo estado en el que se encuentra antes de que el usuario elija las apps predeterminadas para cualquier dominio.

Invoca el proceso de verificación del dominio

Después de restablecer el estado de Android App Links en un dispositivo, puedes realizar la verificación en sí. Para ello, ejecuta el siguiente comando en una ventana de la terminal:

adb shell pm verify-app-links --re-verify PACKAGE_NAME

Consulta los resultados de verificación

Después de esperar un poco para que el agente de verificación finalice sus solicitudes, consulta los resultados. Para ello, ejecuta el siguiente comando:

adb shell pm get-app-links PACKAGE_NAME

El resultado de este comando es similar al siguiente:

com.example.pkg:
    ID: 01234567-89ab-cdef-0123-456789abcdef
    Signatures: [***]
    Domain verification state:
      example.com: verified
      sub.example.com: legacy_failure
      example.net: verified
      example.org: 1026

Los dominios que aprueban la verificación de manera correcta tienen un estado de verificación del dominio de verified. Cualquier otro estado indica que no se pudo realizar esta verificación. En particular, el estado de none indica que es posible que el agente de verificación todavía no completó el proceso.

En la siguiente lista, se mencionan los posibles valores que puede mostrar la verificación para un dominio determinado:

none
No se registró nada para este dominio. Espera unos minutos más para que el agente de verificación termine las solicitudes relacionadas con la verificación del dominio. Luego, vuelve a invocar el proceso.
verified
Se verificó, de manera correcta, el dominio para la app que lo declara.
approved
El dominio se aprobó de manera forzosa, por lo general, mediante la ejecución de un comando de shell.
denied
El dominio se rechazó de manera forzosa, por lo general, mediante la ejecución de un comando de shell.
migrated
El sistema conserva el resultado de un proceso anterior que usó la verificación heredada del dominio.
restored
Se aprobó el dominio después de que el usuario restableció los datos. Se supone que el dominio se verificó con anterioridad.
legacy_failure
Un verificador heredado rechazó el dominio. Se desconoce el motivo específico de la falla.
system_configured
La configuración del dispositivo aprobó el dominio automáticamente.
Código de error de 1024 o superior

Es un código de error personalizado y específico del verificador del dispositivo.

Vuelve a verificar si estableciste una conexión de red y vuelve a invocar el proceso de verificación del dominio.

Solicítale al usuario que asocie la app con un dominio

Otra manera de obtener la aprobación de la app para un dominio es solicitarle al usuario que la asocie con ese dominio.

Verifica si ya se aprobó la app para el dominio

Antes de solicitarle al usuario que realice una acción, verifica si la app es el controlador predeterminado para los dominios que defines en los elementos <intent-filter>. Puedes consultar el estado de aprobación mediante uno de los siguientes métodos:

DomainVerificationManager

En el siguiente fragmento de código, se muestra cómo usar la API de DomainVerificationManager:

Kotlin

val context: Context = TODO("Your activity or fragment's Context")
val manager = context.getSystemService(DomainVerificationManager::class.java)
val userState = manager.getDomainVerificationUserState(context.packageName)

// Domains that have passed Android App Links verification.
val verifiedDomains = userState?.hostToStateMap
    ?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_VERIFIED }

// Domains that haven't passed Android App Links verification but that the user
// has associated with an app.
val selectedDomains = userState?.hostToStateMap
    ?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_SELECTED }

// All other domains.
val unapprovedDomains = userState?.hostToStateMap
    ?.filterValues { it == DomainVerificationUserState.DOMAIN_STATE_NONE }

Java

Context context = TODO("Your activity or fragment's Context");
DomainVerificationManager manager =
        context.getSystemService(DomainVerificationManager.class);
DomainVerificationUserState userState =
        manager.getDomainVerificationUserState(context.getPackageName());

Map<String, Integer> hostToStateMap = userState.getHostToStateMap();
List<String> verifiedDomains = new ArrayList<>();
List<String> selectedDomains = new ArrayList<>();
List<String> unapprovedDomains = new ArrayList<>();
for (String key : hostToStateMap.keySet()) {
    Integer stateValue = hostToStateMap.get(key);
    if (stateValue == DomainVerificationUserState.DOMAIN_STATE_VERIFIED) {
        // Domain has passed Android App Links verification.
        verifiedDomains.add(key);
    } else if (stateValue == DomainVerificationUserState.DOMAIN_STATE_SELECTED) {
        // Domain hasn't passed Android App Links verification, but the user has
        // associated it with an app.
        selectedDomains.add(key);
    } else {
        // All other domains.
        unapprovedDomains.add(key);
    }
}

Programa de línea de comandos

Cuando pruebes la app durante el desarrollo, puedes ejecutar el siguiente comando para consultar el estado de verificación de los dominios que posee la organización:

adb shell pm get-app-links --user cur PACKAGE_NAME

En el siguiente resultado de ejemplo, a pesar de que la app no aprobó la verificación del dominio "example.org", el usuario 0 aprobó de forma manual la app en la configuración del sistema, y no se verificó ningún otro paquete para ese dominio.

com.example.pkg:
ID: ***
Signatures: [***]
Domain verification state:
  example.com: verified
  example.net: verified
  example.org: 1026
User 0:
  Verification link handling allowed: true
  Selection state:
    Enabled:
      example.org
    Disabled:
      example.com
      example.net

También puedes usar comandos de shell para simular el proceso en el que el usuario selecciona qué app está asociada con un dominio determinado. Puedes encontrar una explicación completa de estos comandos en el resultado de adb shell pm.

Brinda contexto para la solicitud

Antes de realizar esta solicitud para aprobar el dominio, bríndale contexto al usuario. Por ejemplo, puedes mostrarle una pantalla de presentación, un diálogo o un elemento de la IU similar que le explique al usuario por qué la app debería ser el controlador predeterminado para un dominio particular.

Realiza la solicitud

Una vez que el usuario comprenda lo que la app le solicita que haga, realiza la solicitud. Para hacerlo, invoca un intent que incluya la acción de intent ACTION_APP_OPEN_BY_DEFAULT_SETTINGS y una string de datos que coincida con package:com.example.pkg para la app de destino, como se muestra en el siguiente fragmento de código:

Kotlin

val context: Context = TODO("Your activity or fragment's Context")
val intent = Intent(Settings.ACTION_APP_OPEN_BY_DEFAULT_SETTINGS,
    Uri.parse("package:${context.packageName}"))
context.startActivity(intent)

Java

Context context = TODO("Your activity or fragment's Context");
Intent intent = new Intent(Settings.ACTION_APP_OPEN_BY_DEFAULT_SETTINGS,
    Uri.parse("package:" + context.getPackageName()));
context.startActivity(intent);

Cuando se invoca el intent, los usuarios ven la pantalla de configuración Abrir de forma predeterminada. En esta pantalla, se muestra el botón de selección Abrir vínculos admitidos, como se muestra en la figura 1.

Cuando el usuario activa Abrir vínculos admitidos, aparece un conjunto de casillas de verificación en la sección Vínculos que se abren en esta app. Desde aquí, los usuarios pueden seleccionar los dominios que quieren asociar con la app. También pueden seleccionar Agregar vínculo para agregar dominios, como se muestra en la Figura 2. Después, cuando los usuarios seleccionen cualquier vínculo dentro de los dominios que agreguen, este se abrirá automáticamente en la app.

Cuando el botón de selección está habilitado, una sección cerca de la parte inferior incluye casillas y el botón &quot;Agregar vínculo&quot;.
Figura 1: Pantalla de configuración del sistema, en la que los usuarios pueden elegir qué vínculos se abren en la app de forma predeterminada.
Cada casilla representa un dominio que puedes agregar. Los botones del diálogo son &quot;Cancelar&quot; y &quot;Agregar&quot;.
Figura 2: Diálogo en el que los usuarios pueden elegir dominios adicionales para asociarlos con la app.

Abre dominios de la app que no se pueden verificar

Es posible que la función principal de la app sea abrir vínculos como un tercero, sin la capacidad de verificar sus dominios controlados. Si este es el caso, explícales a los usuarios que, en el momento en que seleccionen un vínculo web, no podrán elegir entre una app propia y tu app (de terceros). Los usuarios deben asociar de forma manual los dominios con la app de terceros.

Además, considera introducir un diálogo o una actividad de trampolín que le permita al usuario abrir el vínculo en la app propia si prefiere hacerlo, como un proxy. Antes de configurar un diálogo o una actividad de trampolín, configura la app para que tenga visibilidad del paquete en las apps propias que coincidan con el filtro de intents web de tu app.

Cómo probar vínculos de apps

Cuando implementas la función de vinculación de apps, debes probar la funcionalidad de vinculación para asegurarte de que el sistema pueda asociar tu app con tus sitios web y manejar las solicitudes de URL, como esperas.

Para probar un archivo de instrucciones existente, puedes usar la herramienta Generador y verificador de listas de instrucciones.

Cómo confirmar la lista de hosts que se deben verificar

Durante la prueba, debes confirmar la lista de hosts asociados que el sistema debe verificar para tu app. Haz una lista de todas las URLs cuyos filtros de intents correspondientes incluyan los siguientes atributos y elementos:

  • Atributo android:scheme con un valor de http o https
  • Atributo android:host con un patrón de URL de dominio
  • Elemento de acción android.intent.action.VIEW
  • Elemento de categoría android.intent.category.BROWSABLE

Usa esta lista para verificar que se proporcione un archivo JSON de Vínculos de recursos digitales en cada host y subdominio nombrado.

Cómo confirmar los archivos de Vínculos de recursos digitales

En cada sitio web, usa la API de Vínculos de recursos digitales para confirmar que el archivo JSON de Vínculos de recursos digitales se encuentre alojado y definido correctamente:

https://digitalassetlinks.googleapis.com/v1/statements:list?
   source.web.site=https://domain.name:optional_port&
   relation=delegate_permission/common.handle_all_urls

Como parte de tu proceso de prueba, puedes comprobar la configuración actual del sistema para el control de vínculos. Usa el siguiente comando para obtener una lista de las políticas de control de vínculos existentes para todas las apps en tu dispositivo conectado:

adb shell dumpsys package domain-preferred-apps

Lo siguiente hace lo mismo:

adb shell dumpsys package d

Nota: Asegúrate de esperar al menos 20 segundos luego de instalar tu app para permitir que el sistema complete el proceso de verificación.

El comando muestra una lista de cada usuario o perfil definidos en el dispositivo, precedido por un encabezado en el siguiente formato:

App linkages for user 0:

Luego de este encabezado, el resultado usa el siguiente formato para enumerar las configuraciones de control de vínculos para ese usuario:

Package: com.android.vending
Domains: play.google.com market.android.com
Status: always : 200000002

Este listado indica qué aplicaciones están asociadas con qué dominios para ese usuario:

  • Package: Identifica una app por el nombre de su paquete, como se declara en su manifiesto.
  • Domains: Muestra la lista completa de hosts cuyos vínculos web maneja esta app, con espacios en blanco como delimitadores.
  • Status: Muestra la configuración actual de control de vínculos para esta app. Una app que pasó la verificación y cuyo manifiesto contiene android:autoVerify="true" muestra un estado de always. El número hexadecimal que le sigue a ese estado está relacionado con el registro de las preferencias del usuario para la vinculación de apps del sistema Android. Este valor no indica si la verificación se realizó correctamente.

Nota: Si un usuario cambia la configuración de vínculos de apps antes de que se complete la verificación, es posible que veas un falso positivo de una verificación exitosa, aunque esta haya fallado. Sin embargo, esta falla en la verificación no importa si el usuario habilitó explícitamente la app para abrir vínculos compatibles sin preguntar. Esto se debe a que las preferencias del usuario tienen prioridad sobre la verificación programática (o la ausencia de esta). Como resultado, el vínculo va directamente a tu app, sin mostrar un diálogo, como si la verificación se hubiera realizado correctamente.

Ejemplo de comprobación

Para que la verificación de vínculos de apps se realice correctamente, el sistema debe poder verificar tu app con cada uno de los sitios web que especifiques en un filtro de intents determinado que cumpla con los criterios para los vínculos de apps. En el siguiente ejemplo, se muestra la configuración de un manifiesto con varios vínculos de apps definidos:

<application>

    <activity android:name=”MainActivity”>
        <intent-filter android:autoVerify="true">
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.DEFAULT" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:scheme="https" />
            <data android:scheme="https" />
            <data android:host="www.example.com" />
            <data android:host="mobile.example.com" />
        </intent-filter>
        <intent-filter>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:scheme="https" />
            <data android:host="www.example2.com" />
        </intent-filter>
    </activity>

    <activity android:name=”SecondActivity”>
        <intent-filter>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.DEFAULT" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:scheme="https" />
            <data android:host="account.example.com" />
        </intent-filter>
    </activity>

      <activity android:name=”ThirdActivity”>
        <intent-filter>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.DEFAULT" />
            <data android:scheme="https" />
            <data android:host="map.example.com" />
        </intent-filter>
        <intent-filter>
            <action android:name="android.intent.action.VIEW" />
            <category android:name="android.intent.category.BROWSABLE" />
            <data android:scheme="market" />
            <data android:host="example.com" />
        </intent-filter>
      </activity>

</application>

La siguiente es la lista de hosts que la plataforma intentaría verificar a partir del manifiesto anterior:

www.example.com
mobile.example.com
www.example2.com
account.example.com

La siguiente es la lista de hosts que la plataforma no intentaría verificar a partir el manifiesto anterior:

map.example.com (it does not have android.intent.category.BROWSABLE)
market://example.com (it does not have either an "http" or "https" scheme)

Para obtener más información sobre las listas de instrucciones, consulta Cómo crear una lista de instrucciones.

Cómo corregir errores comunes de implementación

Si no puedes verificar tus Android App Links, busca los siguientes errores comunes. En esta sección, se usa example.com como un nombre de dominio de marcador de posición. Cuando realices estas verificaciones, sustituye example.com por el nombre de dominio real de tu servidor.

Configuración incorrecta del filtro de intents
Verifica si incluyes una URL que no es propiedad de tu app en un elemento <intent-filter>.
Configuración del servidor incorrecta

Verifica la configuración JSON de tu servidor y asegúrate de que el valor de SHA sea correcto.

Además, verifica que example.com. (con el punto final) entregue el mismo contenido que example.com.

Redireccionamientos del servidor

El sistema no verifica ningún vínculo de app de Android para tu app si configuras un redireccionamiento como el siguiente:

  • http://example.com a https://example.com
  • example.com a www.example.com

Este comportamiento protege la seguridad de tu app.

Solidez del servidor

Verifica si tu servidor puede conectarse a las apps cliente.

Vínculos que no se pueden verificar

Para realizar pruebas, puedes agregar intencionalmente vínculos que no se puedan verificar. Ten en cuenta que, en Android 11 y versiones anteriores, estos vínculos hacen que el sistema no verifique todos los Android App Links de tu app.

Firma incorrecta en assetlinks.json

Verifica que tu firma sea correcta y coincida con la que usaste para firmar tu app. Entre los errores comunes, se incluyen los siguientes:

  • Firma de la app con un certificado de depuración y solo tener la firma de lanzamiento en assetlinks.json
  • Tener una firma en minúscula en assetlinks.json La firma debe estar en mayúsculas.
  • Si usas la firma de apps de Play, asegúrate de usar la firma que utiliza Google para firmar cada una de tus versiones. Para verificar estos detalles, incluido un fragmento JSON completo, sigue las instrucciones sobre cómo declarar asociaciones de sitios web.