So for example, if you ship a Python interpreter and use it to run Python code that's shipped with your app via the App Store, you're not breaking the rules. If you dynamically download code that's fed into the interpreter, you're almost certainly breaking the rules. Since this
Conversation
This rule makes sense for Python which has external world bindings but not for e.g. Lua unless you bind it in ways that could be abused.
1
Google's policy is worded to permit meaningfully sandboxed code. However, there are a massive number of apps in clear violation of it. They don't really enforce the rules. Apple enforces it a lot more, but not so much for major apps where it'd cause a big fuss. It's arbitrary.
1
1
Can't link Apple's policies because viewing it seems to require a developer account. This is the Play Store policy:
support.google.com/googleplay/and
> An app distributed via Google Play may not modify, replace, or update itself using any method other than Google Play's update mechanism.
1
> Likewise, an app may not download executable code (e.g. dex, JAR, .so files) from a source other than Google Play. This restriction does not apply to code that runs in a virtual machine and has limited access to Android APIs (such as JavaScript in a webview or browser).
1
1
A huge portion of apps on the Play Store are in violation of this rule. Termux is switching to using apk-based packages so that it's no longer in violation of the rule. It's really not enforced much. Apple rules are worded in a way that's it's hard to say if they are more or
1
less restrictive. They intentionally worded it in a way that's very unclear and open to interpretion. They enforce the rules far more though, unlike Google's almost non-existent enforcement especially of this rule. Otherwise, apps like Termux would be long gone from Play Store.
2
Why would Termux use Play Store anyway rather than sideloading? The whole point is to sideload so it doesn't make sense to have sideliading off but use it...
1
The technical-level enforcement (which is primarily an exploit mitigation and anti-persistence mechanism) impacts them either way which is why they need to move to using apks instead of debs. Their package manager will learn to prompt you to install apks via OS package manager.
1
1
Apps targeting API 29+ are forbidden from running executables from app data and need to bundle them with their apk for the package manager to extract. Can still map libraries from app data but that will go away.
Play Store enforces API 28+ and increments it yearly (29+ in Nov).
1
Sideloaded apps don't have a minimum target API level enforced, but there's a soft requirement of API 23+ with a warning for older apps (API 28+ on GrapheneOS). Since this is how backwards incompatible privacy/security changes are done, it's a major loophole for sideloaded apps.
One of the reasons Epic wanted to avoid the Play Store so strongly was so that they could use the legacy permission model rather than runtime permissions. Android 10 added first launch permission review for API < 23 apps but there are many other privacy changes from API level.