Agrega filtros de intents para vínculos de apps

Los App Links son vínculos directos que usan el esquema HTTP o HTTPS y que Android verifica como asociados a tu sitio web. Para registrarte y controlar los vínculos de apps, sigue estos pasos:

  1. Agrega uno o más filtros de intents al manifiesto de tu app que especifiquen el dominio o las URLs de tu sitio web.
  2. Agrega el autoVerify="true"attribute a los elementos del filtro de intents. Esto indica al sistema que debe intentar verificar el esquema y los dominios de host con la configuración de assetlinks.json de tu sitio web.
  3. Declara asociaciones con sitios web.

A continuación, se muestra un ejemplo de una declaración de vínculo de aplicación con esquemas y hosts, así como autoVerify="true":

<activity
    android:name=".MainActivity"
    android:exported="true"
    ...>
    <!-- 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 link that uses the "http" scheme, your
             app should be able to delegate that traffic to "https". -->
        <!-- Do not include other schemes, as this will prevent verification. -->
        <data android:scheme="http" />
        <data android:scheme="https" />

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

Puntos clave sobre el código

  • AutoVerify: El atributo android:autoVerify="true" es obligatorio para los vínculos de apps. Le indica al sistema que debe intentar verificar la asociación entre tu app y los esquemas y dominios especificados en las etiquetas <data>. Se recomienda agregar autoVerify="true" a cada filtro de intents que quieras que se pueda verificar.
  • Elementos de datos: Cada filtro de intents de App Links debe incluir uno o más elementos <data> que especifiquen los esquemas y los formatos de host que coincidan con tu dominio de sitio web verificable.
  • Esquemas: El filtro de intents debe incluir elementos <data> para los esquemas http y https.
  • Hosts: De manera opcional, puedes agregar elementos <data> para que coincidan con uno o más hosts. Usa un comodín (*) para que coincida con varios subdominios (como *.example.com). El sistema intentará verificar cada host con el archivo assetlinks.json de tu sitio web. Ten en cuenta que cualquier enrutamiento a nivel de ruta de acceso debe controlarse con el archivo assetlinks.json (consulta la sección de prácticas recomendadas que aparece más abajo).

  • Varios dominios alojados: Si declaras varios dominios de host, el sistema (en Android 12 y versiones posteriores) intentará verificar cada uno. Si se verifica algún host, la app se convierte en el controlador predeterminado de los vínculos de ese host verificado. En Android 11 y versiones anteriores, la verificación falla si no se puede verificar ni siquiera un host.

  • Varios filtros de intents: Es importante crear filtros separados cuando tu intención es declarar URLs únicas (como una combinación específica de esquema y host), ya que varios elementos <data> en el mismo filtro de intents se combinan para tener en cuenta todas las variaciones de sus atributos combinados.

Consideraciones para las reglas de filtro de manifiestos

Si configuras filtros para usarlos con App Links dinámicos en Android 15 y versiones posteriores, es importante recordar que las reglas dinámicas declaradas en el archivo assetlinks.json del servidor no pueden expandir el alcance de las reglas de URL que declaras de forma estática en el manifiesto de la app.

Por este motivo, te recomendamos que uses este enfoque:

  • En el manifiesto de la app, establece el alcance más amplio posible, por ejemplo, declarando solo el esquema y el dominio.
  • Confía en las reglas de assetlinks.json del servidor para un mayor refinamiento, como el enrutamiento a nivel de la ruta de acceso.

Con esta configuración ideal, podrás agregar de forma dinámica nuevas rutas de acceso de vínculos de apps en el archivo assetlinks.json según sea necesario, sabiendo que se ajustarán al amplio alcance que estableciste en el manifiesto de la app.

Cómo admitir vínculos de aplicación 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 dominios web respectivos de ese filtro de intents. Si la verificación falla, el sistema recurre a 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.

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>

Admite la vinculación de apps para varios subdominios

El protocolo de Vínculos de recursos digitales trata los subdominios de tus filtros de intents como hosts únicos y separados. Por lo tanto, si tu filtro de intents incluye varios hosts con diferentes subdominios, debes publicar un archivo 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 URLs de intents aceptados. Por lo tanto, se debe publicar un assetlinks.json válido 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 tu 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 para cualquier subnombre de example.com (como foo.example.com) siempre que el archivo assetlinks.json se publique 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 con el 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 hay posibles apps en conflicto en el dispositivo del usuario, siempre que tengas la visibilidad del paquete necesaria. Luego, en tu app, muestra un diálogo de selección personalizado que contenga los resultados de la llamada a queryIntentActivities. El usuario puede seleccionar su app preferida de la lista de apps coincidentes que aparecen en el diálogo.

.

Las funciones de Dynamic App Link, incluidas las reglas de coincidencia avanzadas en assetlinks.json y el uso de <uri-relative-filter-group>, solo son totalmente compatibles con Android 15 (nivel de API 35) y versiones posteriores.

En Android 14 (nivel de API 34) y versiones anteriores, el sistema solo tiene en cuenta los elementos scheme y host declarados en los elementos <data> del manifiesto para la verificación de vínculos de apps. No se aplican las reglas específicas de la ruta de acceso, las exclusiones ni las actualizaciones dinámicas de assetlinks.json.

Esto significa que, si tu manifiesto solo especifica scheme y host, es posible que tu app capture de forma inesperada todas las rutas de acceso del dominio verificado en Android 14 y versiones anteriores, independientemente de las reglas específicas de la ruta de acceso definidas en tu assetlinks.json para Android 15 y versiones posteriores.

Para evitar que tu app controle todos los vínculos de un dominio en Android 14 y versiones anteriores cuando quieras usar App Links dinámicos para rutas de acceso más específicas en Android 15 y versiones posteriores, incluye una ruta de acceso que no coincida en el filtro de intents de tu manifiesto. Agrega un elemento <data> con un atributo android:path que sea poco probable que sea una ruta de acceso válida para tus vínculos. Esto garantiza que el filtro de intents no coincida con todas las rutas de acceso en las versiones anteriores.

Ejemplo:

<activity
    android:name=".MainActivity"
    android:exported="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" />

        <data android:scheme="http" />
        <data android:scheme="https" />
        <data android:host="www.example.com" />

        <!-- Add a non-matching path for backward compatibility -->
        <data android:path="/no_match_for_older_android_versions" />

        <uri-relative-filter-group android:allow="true">
          <data android:pathPattern="/.*"/>
        </uri-relative-filter-group>
    </intent-filter>
</activity>

Si agregas <data android:path="/no_match_for_older_android_versions" />, te aseguras de que, en Android 14 y versiones anteriores, este filtro de intents no coincida con ningún vínculo entrante, a la vez que permites que el dominio se verifique para usarlo con vínculos dinámicos a apps en Android 15 y versiones posteriores según las reglas de coincidencia avanzadas de tus reglas de assetlinks.json.

Si ya tienes App Links con reglas de ruta de acceso específicas (como android:pathPrefix) en tu manifiesto y quieres comenzar a usar App Links dinámicos en Android 15 y versiones posteriores, puedes agregar el elemento <uri-relative-filter-group> directamente a tus filtros de intents existentes de forma segura.

Como Android 14 y versiones anteriores ignoran el elemento <uri-relative-filter-group>, tus App Links existentes seguirán funcionando exactamente como lo hacen ahora en dispositivos que ejecutan versiones anteriores de Android.

Sin embargo, debes considerar cuidadosamente cómo Android 15 y versiones posteriores evalúan la configuración "mixta":

  • Filtrado de dos capas: En Android 15 y versiones posteriores, el sistema evalúa los filtros de intents como una unión. Una URL pasa la verificación del manifiesto si cumple con tus etiquetas <data> estáticas heredadas o con las reglas generales de tu <uri-relative-filter-group>. Una vez que la URL pasa esta verificación inicial del manifiesto, el sistema aplica las reglas dinámicas definidas en tu archivo assetlinks.json como una segunda capa de filtrado detallado. Esto significa que las reglas JSON del servidor, en última instancia, dictan cuáles de esas URLs coincidentes abren la app.

Ejemplo de una configuración híbrida:

<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="www.example.com" />

    <!-- Legacy rule: Android 14 and lower use this. Android 15 and higher
         also use this. -->
    <data android:pathPrefix="/store" />

    <!--
      Dynamic rule: Android 14 and lower ignore this. Android 15 and higher
      evaluate this as a union between all paths and the configuration
      specified in the assetlinks.json file. Make sure to apply further
      refinements in the assetlinks.json file to prevent all URL paths from
      opening in the app.
    -->
    <uri-relative-filter-group android:allow="true">
        <data android:pathPrefix="/" />
    </uri-relative-filter-group>
</intent-filter>