Respuesta corta: sí, Google Play permite live updates de code interpretado. Puedes enviar nuevo JavaScript, HTML y CSS a una app de Android sin pasar por una nueva revisión de la Play Store. No puedes descargar code nativo como dex, JAR o .so archivos.
Google es más claro que Apple en esto: la excepción para JavaScript en un WebView está escrita directamente en la política. Esta página la cita, muestra dónde está el límite y explica cómo Google la aplica.
Esto no es asesoría legal. Es la interpretación actual de la política y cómo miles de apps la usan en producción.
Lo que realmente dice la política de Google Play
La regla está en la política de abuso de dispositivos y redes:
Una app distribuida vía Google Play no puede modificarse, reemplazarse o actualizarse mediante ningún método que no sea el mecanismo de actualización de Google Play. Asimismo, una app no puede descargar code ejecutable (como archivos dex, JAR, .so) de una fuente distinta a Google Play. Esta restricción no aplica a code que se ejecute en una máquina virtual o intérprete que proporcione acceso indirecto a las APIs de Android (como JavaScript en un webview o navegador).
Y justo después:
Las apps o code de terceros, como SDKs, con lenguajes interpretados (JavaScript, Python, Lua, etc.) cargados en tiempo de ejecución (por ejemplo, no empaquetados con la app) no deben permitir violaciones potenciales de las políticas de Google Play.
Así que hay dos reglas:
- El code nativo solo viene de Google Play. Nada de descargar dex, JAR o librerías nativas.
- El code interpretado puede venir de cualquier lugar, pero lo que haga debe cumplir con cada política de Play.
La capa web de una app Capacitor es JavaScript, HTML y CSS ejecutándose en el Android WebView, el ejemplo exacto que da Google. Esto entra en la exención.
Dónde está el límite
| Permitido con live update | No permitido con live update |
|---|---|
| Bug fixes en tu JavaScript, HTML, CSS | Descargar dex, JAR, APK o .so archivos |
| Cambios de UI, copy o nuevas pantallas en tu stack web actual | Reemplazar la app fuera del mecanismo de actualización de Google Play |
| A/B tests y rollouts graduales de web code | Enviar code que infrinja la política de Play (comportamiento engañoso, malware, contenido prohibido) |
| Actualizar imágenes, traducciones o config | Convertir la app en algo que la ficha no describe |
| Hacer un rollback de un release fallido | Bypasear permisos o seguridad de Android |
Capgo solo envía la columna izquierda. Cualquier cambio nativo, como un nuevo plugin Capacitor, un nuevo permiso en AndroidManifest.xml, o una dependencia de Gradle, sigue requiriendo una nueva versión en Google Play. La de Capgo segmentación de versiones mantiene los bundles que requieren nuevo code nativo alejados de binarios antiguos.
Cómo lo aplica Google
Google escanea apps buscando code ejecutables descargados o comportamientos que cambien tras la instalación. Los checks automáticos buscan la carga de dex o librerías nativas fuera del APK. El JavaScript en un WebView no los activa.
El riesgo real es la segunda regla: si un live update hace que la app haga algo prohibido por la política de Play, es una infracción sin importar cómo llegó el code. La política de comportamiento engañoso también aplica a apps cuya función cambia tras la revisión.
En la práctica:
- Usa live updates para fixes e iteraciones sobre la app que ya publicaste.
- Mantén la app coherente con tu ficha de Play Store y el formulario de seguridad de datos.
- Lanza cambios nativos y grandes lanzamientos a través de Google Play, con rollouts escalonados si prefieres que sean graduales.
¿Qué stacks pueden hacerlo en Android?
Que tu app pueda publicar actualizaciones over-the-air en Android depende de una pregunta: ¿la lógica de tu app se interpreta en runtime? JavaScript y otros code interpretados, sí. Archivos dex, JAR y nativos descargados, .so no. Los frameworks compilados con AOT, como Flutter, solo pueden hacerlo mediante una VM o un intérprete.
Compatibilidad de live update en Android según el stack
| Stack | Cómo se ejecuta el code en Android | ¿Se permiten live updates? | Herramientas |
|---|---|---|---|
| Capacitor | JavaScript, HTML y CSS en el WebView de Android | Sí | Capgo |
| Ionic (en Capacitor) | Igual que Capacitor | Sí | Capgo |
| Cordova | JavaScript en el WebView de Android | Sí | Capgo tras migrar a Capacitor, plugins de Cordova antiguos |
| React Native / Expo | bundle de JavaScript en Hermes | Sí, solo JavaScript | Expo Updates, alternativas self-hosted a CodePush |
| NativeScript | JavaScript en V8 | Sí, solo JavaScript | Limitado, mayormente desarrollado internamente |
| Flutter | Dart compilado AOT en una librería nativa | Solo mediante VM o intérprete | Shorebird |
| Kotlin / Java nativos | bytecode dex en ART | No para code nativo; sí para JavaScript en WebView | Configuración remota, Play Feature Delivery |
| Kotlin / Compose Multiplatform | bytecode dex en ART | No | Configuración remota, Play Feature Delivery |
| .NET MAUI / Xamarin | runtime de .NET y librerías nativas incluidas en el APK | No | Solo config. remota |
| Unity / Unreal | C# vía IL2CPP o C++, compilado | No para code, sí para contenido | Asset bundles, Play Asset Delivery, contenido con scripts (Lua) |
| Web wrapper / TWA | Sitio web cargado en WebView o Chrome | Siempre en vivo | Ninguna necesaria |
Capacitor, Ionic y Cordova: cobertura total
Tu UI y lógica de negocio es JavaScript ejecutándose en el Android WebView, el ejemplo exacto que la política de Google da para code permitido. Un live update reemplaza el bundle web; el APK, los plugins nativos y los permisos siguen siendo los que publicaste.
Capgo cumple por diseño porque solo puede modificar la capa web. Los nuevos plugins nativos o permisos en AndroidManifest.xml y cambios en dependencias de Gradle requieren una nueva versión en Google Play.
React Native y Expo: JS sí, módulos nativos no
React Native ejecuta un bundle de JavaScript en Hermes, lo que cuenta como code interpretado. Expo Updates y el ya retirado Microsoft CodePush actualizan ese bundle. Los equipos que dejan CodePush necesitan un reemplazo. Los módulos nativos y las actualizaciones de React Native requieren un nuevo release.
Flutter: solo mediante una VM o intérprete
Flutter compila Dart ahead-of-time en libapp.so. Descargar un nuevo .so está explícitamente prohibido, por lo que el Flutter estándar no puede usar live updates. Shorebird añade push de code y afirma que cumple con la política de Play al ejecutar actualizaciones mediante la máquina virtual de Dart. Lee más en live updates para apps de Flutter.
Native Kotlin, Java y Kotlin Multiplatform: sin actualizaciones de code
Cargar archivos dex o JAR descargados con DexClassLoader es exactamente el comportamiento que prohíbe la política. La alternativa del propio Google es Entrega de funciones en tiempo de ejecución, que descarga módulos code a través de Google Play. De lo contrario, el code nativo no puede cambiar. Una app en Kotlin o Java que aloja JavaScript en un WebView aún puede actualizar ese code, ya que la política exime al code interpretado. El resto de la lógica nativa se limita a remote config, feature flags y server-driven UI.
Unity y motores de juego: contenido sí, code no
El code de un juego está compilado. Los asset bundles y Play Asset Delivery gestionan el contenido, y los lenguajes de scripting embebidos como Lua son code interpretado, algo que la política permite siempre que el resultado cumpla las políticas de Play.
Web wrappers y Trusted Web Activities: en vivo por naturaleza
Una Trusted Web Activity o un WebView wrapper carga tu sitio web, así que se actualiza cada vez que haces deploy. Google Play acepta TWAs. La caché offline y los bridges nativos dependen de lo que implemente ese wrapper: una TWA puede usar el service worker de tu PWA, y un shell de WebView puede exponer bridges de JavaScript si los construyes. Una app de Capacitor empaquetada incluye el web bundle en el APK y añade una capa de plugins consistente para live updates.
Lo que ningún stack puede hacer en Android
Sea cual sea tu framework, un live update no puede:
- Descargar dex, JAR, APK o archivos nativos
.sofuera de Google Play - Añadir nuevos permisos de Android
- Hacer que la app haga algo prohibido por Google Play
- Cambiar la app por algo que no describe su ficha en la Play Store
Próximos pasos
- Respuesta de iOS: ¿Permite Apple los Live Updates sin revisión de la App Store?
- Checklist de cumplimiento: Checklist para cumplir con Google Play OTA
- Estrategia de lanzamiento: Cumplimiento en Google Play: estrategias clave
Lanza fixes hoy, no tras una revisión
Live Updates de Capgo envía cambios de JavaScript, HTML y CSS a tu app Capacitor en minutos, con canales, rollbacks, delta updates y cifrado de extremo a extremo. Es open source y puedes self-hostearlo.
bunx @capgo/cli@latest initSigue la guía rápida para enviar tu primer update.
