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 con tu sitio web. Para registrarte y controlar los App Links, 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 le indica al sistema que debe intentar verificar el esquema y los dominios de host en comparación con la configuración assetlinks.json de tu sitio web.
3. Declara asociaciones de sitios web.

A continuación, se muestra un ejemplo de una declaración de App Link 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 App Links. Le indica al sistema que debe intentar verificar la asociación entre tu app y los esquemas y dominios especificados en las <data> etiquetas. Te recomendamos que agregues 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 <data> elementos 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 en comparación con tu archivo assetlinks.json en tu sitio web. Ten en cuenta que el archivo assetlinks.json debe controlar cualquier enrutamiento a nivel de la ruta de acceso (consulta la sección de prácticas recomendadas más adelante).

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

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

Precaución: Si varias actividades contienen filtros de intents que se resuelven en el mismo App Link verificado, no hay garantía de qué actividad controla el vínculo.

Consideraciones para las reglas de filtro de manifiesto

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 tu app, establece el alcance más amplio posible, por ejemplo, declarando solo el esquema y el dominio.
• Confía en las reglas 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 App Links 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 App Links 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 en comparación con los archivos de Vínculos de recursos digitales alojados en los dominios web respectivos en ese filtro de intents. Luego, el sistema adopta su comportamiento estándar de forma predeterminada para resolver el intent, como se describe en Cómo crear vínculos directos al contenido de la app. Sin embargo, la app aún 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 un 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 pasarí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 fusionan 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 <data> elemento 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 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 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 tu assetlinks.json archivo en la raíz nombre de host (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 se publique el archivo assetlinks.json 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>

Cómo verificar 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 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.

Nota: Considera almacenar la ruta de acceso que coincide; de ese modo, el usuario no tendrá que volver a seleccionarla si un intent web similar se inicia más adelante.

Compatibilidad con versiones anteriores de App Links dinámicos para Android 14 y versiones anteriores

Las funciones de App Links dinámicos, 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 considera el scheme y host declarados en los elementos <data> de tu manifiesto para la verificación de App Link. No se aplican las reglas, las exclusiones ni las actualizaciones dinámicas específicas de la ruta de acceso 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 para el 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.

Estrategia de resguardo para versiones anteriores de Android que se configurarán sin vínculos directos

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 probablemente nunca 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 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, al mismo tiempo que permites que se verifique el dominio para usarlo con App Links dinámicos en Android 15 y versiones posteriores según las reglas de coincidencia avanzadas en tus reglas assetlinks.json.

Advertencia: Si configuras <uri-relative-filter-group> en tu manifiesto para Android 15 y versiones posteriores, asegúrate de que se pueda acceder a un archivo assetlinks.json válido en el host especificado. Si falta el archivo assetlinks.json o no es válido, falla la verificación de App Links en Android 15 y versiones posteriores, y tu app no controla ningún vínculo para ese dominio. En otros casos, en los que el archivo assetlinks.json es válido, pero falta la configuración dinámica, es posible que la app se abra para todas las rutas de acceso en Android 15 y versiones posteriores según la declaración estática del manifiesto.

Cómo migrar App Links existentes

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 de forma segura el <uri-relative-filter-group> elemento directamente a tus filtros de intents existentes.

Debido a que Android 14 y versiones anteriores ignoran el <uri-relative-filter-group> elemento, 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 satisface tus etiquetas <data> estáticas heredadas o las reglas amplias en 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 determinan, en última instancia, 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>