Kurze Antwort: Ja, Google Play erlaubt Live Updates von interpretiertem code. Du kannst neues JavaScript, HTML und CSS in eine Android-App pushen, ohne ein neues Play Store Review abzuwarten. Du darfst jedoch keine nativen code wie dex, JAR oder .so Dateien.
Google ist hier klarer als Apple: Die Ausnahme für JavaScript in einer WebView ist direkt in der Policy verankert. Diese Seite zitiert sie, zeigt die Grenze auf und erklärt, wie Google sie durchsetzt.
Dies ist keine Rechtsberatung. Es beschreibt, wie die Policy aktuell lautet und wie tausende Apps sie in der Produktion nutzen.
Was die Google Play Policy tatsächlich sagt
Die Regel steht in der Device and Network Abuse Policy:
Eine über Google Play vertriebene App darf sich nicht mit anderen Methoden als dem Update-Mechanismus von Google Play modifizieren, ersetzen oder aktualisieren. Ebenso darf eine App keine ausführbaren code (wie dex, JAR, .so Dateien) aus einer anderen Quelle als Google Play herunterladen. Diese Einschränkung gilt nicht für code, das in einer virtuellen Maschine oder einem Interpreter läuft, sofern dieser indirekten Zugriff auf Android APIs bietet (wie JavaScript in einer WebView oder einem Browser).
Und direkt danach:
Apps oder Drittanbieter-code, wie SDKs, die interpretierte Sprachen (JavaScript, Python, Lua, etc.) zur Laufzeit laden (z. B. nicht mit der App verpackt), dürfen potenzielle Verstöße gegen die Google Play Policies nicht ermöglichen.
Es gibt also zwei Regeln:
- Native code kommen nur von Google Play. Keine heruntergeladenen dex-, JAR- oder nativen Libraries.
- Interpretierte code können von überall kommen, aber ihre Funktionen müssen weiterhin allen Play-Richtlinien entsprechen.
Der Web-Layer einer Capacitor App besteht aus JavaScript, HTML und CSS, die im Android WebView laufen – genau das Beispiel, das Google nennt. Das fällt unter die Ausnahme.
Wo die Grenze verläuft
| Erlaubt mit einem live update | Nicht erlaubt mit einem live update |
|---|---|
| Bugfixes in JavaScript, HTML oder CSS | Herunterladen von dex, JAR, APK oder .so Dateien |
| UI-Änderungen, Textanpassungen oder neue Screens in deinem bestehenden Web-Stack | Die App außerhalb des Google Play Update-Mechanismus ersetzen |
| A/B-Tests und Staged Rollouts von Web code | Versand von code, der gegen die Play-Policy verstößt (täuschendes Verhalten, Malware, Richtlinienverstöße) |
| Bilder, Übersetzungen, Config aktualisieren | Die App in etwas verwandeln, das nicht der Store-Beschreibung entspricht |
| Ein fehlerhaftes Release zurückrollen | Android-Berechtigungen oder Sicherheitsmechanismen umgehen |
Capgo liefert nur die linke Spalte aus. Alles Native, wie ein neues Capacitor Plugin, eine neue Berechtigung in AndroidManifest.xml, oder eine Gradle-Dependency, erfordert weiterhin ein neues Release über Google Play. Capgo Version-Targeting hält Bundles, die neue native code benötigen, von alten Binaries fern.
Wie Google es durchsetzt
Google scannt Apps auf heruntergeladene ausführbare code und auf Verhaltensweisen, die sich nach der Installation ändern. Die automatisierten Checks suchen nach dem Laden von dex- oder nativen Libraries außerhalb der APK. JavaScript in einer WebView löst diese nicht aus.
Das eigentliche Risiko liegt in der zweiten Regel: Wenn ein live update die App dazu bringt, etwas zu tun, das gegen die Play-Richtlinien verstößt, ist es ein Verstoß – egal, wie der code geladen wurde. Die Richtlinie zu irreführendem Verhalten gilt auch für Apps, deren Funktion sich nach dem Review ändert.
In der Praxis:
- Nutze Live Updates für Fixes und Iterationen an deiner bereits veröffentlichten App.
- Halte die App konsistent mit deinem Play Store Listing und dem Formular zum Datenschutz.
- Veröffentliche native Änderungen und große Releases über Google Play, idealerweise mit gestaffelte Rollouts falls du ein schrittweises Deployment bevorzugst.
Welche Stacks können das auf Android?
Ob deine App Over-the-Air-Updates auf Android ausliefern kann, hängt von einer Frage ab: Wird deine App-Logik zur Laufzeit interpretiert? JavaScript und andere interpretierte code ja. Heruntergeladene dex-, JAR- und native .so Files nein. AOT-kompilierte Frameworks wie Flutter qualifizieren sich nur über eine VM oder einen Interpreter.
Android-live update-Kompatibilität nach Stack
| Stack | So läuft code auf Android | Live Updates erlaubt? | Tooling |
|---|---|---|---|
| Capacitor | JavaScript, HTML, CSS in der Android WebView | Ja | Capgo |
| Ionic (auf Capacitor) | Wie Capacitor | Ja | Capgo |
| Cordova | JavaScript in der Android WebView | Ja | Capgo nach der Migration zu Capacitor, Legacy-Cordova-Plugins |
| React Native / Expo | JavaScript-Bundle auf Hermes | Ja, nur JavaScript | Expo Updates, selbst gehostete CodePush-Alternativen |
| NativeScript | JavaScript auf V8 | Ja, nur JavaScript | Eingeschränkt, meist Eigenbau |
| Flutter | Dart AOT zu einer nativen Library kompiliert | Nur über eine VM oder einen Interpreter | Shorebird |
| Natives Kotlin / Java | dex-Bytecode auf ART | Nein für natives code; ja für JavaScript in einer WebView | Remote Config, Play Feature Delivery |
| Kotlin / Compose Multiplatform | dex-Bytecode auf ART | Nein | Remote Config, Play Feature Delivery |
| .NET MAUI / Xamarin | .NET-Runtime plus native Libraries, die im APK mitgeliefert werden | Nein | Nur Remote Config |
| Unity / Unreal | C# via IL2CPP oder C++, kompiliert | Nein für code, ja für Content | Asset Bundles, Play Asset Delivery, skriptbasierter Content (Lua) |
| Web Wrapper / TWA | Website wird in einer WebView oder in Chrome geladen | Immer live | Keine erforderlich |
Capacitor, Ionic und Cordova: voll unterstützt
Deine UI und Business-Logik sind JavaScript, das in der Android WebView läuft – genau das Beispiel, das Googles Richtlinien für erlaubte code nennen. Ein live update ersetzt das Web-Bundle; die APK, nativen Plugins und Berechtigungen bleiben die, die du veröffentlicht hast.
Capgo ist von Haus aus konform, da sich damit nur die Web-Schicht ändern lässt. Neue native Plugins, neue Berechtigungen in AndroidManifest.xml und Änderungen an Gradle-Dependencies brauchen weiterhin ein Google-Play-Release.
React Native und Expo: JavaScript ja, native Module nein
React Native führt ein JavaScript-Bundle auf Hermes aus, was als code in interpretierter Form gilt. Expo Updates und das mittlerweile eingestellte Microsoft CodePush aktualisieren dieses Bundle. Teams, die CodePush verlassen brauchen einen Ersatz. Native Module und React-Native-Upgrades brauchen ein neues Release.
Flutter: nur über eine VM oder einen Interpreter
Flutter kompiliert Dart Ahead-of-Time in libapp.so. Das Herunterladen einer neuen .so ist ausdrücklich verboten, daher kann Standard-Flutter keine Live Updates nutzen. Shorebird fügt code Push hinzu und gibt an, dass es die Play-Richtlinie einhält, indem es Updates über die Dart-VM ausführt. Mehr dazu in Live Updates für Flutter-Apps.
Native Kotlin, Java und Kotlin Multiplatform: keine code-Updates
Das Laden heruntergeladener dex- oder JAR-Dateien mit DexClassLoader entspricht genau dem Verhalten, das die Richtlinie verbietet. Googles eigene Alternative ist Feature-Delivery mit Play ermöglichen, welches code-Module über Google Play herunterlädt. Ansonsten kann der native code nicht geändert werden. Eine Kotlin- oder Java-App, die JavaScript in einer WebView hostet, kann dieses code weiterhin aktualisieren, da die Richtlinie interpretierten code ausnimmt. Andere native Logik ist auf Remote Config, Feature Flags und Server-driven UI beschränkt.
Unity und Game Engines: Content ja, code nein
Der code des Spiels ist kompiliert. Asset-Bundles und Play Asset Delivery kümmern sich um die Inhalte, und eingebettete Skriptsprachen wie Lua werden code interpretiert, was die Richtlinie erlaubt, solange das Ergebnis den Play-Richtlinien entspricht.
Web Wrappers und Trusted Web Activities: von Haus aus live
Ein Trusted Web Activity oder WebView-Wrapper lädt deine Website, sodass sie bei jedem Deployment aktualisiert wird. Google Play akzeptiert TWAs. Offline-Caching und native Bridges hängen davon ab, was der Wrapper implementiert: Eine TWA kann deinen PWA-Service-Worker nutzen, und eine WebView-Shell kann JavaScript-Bridges bereitstellen, wenn du sie selbst baust. Eine gebündelte Capacitor-App liefert das Web-Bundle in der APK aus und fügt eine konsistente Plugin-Schicht für Live Updates hinzu.
Was kein Stack auf Android kann
Egal, welches Framework du nutzt, eine live update kann nicht:
- dex-, JAR-, APK- oder native
.soDateien außerhalb von Google Play herunterladen - Neue Android-Berechtigungen hinzufügen
- Die App Dinge tun lassen, die Google Play verbietet
- Die App in etwas verwandeln, das nicht im Play Store steht
Wie es weitergeht
- Antwort für iOS: Erlaubt Apple Live Updates ohne App Store Review?
- Compliance-Checkliste: Checkliste für Google Play OTA-Compliance
- Release-Strategie: Google Play Compliance: Strategien für Key-Updates
Fixes heute releasen, nicht erst nach dem Review
Capgo Live Updates Pushe JavaScript-, HTML- und CSS-Änderungen in wenigen Minuten in deine Capacitor App – mit Channels, Rollbacks, Delta Updates und End-to-End-Verschlüsselung. Open Source und selbst hostbar.
bunx @capgo/cli@latest initFolge dem Quickstart um dein erstes Update zu senden.
