Google Play policy restricts it. Apps cannot update themselves through methods other than Google Play's update mechanism, and downloading executable code from outside Google Play is restricted. Code running in a virtual machine or interpreter that gives indirect access to Android APIs, such as JavaScript in a webview, is excepted.
What the policy text says
From Google Play's Device and Network Abuse policy page:
- Apps and their third party SDKs must not improperly access or interfere with devices, networks, APIs, services, other apps, or Google services.
- Apps cannot update themselves by methods other than Google Play's update mechanism.
- Downloading executable code from outside Google Play is restricted. Code running in a virtual machine or interpreter that provides indirect access to Android APIs, such as JavaScript in a webview, is an exception.
- Code that introduces or exploits security vulnerabilities is not allowed.
- Installing other apps without the user's prior consent is prohibited.
- Apps cannot circumvent Android sandbox protections to derive activity or identity from other apps.
The page I read does not cover the Malware or Mobile Unwanted Software policies, so check those separately for the full picture.
Same idea as the iOS rule, different wording
Both major mobile stores want the reviewed package to be the thing that runs. The iOS guideline is phrased as a prohibition on downloading or executing feature changing code. The Play policy is phrased around self updates and executable code from outside Play, with an interpreter exception. Neither is a licence to build a plugin system by downloading native code.
| Design | Likely position |
|---|---|
| Update through Google Play | Fine |
| App downloads its own replacement package | Restricted |
| Native code fetched from your server | Restricted |
| Scripts inside a webview or interpreter | Excepted where access to Android APIs is indirect |
| Server-side plugins, app shows results | Generally clear |
This is a reading aid. Confirm against the current policy before you ship.
Security reasons to like the rule
- A second update channel is a second thing to secure. If it is compromised, the store's review does not help.
- Downloaded code can be swapped for different code per user.
- Without a store signature check on the new code, integrity depends on your own implementation.
If your app genuinely needs extensibility, prefer server side logic, signed configuration data, and interpreters with tightly limited access to device APIs.
SDKs count too
The policy applies to apps and their third party SDKs. An advertising or analytics SDK that fetches and runs code can put your app out of compliance without a line of your own code doing it. Review each SDK for update and download behaviour, and ask suppliers directly.
A review checklist for your release
- List SDKs and their versions from your build.
- Search for dynamic class loading, runtime downloads and custom update routines.
- Confirm the app updates only through Play.
- Check webview settings, especially JavaScript interfaces that expose native methods.
- Run static analysis on the release build, not only on source.
Try it yourself
Click through it at your own pace, or open it full screen. Look at how findings point to the exact line, which is where dynamic code loading would show up.
Safeguard has an Android app and dependency scanning for the SDKs in your builds. A free scan shows the dependency view.
Quick check
Can an Android app update itself outside Play?
The policy says apps cannot update themselves by methods other than Google Play's update mechanism.
Is JavaScript in a webview banned?
No. Code in a virtual machine or interpreter that gives indirect access to Android APIs is an exception.
Does the rule cover SDKs?
Yes. The policy names apps and their third party SDKs.
Sources
Last reviewed: 19 October 2026.
