Réponse courte : oui, Google Play autorise les live updates de code interprété. Vous pouvez envoyer du nouveau JavaScript, HTML et CSS à une application Android sans nouvelle revue du Play Store. Vous ne pouvez pas télécharger de code natif tel que dex, JAR ou .so fichiers.
Google est plus clair qu’Apple sur ce point : l’exemption pour le JavaScript dans un WebView est inscrite directement dans la politique. Cette page la cite, montre où se situe la limite et explique comment Google l’applique.
Ceci n'est pas un conseil juridique. C'est ce que dit la politique aujourd'hui et comment des milliers d'applications l'utilisent en 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 du code exécutable (comme 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 où l'un ou l'autre fournit un accès indirect aux API Android (comme le JavaScript dans une webview ou un navigateur).
Et juste après :
Les applications ou le code tiers, comme les SDK, qui utilisent des langages interprétés (JavaScript, Python, Lua, etc.) chargés à l'exécution (par exemple, non intégrés à l'app) ne doivent pas autoriser d'éventuelles violations des politiques de Google Play.
Il y a donc deux règles :
- Le code natif provient uniquement de Google Play. Pas de dex, JAR ni bibliothèques natives téléchargés.
- Le code interprété peut venir de n'importe où, mais ce qu'il fait doit toujours respecter toutes les politiques de Play.
La couche web d’une application Capacitor est du JavaScript, du HTML et du CSS exécutés dans le WebView Android, l’exemple exact donné par Google. Elle relève de l’exemption.
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 |
| Changements d'UI, de textes ou nouveaux écrans dans votre stack web existante | Remplacer l’app en dehors du mécanisme de mise à jour de Google Play |
| Tests A/B et déploiements progressifs de web code | Publier un code qui viole la politique Play (comportement trompeur, malware, contenu non conforme) |
| Mise à jour d'images, de traductions, 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. Capgo ciblage de version garde les bundles qui ont besoin de nouveaux code natifs à l'écart des anciens binaires.
Comment Google l'applique
Google scanne 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 dex ou de bibliothèques natives en dehors de l'APK. Le JavaScript dans une WebView ne les déclenche pas.
Le vrai risque, c'est la deuxième règle : si un live update amène l'app à faire quelque chose que la politique Play interdit, c'est une violation, peu importe comment le code est arrivé. La politique sur les comportements trompeurs s'applique aussi aux apps dont le fonctionnement change après la revue.
En pratique :
- Utilisez les live updates pour les correctifs et l'itération sur l'app que vous avez publiée.
- Gardez l’application cohérente avec votre fiche Play Store et votre formulaire de sécurité des données.
- Publiez les modifications natives et les grandes releases via Google Play, avec déploiements progressifs si vous souhaitez qu’ils soient progressifs.
Quels stacks peuvent le faire sur Android ?
Si votre application peut livrer des mises à jour OTA sur Android dépend d’une seule question : la logique de votre application est-elle interprétée à l’exécution ? JavaScript et autres code interprétés, oui. Dex, JAR et fichiers 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é Android de live update par stack
| Stack | Fonctionnement de code sur Android | Live updates autorisés ? | Outils |
|---|---|---|---|
| Capacitor | JavaScript, HTML, CSS dans la WebView Android | Oui | Capgo |
| Ionic (sur Capacitor) | Identique à Capacitor | Oui | Capgo |
| Cordova | JavaScript dans la WebView Android | Oui | Capgo après migration vers Capacitor, anciens plugins Cordova |
| React Native / Expo | Bundle JS sur Hermes | Oui, uniquement du JavaScript | Expo Updates, alternatives self-hosted à CodePush |
| NativeScript | JavaScript sur V8 | Oui, uniquement du JavaScript | Limité, essentiellement fait maison |
| Flutter | Dart compilé AOT en bibliothèque native | Uniquement via une VM ou un interpréteur | Shorebird |
| Kotlin / Java natif | bytecode DEX sur ART | Non pour le natif code ; oui pour le JavaScript dans un WebView | Configuration distante, Play Feature Delivery |
| Kotlin / Compose Multiplatform | bytecode DEX sur ART | Non | Configuration distante, Play Feature Delivery |
| .NET MAUI / Xamarin | Runtime .NET et bibliothèques natives embarqués 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) |
| Wrapper web / TWA | Site web chargé dans une WebView ou Chrome | Toujours à jour | Aucun |
Capacitor, Ionic et Cordova : entièrement couverts
Votre UI et votre logique métier sont du JavaScript exécuté dans la WebView Android, l’exemple exact que cite la politique de Google pour les code que Google autorise. Un live update remplace le bundle web ; l’APK, les plugins natifs et les permissions restent tels que vous les 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 Microsoft CodePush, désormais retiré, mettent à jour ce bundle. Les équipes qui quittent CodePush nécessitent un remplacement. Les modules natifs et les mises à niveau de React Native exigent une nouvelle release.
Flutter : uniquement via une VM ou un interpréteur
Flutter compile Dart à l'avance (AOT) 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, Java et Kotlin Multiplatform natifs : 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éployez des fonctionnalités en temps réel, qui télécharge des modules code via Google Play. Sinon, le code natif ne peut pas être modifié. 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é. Le reste de la logique native est limité à la remote config, 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 des code interprétés, ce que la politique autorise tant que le résultat respecte les règles de Play.
Wrappers web et Trusted Web Activities : à jour par nature
Une Trusted Web Activity ou un wrapper WebView charge votre site web, qui se met donc à jour à chaque déploiement. Google Play accepte les TWA. Le cache hors ligne et les ponts natifs dépendent de ce que ce wrapper implémente : une TWA peut utiliser le service worker de votre PWA, et un shell WebView peut exposer des ponts JavaScript si vous les mettez en place. Une application Capacitor avec bundle embarque le bundle web dans l'APK et ajoute une couche de plugins homogène 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
- Faire faire à l’app quelque chose d’interdit par la politique Google Play
- Transformer l’application en quelque chose que la fiche Play Store ne décrit pas
Prochaines étapes
- Réponse iOS : Apple autorise-t-il les live updates sans passage par 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 des clés
Ship fixes today, not after review
les 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 auto-hébergeable.
bunx @capgo/cli@latest initConsultez la démarrage rapide pour envoyer votre première mise à jour.
