Google Play

Google Play has no policy for superapps or mini apps. There is no Android equivalent of Apple’s Guideline 4.7 — no clause that names the category and authorises it.

That is the reverse of what most people assume, and it changes the architecture.

The interpreter exemption

Android’s legality runs through the Device and Network Abuse policy, which prohibits apps from downloading executable code but exempts:

…code that runs in a virtual machine or an interpreter where either provides indirect access to Android APIs (such as JavaScript in a webview or browser).

Every word there is load-bearing:

Phrase	Consequence for Sollar
in a virtual machine or an interpreter	Mini apps are interpreted JavaScript. Never a native code loader, never a dynamically loaded .so or .dex.
indirect access to Android APIs	Every capability reaches Android through the Sollar bridge, mediated and checked. Never a direct binding.
such as JavaScript in a webview	The named example is exactly the architecture. That is not a coincidence; it is why the architecture is this.

All executable code arrives inside the verified package. The CSP floor — script-src 'self', no remote host, no 'unsafe-eval' — is what makes that true. A mini app pulling a script from a CDN is downloading executable code from outside the verified package, which is precisely what the exemption does not cover.

That is why the CSP floor is enforced by the submission validator rather than recommended in a style guide. It is a legal boundary wearing a security control’s clothes.

What has no Android equivalent

Danger

Apple’s 3.1.3(c) enterprise exemption does not exist on Google Play.

Apple exempts apps “sold directly by you to your organization or to other organizations for use by their employees” from the In-App Purchase requirement. Google’s Payments policy has no such carve-out — and it explicitly names the categories a B2B vendor would hope to fall under: “business productivity software” and “cloud software and services” are covered by Play Billing, not exempted from it.

Consequence: on Android the sale must be entirely outside the app — a contract, an invoice, a purchase order between two companies. Never an unlock inside a mini app, never a purchase flow inside Sollar, never a link that steers a user from inside the app to a payment page.

Assuming that what works on iOS works on Android is the single most expensive mistake available on this page.

What remains available on Android, and is what Sollar uses: the customer signs a contract with Sollar, is invoiced, and their employees use the product. No transaction happens in the app or is initiated from it.

Distribution routes

Route	Verdict
Play Store, public listing	The route Sollar uses
Managed Google Play — private apps	Cannot charge anything, and cannot coexist with a public listing. Closed.
Sideloading / APK download	Not a product distribution channel
Alternative stores	Reach without the guarantees, and no help with the billing question

Managed Google Play private apps deserve their line because they look like the answer to tenant-private distribution and are not: a private app cannot charge, and the exclusivity with a public listing means Sollar would have to choose one. Tenant-private mini apps are therefore provisioned inside the single publicly listed Sollar app, by tenant administrators — which is the design in Distribution anyway.

Data safety

Google Play requires a Data safety declaration covering what the app collects and shares — and it covers what mini apps collect through the host.

This is why the manifest’s purpose strings and the permission model matter beyond user experience: Sollar’s Data safety form is assembled from what mini apps are permitted to do, so an over-declared scope in your manifest becomes an over-declaration on a form Google reads.

A permission declared and never used is therefore not a harmless leftover. Remove it.

Target API level

Google Play requires a recent targetSdkVersion and raises it annually. This is Sollar’s obligation, not yours, but it has one consequence you will feel: Sollar’s minSdk moves over time, and the compatibility baseline moves with it — at most once a year, announced at least two release cycles ahead.

WebView versions

Android System WebView updates independently of the OS, through Play. In practice most devices run a recent build, but not all: managed devices with delayed update policies, devices in regions with limited Play services, and a long tail of old hardware run older WebViews.

The baseline is Android System WebView 114+. Below that, Sollar refuses to run mini apps rather than running them unpredictably — a mini app failing in a way its developer never saw is worse than one that does not start.

User Data policy

Google’s User Data policy requires prominent disclosure and consent for sensitive data access, and it applies to what happens inside mini apps.

For you this means the permission prompt and the purpose string are not just Sollar’s mechanism — they are how Sollar meets an obligation on Android. A purpose that does not describe what the app actually does with the data is a policy problem, not only a review finding.

Checklist for Sollar’s own Play submission

1. No mini app path loads native code. Everything is interpreted JavaScript with mediated access.
2. The CSP floor is enforced by the validator; no mini app can load a remote script.
3. No purchase flow of any kind inside the app, and no steering to one.
4. The Data safety declaration matches the permission scopes mini apps can hold.
5. Prominent disclosure and consent for every sensitive scope, at the point of use.
6. The listing describes the mini app model plainly. An unexplained superapp invites the wrong policy reading, exactly as it does on iOS.