Un Android App Link es un tipo especial de vínculo directo que permite que las URLs de tu sitio web abran inmediatamente el contenido correspondiente en tu app para Android, sin requerir que el usuario seleccione la app. Android App Links usa la API de Digital Asset Links para establecer la confianza de que el sitio web aprobó tu app para abrir automáticamente vínculos de ese dominio. Si el sistema verifica con éxito que posees las URLs, automáticamente enruta esos intents de URL a tu app.
Para verificar que eres propietario de la app y las URLs del sitio web, completa los siguientes pasos:
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.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
Para 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". -->
<!-- Do not include other schemes. -->
<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 no marcadas, 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 en el archivo de manifiesto, la app siga 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 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 está dentro de un elemento <intent-filter> que contiene el formato exacto especificado en el fragmento de código anterior.
Por ejemplo, los esquemas que no sean "http" ni "https", como <data android:scheme="custom" />, impedirán que un <intent-filter> active la verificación de dominio.
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 en comparación con los archivos de Vínculos de recursos digitales alojados en los dominios web respectivos en ese filtro de intents. Si la verificación falla, 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 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 Digital Asset Links 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: Todos los elementos <data> en el mismo filtro de intents se combinan 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 a 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 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 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.
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 archivobuild.gradlede 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 dactilar mediante la herramienta keytool de Java:keytool -list -v -keystore my-release-key.keystore
Este campo admite varias huellas dactilares, que pueden usarse para brindar compatibilidad con diferentes versiones de tu app, como depuración y compilación de producción.Si usas la firma de apps de Play para tu app, por lo general, la huella dactilar del certificado que produce la ejecución de
keytoolde 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 la cuenta de desarrollador de Play Console enRelease > Setup > App signing. Si es así, 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 ejemplo, el archivo assetlinks.json otorga 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 reside 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 para declarar la asociación de example.com y example.net con app1. En la primera lista, se 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:
- Se publica el archivo
assetlinks.jsoncon el tipo de contenidoapplication/json. - Se debe poder acceder al archivo
assetlinks.jsonmediante 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.jsonsin redireccionamientos (sin redireccionamientos 301 o 302). - Si los vínculos de tu app admiten varios dominios de host, debes publicar el archivo
assetlinks.jsonen cada dominio. Consulta Cómo admitir la vinculación de apps para varios hosts. - No publiques tu app con URLs de desarrollo y prueba en el archivo de manifiesto que podría no estar disponible para el público (como los archivos que solo están disponibles 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, instalar tu app en un dispositivo que ejecuta Android 6.0 (nivel de API 23) o versiones posteriores 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:
- 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.BROWSABLEyandroid.intent.category.DEFAULT - Esquema de datos:
httpohttps
- Acción:
- 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 que hayas confirmado 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 la app se orienta a Android 12 o versiones posteriores, el sistema usará automáticamente el proceso actualizado de verificación del dominio.
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
1024o 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:
- La API de
DomainVerificationManager(en el tiempo de ejecución). - Un programa de línea de comandos (durante las pruebas).
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 incluye el botón de selección Abrir vínculos admitidos, como se muestra en la figura 1.
Cuando el usuario activa Open supported links, aparece un conjunto de casillas de verificación debajo de una sección llamada Links to open in this app. Desde aquí, los usuarios pueden seleccionar los dominios que desean asociar con tu app. También pueden seleccionar Add link 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.
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 implementes 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, tal como lo esperas.
Para probar un archivo de instrucciones existente, puedes usar la herramienta Generador y comprobador de listas de instrucciones.
Cómo confirmar la lista de hosts que se deben verificar
Cuando se realiza 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 incluyen los siguientes atributos y elementos:
- Atributo
android:schemecon un valor dehttpohttps - Atributo
android:hostcon 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 comprobar 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
Para cada sitio web, usa la API de Digital Asset Links para confirmar que el archivo JSON de Digital Asset Links 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
Comprueba las políticas de vínculos
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 políticas de control de vínculos existentes para todas las apps de 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 después de instalar tu app para permitir que el sistema complete el proceso de verificación.
El comando muestra un listado 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 encuentra declarado en su manifiesto.Domains: Muestra la lista completa de hosts cuyos vínculos web maneja esta app; utiliza espacios en blanco como delimitadores.Status: Muestra la configuración actual de control de vínculos para esta app. Una app que aprobó la verificación, y cuyo manifiesto contieneandroid:autoVerify="true", muestra un estado dealways. El número hexadecimal que le sigue a ese estado está relacionado con el registro de las preferencias de usuario para la vinculación de apps del sistema Android. Este valor no indica si la verificación tuvo éxito.
Nota: Si un usuario cambia la configuración de vínculos de aplicaciones para una aplicación antes de que se complete la verificación, es posible que veas un falso positivo de una verificación exitosa, aunque esta falle. Sin embargo, esta falla en la verificación no es relevante si el usuario habilita explícitamente la app para abrir vínculos compatibles sin preguntar. Esto se debe a que las preferencias del usuario tienen prioridad ante la verificación programática (o la ausencia de esta). Como resultado, el vínculo dirige de forma directa a tu app, sin mostrar un diálogo, como si la verificación hubiese tenido éxito.
Ejemplo de comprobación
Para que tenga éxito la verificación de vínculos de aplicaciones, el sistema debe poder verificar tu aplicación 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 aplicaciones. 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 vínculos de apps para Android, verifica los siguientes errores comunes. En esta sección, se usa example.com como nombre de dominio de marcador de posición. Cuando realices estas verificaciones, reemplaza 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 de tu app en un elemento
<intent-filter>. - Configuración incorrecta del servidor
Verifica la configuración JSON de tu servidor y asegúrate de que el valor SHA sea correcto.
Además, verifica que
example.com.(con el punto final) publique el mismo contenido queexample.com.- Redireccionamientos del servidor
El sistema no verifica ningún Android App Links para tu app si configuras un redireccionamiento como el siguiente:
- De
http://example.comahttps://example.com - De
example.comawww.example.com
Este comportamiento protege la seguridad de tu app.
- De
- Robustez del servidor
Verifica si tu servidor puede conectarse a tus apps de cliente.
- Vínculos no verificables
Para fines de prueba, puedes agregar intencionalmente vínculos no verificables. Ten en cuenta que, en Android 11 y versiones anteriores, estos vínculos hacen que el sistema no verifique todos los vínculos de Android App Links de tu app.
- Firma incorrecta en assetlinks.json
Verifica que tu firma sea correcta y coincida con la que se usó para firmar tu app. Entre los errores comunes, se incluyen los siguientes:
- Firmar la app con un certificado de depuración y tener solo la firma de lanzamiento en
assetlinks.json - Tener una firma en minúsculas en
assetlinks.jsonLa firma debe estar en mayúsculas. - Si usas la firma de apps de Play, asegúrate de usar la firma que usa Google para firmar cada una de tus versiones. Para verificar estos detalles, incluido un fragmento JSON completo, sigue las instrucciones para declarar asociaciones de sitios web.
- Firmar la app con un certificado de depuración y tener solo la firma de lanzamiento en