OtaKitGoogle Play OTA compliance: a developer checklist
What Google Play's Device and Network Abuse policy actually restricts, why interpreted web-layer updates stay within policy, and a checklist to keep your Capacitor OTA setup compliant.
Apple's OTA rules get most of the attention, but Google Play has its own policy on downloading code — and Capacitor apps need to respect it too. The good news: like Apple, Google's restriction targets native/executable code, not the interpreted JavaScript your web layer is made of. Here's what the policy actually says and a checklist to keep your OtaKit setup compliant.
Short version: Google Play restricts downloading executable code (like dex or native libraries) that changes app behavior in policy-violating ways. Updating your web layer over the air is standard practice and stays within policy.
What the policy restricts
Google Play's Device and Network Abuse policy prohibits apps from introducing or exploiting code that isn't part of the app to evade Play's policies — the concern is native/executable code (DEX, .so libraries) downloaded at runtime to change what the app does. That's the abuse vector the policy is written against.
Interpreted code executed in a web view — your HTML, CSS, and JavaScript — is a different category and is how hybrid apps have always worked. Shipping bug fixes, UI changes, and content to your web layer over the air is well within policy.
The compliance checklist
- Web layer only. OTA updates carry your web build. Never download and execute native code (DEX, native libraries) to change behavior.
- Native changes go through Play. New permissions, native SDKs, or Capacitor/plugin upgrades ship as a Play release — not OTA.
- Don't change the app's core purpose via OTA. Update and improve the reviewed app; don't repurpose it after approval.
- Respect data-safety declarations. If an OTA update changes what data you collect, update your Play Data safety form accordingly.
- Keep the update path secure. Signed, hash-verified bundles over HTTPS — a tampered update is both a security and a policy problem. See OTA security.
How OtaKit helps you stay compliant
OtaKit ships only your web build and checks the bundle's dependencies at upload time, warning when it detects native code the installed shell doesn't have. The runtimeVersion mechanism keeps bundles matched to compatible shells, so a device never runs a web layer that expects native capabilities it doesn't have.
The through-line across both stores: interpreted web-layer updates are fine; downloading native executable code to change behavior is not. Stay in the web layer.
Where to go next
See Apple guideline 2.5.2 explained for the iOS side, and the complete compliant-OTA guide for both stores together.