Réponse courte : oui, Google Play autorise les live updates de code interprétés. Vous pouvez pousser du nouveau JavaScript, HTML et CSS vers une application Android sans nouvelle revue du Play Store. Vous ne pouvez pas télécharger de code natifs tels que des fichiers dex, JAR ou .so fichiers.
Google est plus clair qu'Apple sur ce point : l'exemption pour le JavaScript dans une WebView est explicitement inscrite dans la politique. Cette page la cite, montre où se situe la limite et explique comment Google l'applique.
This is not legal advice. It is how the policy reads today and how thousands of apps use it in production.
Ce que dit réellement la politique de Google Play
La règle se trouve dans la politique d’abus de l’appareil et du réseau:
Une application distribuée via Google Play ne peut pas se modifier, se remplacer ou se mettre à jour en utilisant une méthode autre que le mécanisme de mise à jour de Google Play. De même, une application ne peut pas télécharger de code exécutable (tels que des fichiers dex, JAR, .so) depuis une source autre que Google Play. Cette restriction ne s'applique pas au code qui s'exécute dans une machine virtuelle ou un interpréteur fournissant un accès indirect aux API Android (comme le JavaScript dans une webview ou un navigateur).
Et juste après :
Les applications ou les code tiers, comme les SDK, utilisant des langages interprétés (JavaScript, Python, Lua, etc.) chargés au moment de l'exécution (par exemple, non packagés avec l'app) ne doivent pas permettre de violations potentielles des politiques de Google Play.
Il y a donc deux règles :
- Le code natif provient uniquement de Google Play. Aucun téléchargement de dex, JAR ou de bibliothèques natives.
- Le code interprété peut provenir de n'importe où, mais ses actions doivent toujours respecter chaque politique de Play.
La couche web d'une application Capacitor est composée de JavaScript, HTML et CSS s'exécutant dans l'Android WebView, l'exemple exact donné par Google. Cela entre dans l'exception.
Où se situe la limite
| Autorisé avec un live update | Non autorisé avec un live update |
|---|---|
| Corrections de bugs en JavaScript, HTML, CSS | Téléchargement de dex, JAR, APK ou .so fichiers |
| Modifications d'UI, de texte ou nouveaux écrans via votre stack web actuelle | Remplacer l'application en dehors du mécanisme de mise à jour de Google Play |
| Tests A/B et déploiements progressifs de code web | Déploiement de code enfreignant la politique Play (comportement trompeur, malware, contenu non conforme) |
| Mise à jour d'images, de traductions ou de config | Transformer l'app en quelque chose que la fiche ne décrit pas |
| Faire un rollback d'une mauvaise release | Contourner les permissions ou la sécurité Android |
Capgo ne déploie que la colonne de gauche. Tout ce qui est natif, comme un nouveau plugin Capacitor, une nouvelle permission dans AndroidManifest.xml, ou une dépendance Gradle, nécessite toujours une nouvelle release via Google Play. Celle de Capgo ciblage de version permet d'isoler les bundles nécessitant de nouveaux code natifs des anciens binaires.
Comment Google l'applique
Google analyse les apps pour détecter les code exécutables téléchargés et les comportements qui changent après l'installation. Les contrôles automatisés cherchent le chargement de fichiers dex ou de bibliothèques natives en dehors de l'APK. Le JavaScript dans une WebView ne déclenche pas ces alertes.
Le vrai risque réside dans la seconde règle : si un live update force l'app à faire quelque chose d'interdit par la politique Play, c'est une violation, peu importe la manière dont le code est arrivé. La politique sur les comportements trompeurs s'applique aussi aux apps dont la fonction change après examen.
En pratique :
- Utilisez les live updates pour les correctifs et l'itération sur l'app que vous avez publiée.
- Gardez votre application cohérente avec votre fiche Play Store et votre formulaire de sécurité des données.
- Déployez des changements natifs et des lancements majeurs via Google Play, avec des déploiements progressifs si vous souhaitez une approche graduelle.
Quelles stacks le permettent sur Android ?
La capacité de votre application à déployer des mises à jour OTA sur Android dépend d'une question : votre logique applicative est-elle interprétée au runtime ? Le JavaScript et les autres code interprétés, oui. Les fichiers dex, JAR et natifs téléchargés, .so non. Les frameworks compilés en AOT comme Flutter ne sont éligibles que via une VM ou un interpréteur.
Compatibilité live update Android par stack
| Stack | Mode d'exécution du code sur Android | Live updates autorisés ? | Tooling |
|---|---|---|---|
| Capacitor | JavaScript, HTML, CSS dans l'Android WebView | Oui | Capgo |
| Ionic (sur Capacitor) | Identique à Capacitor | Oui | Capgo |
| Cordova | JavaScript dans l'Android WebView | Oui | Capgo après la migration vers Capacitor, les anciens plugins Cordova |
| React Native / Expo | bundle JS sur Hermes | Oui, uniquement le JavaScript | Expo Updates, alternatives self-hosted à CodePush |
| NativeScript | JavaScript sur V8 | Oui, uniquement le JavaScript | Limité, principalement du sur-mesure |
| Flutter | Dart compilé en AOT dans une bibliothèque native | Uniquement via une VM ou un interpréteur | Shorebird |
| Kotlin / Java natif | bytecode dex sur ART | Non pour le code natif ; oui pour le JavaScript dans une WebView | Remote config, Play Feature Delivery |
| Kotlin / Compose Multiplatform | bytecode dex sur ART | Non | Remote config, Play Feature Delivery |
| .NET MAUI / Xamarin | runtime .NET plus bibliothèques natives incluses dans l'APK | Non | Configuration à distance uniquement |
| Unity / Unreal | C# via IL2CPP ou C++, compilé | Non pour code, oui pour le contenu | Asset bundles, Play Asset Delivery, contenu scripté (Lua) |
| Web wrapper / TWA | Site web chargé dans une WebView ou Chrome | Toujours en direct | Aucun nécessaire |
Capacitor, Ionic et Cordova : totalement couverts
Votre UI et votre logique métier sont du JavaScript s'exécutant dans l'Android WebView, l'exemple exact donné par la politique de Google pour les code autorisés. Un live update remplace le bundle web ; l'APK, les plugins natifs et les permissions restent ceux que vous avez publiés.
Capgo est conforme par conception car il ne peut modifier que la couche web. Les nouveaux plugins natifs, les nouvelles permissions dans AndroidManifest.xml et les changements de dépendances Gradle nécessitent toujours une release sur Google Play.
React Native et Expo : le JavaScript oui, les modules natifs non
React Native exécute un bundle JavaScript sur Hermes, ce qui est considéré comme du code interprété. Expo Updates et l'ancien Microsoft CodePush mettent à jour ce bundle. Les équipes quittant CodePush besoin d'un remplacement. Les modules natifs et les mises à niveau React Native nécessitent une nouvelle release.
Flutter : uniquement via une VM ou un interpréteur
Flutter compile le Dart en amont en libapp.so. Le téléchargement d'un nouveau .so est explicitement interdit, donc le Flutter standard ne peut pas utiliser de live updates. Shorebird ajoute le push code et affirme être conforme à la politique Play en exécutant les mises à jour via la machine virtuelle Dart. En savoir plus dans les live updates pour les apps Flutter.
Kotlin natif, Java et Kotlin Multiplatform : pas de mises à jour code
Charger des fichiers dex ou JAR téléchargés avec DexClassLoader est précisément le comportement interdit par la politique. L'alternative de Google est Déploiement de fonctionnalités via Play Store, qui télécharge des modules code via Google Play. Sinon, le code natif ne peut pas changer. Une application Kotlin ou Java qui héberge du JavaScript dans une WebView peut toujours mettre à jour ce code, car la politique exempte le code interprété. La logique native est limitée à la config distante, aux feature flags et au server-driven UI.
Unity et moteurs de jeu : le contenu oui, le code non
Le code de jeu est compilé. Les asset bundles et Play Asset Delivery gèrent le contenu, et les langages de scripting embarqués comme Lua sont du code interprété, ce que la politique autorise tant que le résultat respecte les règles de Play.
Web wrappers et Trusted Web Activities : vivants par nature
Une Trusted Web Activity ou un wrapper WebView charge votre site web, il est donc mis à jour à chaque déploiement. Google Play accepte les TWA. Le cache hors ligne et les ponts natifs dépendent de ce que le wrapper implémente : une TWA peut utiliser le service worker de votre PWA, et une coquille WebView peut exposer des ponts JavaScript si vous les développez. Une application Capacitor inclut le bundle web dans l'APK et ajoute une couche de plugins cohérente pour les live updates.
Ce qu'aucune stack ne peut faire sur Android
Quel que soit votre framework, un live update ne peut pas :
- Télécharger des fichiers dex, JAR, APK ou natifs
.soen dehors de Google Play - Ajouter de nouvelles permissions Android
- Forcer l'app à faire quelque chose d'interdit par Google Play
- Transformer l'app en quelque chose de non décrit sur le Play Store
Prochaines étapes
- Réponse pour iOS : Apple autorise-t-il les live updates sans revue de l'App Store ?
- Checklist de conformité : Checklist de conformité OTA pour Google Play
- Stratégie de release : Conformité Google Play : stratégies de mise à jour clés
Ship fixes today, not after review
live updates Capgo envoyez vos changements JavaScript, HTML et CSS vers votre application Capacitor en quelques minutes, avec des canaux, des rollbacks, des mises à jour delta et un chiffrement de bout en bout. C'est open source et peut être auto-hébergé.
bunx @capgo/cli@latest initConsultez la démarrage rapide pour envoyer votre première mise à jour.
