Respuesta corta: sí, Google Play permite actualizaciones en vivo de code interpretado. Puedes enviar nuevo JavaScript, HTML y CSS a una app de Android sin una nueva revisión de 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 hace cumplir.
Esto no es asesoramiento legal. Es cómo está redactada la política hoy 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 a través de Google Play no puede modificarse, reemplazarse ni actualizarse mediante ningún método distinto al mecanismo de actualización de Google Play. Del mismo modo, una app no puede descargar code ejecutable (como archivos dex, JAR o .so) de una fuente distinta a Google Play. Esta restricción no se aplica a code que se ejecuta en una máquina virtual o un intérprete que proporcionen 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, que no se empaquetan con la app) no deben permitir posibles violaciones de las políticas de Google Play.
Así que hay dos reglas:
- El code nativo solo proviene de Google Play. Nada de dex, JAR ni librerías nativas descargadas.
- El code interpretado puede provenir de cualquier lugar, pero lo que haga debe cumplir todas las políticas de Play.
La capa web de una app de Capacitor es JavaScript, HTML y CSS que se ejecutan en el WebView de Android, el ejemplo exacto que da Google. Encaja en la exención.
Dónde está el límite
| Permitido con un live update | No permitido con un live update |
|---|---|
| Correcciones de bugs en tu JavaScript, HTML o CSS | Descargar dex, JAR, APK o .so archivos |
| Cambios de UI, de copy o nuevas pantallas en tu stack web actual | Reemplazar la app fuera del mecanismo de actualización de Google Play |
| Pruebas A/B y despliegues progresivos de web code | Publicar code que incumple la política de Play (conducta engañosa, malware, contenido que viola las normas) |
| Actualizar imágenes, traducciones o config | Convertir la app en algo que no describe la ficha |
| Revertir una versión defectuosa | Evitar permisos o seguridad de Android |
Capgo solo envía la columna izquierda. Cualquier cosa nativa, como un nuevo plugin de Capacitor, un nuevo permiso en AndroidManifest.xml, o una dependencia de Gradle, aún requiere un nuevo lanzamiento a través de Google Play. Capgo segmentación por versión mantiene los bundles que necesitan nuevo code nativo alejados de los binarios antiguos.
Cómo lo aplica Google
Google escanea las aplicaciones en busca de code ejecutable descargado y de comportamientos que cambian tras la instalación. Las comprobaciones automatizadas buscan la carga de dex o librerías nativas desde fuera del APK. El JavaScript en un WebView no las activa.
El riesgo real es la segunda regla: si un live update hace que la app haga algo que la política de Play prohíbe, es una infracción sin importar cómo llegó el code. La política de comportamiento engañoso también se aplica a apps cuya función cambia tras la revisión.
En la práctica:
- Usa actualizaciones en vivo para correcciones e iteraciones en la app que publicaste.
- Mantén la app coherente con tu ficha en Play Store y tu formulario de seguridad de datos.
- Lanza cambios nativos y grandes versiones a través de Google Play, con rollouts escalonados si quieres que sean graduales.
¿Qué stacks pueden hacerlo en Android?
Si tu app puede enviar actualizaciones over-the-air en Android depende de una pregunta: ¿la lógica de tu app se interpreta en tiempo de ejecución? JavaScript y otros code interpretados, sí. Dex descargado, JAR y nativo .so archivos, no. Los frameworks compilados AOT como Flutter solo califican a través de una VM o intérprete.
Compatibilidad de live update en Android por stack
| Stack | Cómo funciona 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 legacy de Cordova |
| 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 propio |
| Flutter | Dart compilado AOT a una librería nativa | Solo mediante VM o intérprete | Shorebird |
| Kotlin / Java nativo | bytecode dex en ART | No para code nativo; sí para JavaScript en un 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 configuración 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 | Ninguno necesario |
Capacitor, Ionic y Cordova: totalmente cubiertos
Tu UI y tu lógica de negocio son JavaScript que se ejecuta en el Android WebView, el ejemplo exacto que la política de Google cita como caso permitido de code. 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, ya que solo puede cambiar la capa web. Los nuevos plugins nativos, los nuevos permisos en AndroidManifest.xml y los cambios en dependencias de Gradle aún requieren una publicación en Google Play.
React Native y Expo: JavaScript sí, módulos nativos no
React Native ejecuta un bundle de JavaScript en Hermes, lo que cuenta como code interpretado. Expo Updates y el ahora retirado Microsoft CodePush actualizan ese bundle. Equipos que abandonan CodePush necesitan una alternativa. Los módulos nativos y las actualizaciones de React Native requieren un nuevo release.
Flutter: solo a través de una VM o intérprete
Flutter compila Dart de antemano en libapp.so. Descargar un nuevo .so está explícitamente prohibido, por lo que Flutter estándar no puede usar actualizaciones en vivo. Shorebird añade push de code y afirma que cumple con la política de Play ejecutando las actualizaciones a través de la máquina virtual de Dart. Lee más en actualizaciones en vivo para apps de Flutter.
Kotlin nativo, 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 real, 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 aloje 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 queda limitada a remote config, feature flags y server-driven UI.
Unity y motores de juego: contenido sí, code no
El code del juego está compilado. Los asset bundles y Play Asset Delivery gestionan el contenido, y los lenguajes de scripting embebidos como Lua son code interpretado, lo que la política permite siempre que el resultado respete las políticas de Play.
Web wrappers y Trusted Web Activities: en vivo por naturaleza
Una Trusted Web Activity o un wrapper de WebView carga tu sitio web, por lo que se actualiza cada vez que haces deploy. Google Play acepta TWAs. El caching offline y los bridges nativos dependen de lo que implemente ese wrapper: un TWA puede usar el service worker de tu PWA, y un shell de WebView puede exponer bridges de JavaScript si los construyes. Una app Capacitor empaquetada incluye el bundle web 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 archivos dex, JAR, APK o nativos
.sofuera de Google Play - Añadir nuevos permisos de Android
- Haz que la app haga algo que la política de Google Play prohíbe
- Convertir la app en algo que la ficha de Play Store no describe
Próximos pasos
- Respuesta para iOS: ¿Permite Apple actualizaciones en vivo sin revisión de App Store?
- Lista de verificación de cumplimiento: Checklist para el cumplimiento de OTA en Google Play
- Estrategia de lanzamiento: Cumplimiento de Google Play: estrategias de actualización de keys
Lanza fixes hoy, no tras la revisión
actualizaciones Live Update de Capgo envía cambios de JavaScript, HTML y CSS a tu app Capacitor en minutos, con canales, rollbacks, actualizaciones delta y cifrado de extremo a extremo. Es open source y puedes autoalojarlo.
bunx @capgo/cli@latest initSigue la Inicio rápido para enviar tu primer update.
