Conversation

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
> 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
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.
1