Risposta breve: sì, Google Play consente live update di code interpretato. Puoi spingere nuovo JavaScript, HTML e CSS su un'app Android senza una nuova revisione su Play Store. Non puoi scaricare code nativo come dex, JAR o .so file.
Qui Google è più chiaro di Apple: l'esenzione per JavaScript in un WebView è scritta direttamente nella policy. Questa pagina la cita, mostra dove sta il confine 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 eseguibile (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, dove uno dei due fornisce 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 consentire potenziali 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 è JavaScript, HTML e CSS eseguiti nella WebView di Android, esattamente l'esempio che fa Google. Rientra nell'esenzione.
Dove sta 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 e config | Trasformare l'app in qualcosa che non è descritto nella scheda |
| Fare 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 tiene lontani dai vecchi binari i bundle che richiedono nuovi code nativi.
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 dall'esterno dell'APK. Il JavaScript in una WebView non li attiva.
Il rischio reale è 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 Sicurezza dei dati.
- Rilascia modifiche native e grandi lanci tramite Google Play, con rollout graduali se li vuoi graduali.
Quali stack possono farlo su Android?
La possibilità di rilasciare aggiornamenti over-the-air su Android dipende da una domanda: la logica dell'app viene interpretata a runtime? JavaScript e gli altri code interpretati: sì. File dex, JAR e nativi scaricati, .so no. I framework compilati AOT come Flutter sono compatibili solo tramite VM o interprete.
Compatibilità live update su Android per stack
| Stack | Come viene eseguito il code su Android | Aggiornamenti live consentiti? | Strumenti |
|---|---|---|---|
| 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 | Limitata, in gran parte sviluppata internamente |
| 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 una 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 incluse nell'APK | No | Solo remote config |
| Unity / Unreal | C# via IL2CPP o C++, compilati | 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 | Nessuno richiesto |
Capacitor, Ionic e Cordova: copertura totale
La tua UI e la business logic sono JavaScript in esecuzione nella WebView di Android, l'esempio esatto che la policy di Google riporta per code consentiti. Un live update sostituisce il web bundle; l'APK, i plugin nativi e i permessi restano quelli pubblicati.
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 comunque una release su Google Play.
React Native ed Expo: JavaScript sì, moduli nativi no
React Native esegue un bundle JavaScript su Hermes, che viene considerato 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 ahead-of-time in libapp.so. Il download di un nuovo .so è esplicitamente vietato, quindi Flutter standard non può usare live updates. Shorebird aggiunge code push e afferma di rispettare la policy di Play eseguendo gli aggiornamenti tramite la macchina virtuale Dart. Leggi di più in live updates per app Flutter.
Kotlin nativo, Java e Kotlin Multiplatform: nessun aggiornamento code
Caricare file dex o JAR scaricati con DexClassLoader è esattamente il comportamento che la policy vieta. 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. Il resto della logica nativa è limitato a remote config, feature flag e server-driven UI.
Unity e motori di gioco: 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 che la policy permette 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 carica il tuo sito, quindi si aggiorna a ogni deploy. Google Play accetta le TWA. La cache offline e i bridge nativi dipendono da cosa 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 un layer 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 file dex, JAR, APK o nativi
.soal di fuori di Google Play - Aggiungere nuovi permessi Android
- Far fare all'app qualcosa che la policy di Google Play proibisce
- Trasformare l'app in qualcosa non descritto sulla scheda del Play Store
Cosa fare ora
- Risposta per iOS: Apple permette i live update senza la revisione dell'App Store?
- Checklist di conformità: Checklist per la conformità OTA su Google Play
- Strategia di rilascio: Conformità Google Play: strategie chiave per gli update
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 lo standard quickstart per inviare il tuo primo update.
