Risposta breve: sì, Google Play permette i live update di code interpretato. Puoi inviare nuovo JavaScript, HTML e CSS a un'app Android senza una nuova revisione sul Play Store. Non puoi scaricare code nativi come dex, JAR o .so file.
Google è più chiaro di Apple su questo: l'esenzione per JavaScript in una WebView è scritta direttamente nella policy. Questa pagina la cita, mostra il limite e spiega come Google la applica.
Questa non è una consulenza legale. È l'interpretazione attuale della policy e il modo in cui migliaia di app la utilizzano in produzione.
Cosa dice realmente la policy di Google Play
La regola si trova nella policy Device and Network Abuse:
Un'app distribuita tramite Google Play non può modificare, sostituire o aggiornare se stessa con metodi diversi dal meccanismo di aggiornamento di Google Play. Allo stesso modo, un'app non può scaricare code eseguibili (come file dex, JAR, .so) da fonti diverse da Google Play. Questa restrizione non si applica a code che gira in una macchina virtuale o in un interprete che fornisca un accesso indiretto alle API Android (come JavaScript in una webview o in un browser).
E subito dopo:
App o code di terze parti, come gli SDK, che utilizzano linguaggi interpretati (JavaScript, Python, Lua, ecc.) caricati a runtime (ad esempio, non inclusi nel pacchetto dell'app) non devono permettere violazioni delle policy di Google Play.
Quindi ci sono due regole:
- Il code nativo proviene solo da Google Play. Nessun download di dex, JAR o librerie native.
- Il code interpretato può provenire da qualsiasi fonte, ma ciò che esegue deve comunque rispettare ogni policy di Play.
Il web layer di un'app Capacitor è composto da JavaScript, HTML e CSS in esecuzione nell'Android WebView, proprio come l'esempio fornito da Google. Rientra quindi nell'esenzione.
Dove tracciare la linea
| Consentito con live update | Non consentito con live update |
|---|---|
| Bug fix in JavaScript, HTML o CSS | Download di dex, JAR, APK o .so file |
| Modifiche UI, testi o nuove schermate nel web stack esistente | Sostituire l'app al di fuori del meccanismo di aggiornamento di Google Play |
| A/B test e rollout graduali di code web | Rilasciare code che violano le policy di Play (comportamenti ingannevoli, malware, contenuti non conformi) |
| Aggiornamento di immagini, traduzioni o config | Trasformare l'app in qualcosa che non è descritto nella scheda |
| Effettuare il rollback di un rilascio errato | Aggirare i permessi o la sicurezza di Android |
Capgo distribuisce solo la colonna di sinistra. Qualsiasi elemento nativo, come un nuovo plugin Capacitor, un nuovo permesso in AndroidManifest.xml, o una dipendenza Gradle, richiede ancora un nuovo rilascio tramite Google Play. Capgo targeting delle versioni mantiene i bundle che richiedono nuovi code nativi separati dai vecchi binari.
Come Google applica le regole
Google scansiona le app alla ricerca di code eseguibili scaricati e di comportamenti che cambiano dopo l'installazione. I controlli automatici cercano il caricamento di dex o librerie native al di fuori dell'APK. Il JavaScript in una WebView non li attiva.
Il vero rischio è la seconda regola: se un live update spinge l'app a fare qualcosa vietato dalle policy di Play, è una violazione a prescindere da come è arrivato il code. La policy sul comportamento ingannevole si applica anche alle app la cui funzione cambia dopo la revisione.
In pratica:
- Usa i live updates per fix e iterazioni sull'app che hai già pubblicato.
- Mantieni l'app coerente con la scheda del Play Store e il modulo sulla sicurezza dei dati.
- Distribuisci modifiche native e grandi lanci tramite Google Play, con rollout graduali se desideri un rilascio graduale.
Quali stack possono farlo su Android?
La possibilità di inviare aggiornamenti over-the-air su Android dipende da una domanda: la logica dell'app è interpretata a runtime? JavaScript e altri code interpretati, sì. File dex, JAR e nativi scaricati, .so no. I framework compilati AOT come Flutter sono idonei solo tramite VM o interprete.
Compatibilità live update Android per stack
| Stack | Come viene eseguito il code su Android | Live updates consentiti? | Tooling |
|---|---|---|---|
| Capacitor | JavaScript, HTML, CSS nella WebView di Android | Sì | Capgo |
| Ionic (su Capacitor) | Uguale a Capacitor | Sì | Capgo |
| Cordova | JavaScript nella WebView di Android | Sì | Capgo dopo la migrazione a Capacitor, plugin Cordova legacy |
| React Native / Expo | bundle JavaScript su Hermes | Sì, solo JavaScript | Expo Updates, alternative self-hosted a CodePush |
| NativeScript | JavaScript su V8 | Sì, solo JavaScript | Limitato, per lo più custom |
| Flutter | Dart compilato AOT in una libreria nativa | Solo tramite VM o interprete | Shorebird |
| Kotlin / Java nativo | bytecode dex su ART | No per code nativo; sì per JavaScript in WebView | Remote config, Play Feature Delivery |
| Kotlin / Compose Multiplatform | bytecode dex su ART | No | Remote config, Play Feature Delivery |
| .NET MAUI / Xamarin | runtime .NET più librerie native nell'APK | No | Solo remote config |
| Unity / Unreal | C# via IL2CPP o C++, compilato | No per code, sì per i contenuti | Asset bundle, Play Asset Delivery, contenuti scriptati (Lua) |
| Web wrapper / TWA | Sito caricato in una WebView o Chrome | Sempre live | Non serve nulla |
Capacitor, Ionic e Cordova: supporto completo
La tua UI e la logica di business sono JavaScript in esecuzione nella WebView di Android, l'esempio esatto che la policy di Google cita per i code consentiti. Un live update sostituisce il web bundle; l'APK, i plugin nativi e i permessi restano quelli che hai pubblicato.
Capgo è conforme by design perché può modificare solo il layer web. Nuovi plugin nativi, nuovi permessi in AndroidManifest.xml e modifiche alle dipendenze Gradle richiedono ancora un rilascio su Google Play.
React Native ed Expo: JavaScript sì, moduli nativi no
React Native esegue un bundle JavaScript su Hermes, che conta come code interpretato. Expo Updates e l'ormai dismesso Microsoft CodePush aggiornano quel bundle. I team che abbandonano CodePush serve un sostituto. I moduli nativi e gli aggiornamenti di React Native richiedono un nuovo rilascio.
Flutter: solo tramite VM o interprete
Flutter compila Dart in modalità AOT in libapp.so. Scaricare un nuovo .so è esplicitamente vietato, quindi il Flutter standard non può usare i live updates. Shorebird aggiunge code push e dichiara di rispettare la policy di Play eseguendo gli aggiornamenti tramite la macchina virtuale Dart. Leggi di più in live updates per app Flutter.
Native Kotlin, Java e Kotlin Multiplatform: nessun aggiornamento code
Caricare file dex o JAR scaricati con DexClassLoader è esattamente il comportamento vietato dalla policy. L'alternativa di Google è Consegna delle funzionalità in tempo reale, che scarica i moduli code tramite Google Play. Altrimenti, il code nativo non può cambiare. Un'app Kotlin o Java che ospita JavaScript in una WebView può comunque aggiornare quel code, poiché la policy esenta il code interpretato. Altra logica nativa è limitata a remote config, feature flags e server-driven UI.
Unity e game engine: contenuti sì, code no
Il code del gioco è compilato. Asset bundle e Play Asset Delivery gestiscono i contenuti, mentre i linguaggi di scripting embedded come Lua sono code interpretati, cosa permessa dalla policy purché il risultato rispetti le regole di Play.
Web wrapper e Trusted Web Activities: live per natura
Una Trusted Web Activity o un wrapper WebView caricano il tuo sito, quindi si aggiornano a ogni deploy. Google Play accetta le TWA. Caching offline e bridge nativi dipendono da ciò che implementa il wrapper: una TWA può usare il service worker della tua PWA, e una shell WebView può esporre bridge JavaScript se li sviluppi. Un'app Capacitor bundleizzata include il web bundle nell'APK e aggiunge uno strato di plugin coerente per i live updates.
Cosa nessuno stack può fare su Android
Qualunque sia il tuo framework, un live update non può:
- Scaricare dex, JAR, APK o file nativi
.sofile al di fuori di Google Play - Aggiungere nuovi permessi Android
- Far fare all'app ciò che la policy di Google Play proibisce
- Trasformare l'app in qualcosa che la scheda del Play Store non descrive
Prossimi passi
- Risposta per iOS: Apple permette i Live Update senza revisione dell'App Store?
- Checklist di conformità: Checklist per la conformità OTA su Google Play
- Strategia di rilascio: Conformità Google Play: strategie di aggiornamento chiave
Rilascia fix oggi, non dopo la revisione
Live Updates di Capgo pubblica modifiche JavaScript, HTML e CSS nella tua app Capacitor in pochi minuti, con canali, rollback, delta update e crittografia end-to-end. È open source e può essere self-hosted.
bunx @capgo/cli@latest initSegui la guida rapida per inviare il tuo primo update.
