SafetyNet vs Play Integrity API: cómo superarla con root (2026)

La API SafetyNet que la comunidad del root en Android conoció durante una década fue retirada formalmente por Google a principios de 2024 y sustituida por Play Integrity API. Todas las guías escritas antes de 2024 están desfasadas y en hilos antiguos de foros persiste mucha desinformación. Esta guía es el recorrido práctico y actual de 2026: qué cambió, qué significan realmente los tres veredictos de Play Integrity, qué herramientas de bypass funcionan en 2026 y las instrucciones paso a paso, con los comandos concretos de Magisk. Está dirigida a usuarios avanzados que ya tienen un dispositivo con root y necesitan que funcionen las apps bancarias y de pago.

Breve historia: de SafetyNet a Play Integrity

SafetyNet (2014-2024) era la API de atestación de dispositivos de Google. Devolvía dos campos booleanos: ctsProfileMatch (¿coincide este dispositivo con un perfil conocido del Compatibility Test Suite?) y basicIntegrity (¿supera este dispositivo comprobaciones básicas de integridad, como el estado de bootloader bloqueado?). Las apps bancarias la llamaban a través de Google Play Services, obtenían los dos booleanos y se negaban a funcionar si cualquiera era falso. Los métodos de bypass evolucionaron durante la década: primero MagiskHide, luego Zygisk + DenyList cuando MagiskHide se retiró en Magisk 24, y después Shamiko encima para ocultar mejor.

Play Integrity API (2023 hasta hoy) es el sustituto oficial. La cronología de la retirada:

• Junio de 2023: Play Integrity API se lanza como sustituto recomendado
• De mediados de 2023 a principios de 2024: las apps empiezan a migrar de SafetyNet a Play Integrity
• Enero de 2024: SafetyNet queda oficialmente obsoleta; las nuevas respuestas de la API ya no están garantizadas
• A mediados de 2026: casi todas las grandes apps bancarias y de pago usan ya solo Play Integrity

Play Integrity devuelve tres veredictos en lugar de dos booleanos y usa atestación de claves por hardware para el nivel más estricto, lo que la hace fundamentalmente más difícil de saltar con métodos solo de software.

Los tres veredictos de Play Integrity explicados

Cada comprobación de Play Integrity devuelve tres valores booleanos:

MEETS_DEVICE_INTEGRITY

El nivel base. Significa que el dispositivo ejecuta Android sin modificar, tiene Google Play Services instalado y supera las comprobaciones básicas de compatibilidad. Se puede saltar en dispositivos con root con las herramientas actuales (Magisk + Zygisk + DenyList + Shamiko + módulo Play Integrity Fix). Alrededor del 60 % de las apps exigen este veredicto para funcionar con normalidad.

MEETS_BASIC_INTEGRITY

Una comprobación más estricta que incluye alguna validación adicional del entorno: integridad de los archivos del sistema, estado esperado de Google Play Services, ciertas comprobaciones del estado de depuración. Casi siempre se puede saltar en dispositivos con root, pero es más sensible a la configuración de los módulos. Alrededor del 30 % de las apps exigen este veredicto además de DEVICE_INTEGRITY. La mayoría de las apps bancarias exigen ambos.

MEETS_STRONG_INTEGRITY

El nivel más difícil. Usa atestación de claves respaldada por hardware: el TEE (Trusted Execution Environment) del dispositivo firma una respuesta que se puede verificar hasta el certificado raíz del fabricante del dispositivo. Esto funciona incluso con el bootloader bloqueado porque las claves están protegidas por el elemento seguro. Los métodos de software actuales no pueden saltarlo en un dispositivo con el bootloader desbloqueado porque el desbloqueo rompe la cadena de arranque verificado en la que se apoyan las claves del TEE.

Entre el 10 y el 20 % de las apps exigen STRONG_INTEGRITY:

• Pago sin contacto de Google Wallet en algunas regiones
• Varios neobancos (Revolut, Wise, N26 en algunas regiones)
• Ciertas apps de identificación oficial (pasaportes digitales, carné de votante)
• Apps sanitarias con requisitos estrictos de cumplimiento normativo
• Algunas apps de trabajo protegidas por MDM y facilitadas por la empresa

Si tus apps imprescindibles exigen STRONG_INTEGRITY, el root es incompatible con ellas y ninguna solución actual lo cambia.

Herramientas de bypass: Magisk Hide vs Shamiko vs TrickyStore

Tres herramientas principales se combinan para saltarse Play Integrity en 2026 en dispositivos con root:

Paso a paso: supera Play Integrity en apps bancarias básicas

Se da por hecho que ya tienes:

• Bootloader desbloqueado
• Magisk instalado mediante un boot.img parcheado
• Root verificado y funcionando en Magisk Manager

Si todavía no tienes eso, consulta antes nuestra guía para desbloquear el bootloader y Magisk vs KernelSU vs APatch.

Paso 1: activa Zygisk en Magisk

Abre la app Magisk → Ajustes (icono de engranaje) → activa el interruptor Zygisk. Reinicia.

Tras reiniciar, vuelve a los ajustes de Magisk y activa Enforce DenyList.

Paso 2: instala Shamiko

Descarga el último zip de Shamiko de las versiones oficiales de LSPosed/LSPosed en GitHub. En la app Magisk → pestaña Módulos → toca el icono + → busca el zip de Shamiko → instala. Reinicia.

Tras reiniciar, comprueba que Shamiko está cargado: app Magisk → pestaña Módulos → Shamiko debería aparecer en la lista y estar activado.

Paso 3: instala el módulo Play Integrity Fix

Descarga el último zip de PIF de las versiones de GitHub de chiteroman/PlayIntegrityFork (o del fork que se mantenga en ese momento; consulta los hilos de Recognized Developers de XDA para ver las recomendaciones actuales).

App Magisk → Módulos → + → instala el zip de PIF → reinicia.

Paso 4: actualiza el fingerprint de PIF a uno que pase ahora

El fingerprint de PIF debe coincidir con el de un dispositivo conocido que pase Play Integrity en este momento. El módulo PIF incluye un script de actualización automática. Abre una app de terminal (Termux sirve) y ejecuta:

su -c sh /data/adb/modules/playintegrityfix/action.sh

Esto descarga el último fingerprint válido mantenido por la comunidad y lo aplica. Reinicia.

Paso 5: configura DenyList para tus apps

App Magisk → Configurar DenyList → busca cada app bancaria, de pago o que compruebe Play Integrity que necesites usar. Toca el interruptor junto a cada app para activar el ocultamiento. Las entradas de subprocesos suelen activarse automáticamente.

Apps habituales que conviene añadir:

• Tu app bancaria principal (HDFC, SBI, Bank of America, Lloyds, etc.)
• Apps de dinero móvil (bKash, GCash, M-Pesa, JazzCash)
• Apps de pago (Google Pay, PayPal, Venmo, Cash App)
• Apps de inversión (Robinhood, Zerodha, Groww)
• Apps gubernamentales (DigiLocker, Aadhaar, app del NHS)
• Apps de streaming con DRM (Netflix, Disney+, Amazon Prime: comprueban Play Integrity para HD/4K)

Paso 6: verifica con Play Integrity API Checker

Instala Play Integrity API Checker desde Play Store (hay varias versiones; prueba la de gkkang o la que mantiene el equipo de LSPosed).

Ábrela. Toca Check. Fíjate en:

• MEETS_DEVICE_INTEGRITY: debería ser true
• MEETS_BASIC_INTEGRITY: debería ser true
• MEETS_STRONG_INTEGRITY: será false en un dispositivo con el bootloader desbloqueado, es lo esperado

Si DEVICE y BASIC devuelven true, el bypass funciona a nivel de veredicto. La mayoría de las apps bancarias y de pago funcionarán ya con normalidad.

Paso 7: prueba cada app bancaria por separado

Abre cada app una por una. Confirma que pasa de la pantalla de inicio y te deja iniciar sesión. Si alguna falla:

1. Confirma que la app está activada en DenyList
2. Vuelve a ejecutar el comando de actualización automática de PIF para renovar el fingerprint
3. Reiniciar
4. Si sigue fallando, es posible que esa app use detección adicional además de Play Integrity: prueba TrickyStore como capa extra o acepta que la app es incompatible con tu configuración de root actual

Cuando las apps siguen fallando aunque el veredicto pase

Algunas apps usan vectores de detección adicionales además de la API oficial de Play Integrity:

• Análisis directo de archivos: buscan /system/bin/su, rutas de binarios de Magisk o rutas de instalación de módulos conocidos. Solución: activa el ocultamiento de archivos equivalente a MagiskHide de Magisk (integrado en las versiones recientes).
• Inspección del espacio de nombres de procesos: comprueban /proc/self/status y similares en busca de firmas de hooks de Zygisk. Solución: Shamiko cubre la mayoría de los casos.
• Desafíos de atestación del TEE independientes de Play Integrity. Solución: TrickyStore en algunas apps; imposible en otras.
• Listas de bloqueo propias de la app que mantiene el desarrollador e incluyen nombres de paquete conocidos relacionados con el root. Solución: cambia el nombre de la app Magisk en Ajustes → Ocultar la app de Magisk, con un nombre que no parezca de Magisk.

Estado de las apps bancarias por región: qué funciona hoy en Android con root

El comportamiento de las apps bancarias varía muchísimo según la región, porque cada banco elige su propio nivel de exigencia en la comprobación de integridad. Según los informes de clientes de los mercados BD/IN/PK/UK a lo largo de 2026:

Bangladesh

• bKash: funciona con Magisk + Shamiko + PIF para la mayoría de los usuarios; a veces hay que actualizar el fingerprint tras las actualizaciones de Google
• Nagad: funciona con la misma combinación; algo más sensible a lo reciente que sea el fingerprint
• Rocket (DBBL): funciona con la combinación estándar
• Apps de City Bank, BRAC Bank, EBL y Dutch-Bangla Bank: la mayoría funcionan con la combinación estándar; compruébalas tras cada actualización de Play Integrity
• Pago sin contacto específico de cada banco: por lo general exige STRONG_INTEGRITY; no se puede saltar en dispositivos con root

India

• Google Pay (Tez): UPI funciona con la combinación estándar; el pago sin contacto (en las regiones compatibles) exige STRONG_INTEGRITY
• PhonePe, Paytm: UPI funciona con la combinación estándar
• HDFC, ICICI, SBI YONO, Axis Mobile: la mayoría funcionan; HDFC y Axis son algo más estrictas y pueden necesitar TrickyStore para ciertas funciones
• Apps de inversión (Zerodha Kite, Groww, Upstox): funcionan con la combinación estándar
• App mAadhaar de Aadhaar: funciona en la mayoría de las funciones; las funciones biométricas pueden requerir una configuración de ocultamiento adicional

Pakistán

• JazzCash, Easypaisa: ambas funcionan con la combinación estándar para la mayoría de los usuarios
• HBL Mobile, UBL Digital, Meezan Bank Mobile: la mayoría funcionan; Meezan es la más estricta de las tres
• NayaPay, SadaPay (neobanco): variable; compruébalo antes de fiarte del root para estas

Reino Unido y UE

• La mayoría de las apps de bancos tradicionales (Lloyds, Barclays, HSBC, Santander, NatWest): funcionan con la combinación estándar a mediados de 2026
• Neobancos (Revolut, Wise, N26, Monzo): Revolut y Wise son conocidos por ser muy estrictos y con frecuencia exigen STRONG_INTEGRITY en algunos flujos; Monzo y Starling suelen ser más tolerantes
• Equivalentes de pago sin contacto de Apple/Google: exigen STRONG_INTEGRITY; no se pueden saltar

Esta lista refleja la situación en el momento de escribir y cambia con regularidad. Prueba siempre tus apps concretas antes de fiarte del root para un uso financiero urgente.

Qué implica realmente STRONG_INTEGRITY a nivel de TEE

Contexto técnico rápido para usuarios avanzados sobre por qué STRONG_INTEGRITY no se puede saltar en dispositivos con el bootloader desbloqueado.

Los dispositivos Android modernos incluyen un Trusted Execution Environment (TEE): un procesador seguro independiente, con su propia memoria y su propio sistema operativo, aislado del Android principal. El TEE guarda claves criptográficas únicas de cada dispositivo, aprovisionadas en fábrica y firmadas por la autoridad de certificación raíz del fabricante.

Cuando una app solicita STRONG_INTEGRITY, la solicitud pasa por el TEE, que firma una respuesta con esas claves aprovisionadas en fábrica. La respuesta incluye el estado actual del arranque verificado: una cadena de hashes que demuestra que el bootloader está bloqueado y que las particiones boot, system y vendor coinciden con lo que el fabricante ha firmado.

Al desbloquear el bootloader, el TEE actualiza su estado de arranque verificado a «yellow» (claves instaladas por el usuario) o «orange» (sin arranque verificado). El TEE seguirá firmando las respuestas de STRONG_INTEGRITY, pero la respuesta incluirá de forma explícita el estado de desbloqueo. Las apps que exigen STRONG_INTEGRITY comprueban ese campo y se niegan a funcionar cuando el estado es distinto de «green» (bootloader bloqueado, cadena de arranque firmada por el fabricante).

Un bypass por software no puede falsificar esto porque el TEE firma con claves a las que el Android principal no tiene acceso. TrickyStore puede interceptar la llamada al keystore antes de que llegue al TEE y sustituirla por una respuesta «buena» grabada de un dispositivo similar, lo que funciona con algunas apps que no validan bien el origen en hardware de la respuesta; pero las apps que sí lo validan (las estrictas) detectarán la sustitución.

Las únicas formas fiables de pasar STRONG_INTEGRITY:

• Usar un boot.img de firmware original con el bootloader bloqueado de nuevo. Algunos dispositivos (Pixel, ciertos OnePlus) permiten volver a bloquear el bootloader tras flashear imágenes firmadas por el fabricante. Esto restaura STRONG_INTEGRITY, pero pierdes el root.
• Usar un dispositivo secundario sin root para las pocas apps que exigen STRONG_INTEGRITY.

No existe una tercera opción oculta. El diseño del TEE está pensado precisamente para impedirlo.

Lo que nunca recomendamos

• Ejecutar varios módulos de bypass de Play Integrity a la vez sin un motivo concreto: suelen entrar en conflicto y rompen más apps de las que arreglan.
• Usar forks de PIF aleatorios de fuentes desconocidas. Ciñete al fork principal que se mantiene y consulta los hilos de XDA para ver la recomendación actual.
• Fiarte del bypass para transacciones financieras de alto valor. Usa un dispositivo de reserva sin root para importes que no puedas permitirte perder, y lee las condiciones de servicio de tu banco sobre la responsabilidad por fraude en dispositivos con root.
• Activar el root para la propia Play Store. Play Store no necesita estar en DenyList; hacerlo puede romper funciones de Play Store sin ningún beneficio.

Cuándo recurrir a un profesional

Si una app bancaria concreta se niega a funcionar tras instalar el root y has probado la combinación estándar, escríbenos por WhatsApp o Telegram. Tenemos configuraciones revisadas y probadas para la mayoría de los grandes bancos de los mercados de BD, IN, PK, UK, EE. UU. y la UE, y normalmente podemos dejar una app funcionando en una sesión remota de 30 a 60 minutos. Consulta nuestro servicio de root para Android para ver qué incluye.

Para los detalles a nivel de módulo de DenyList y Shamiko, nuestra guía de módulos de Magisk cubre la combinación actual para ocultar el root a Play Integrity y qué forks se siguen manteniendo.