# Google Play

> Android's legality runs through a generic interpreter exemption, and the B2B billing carve-out that exists on iOS does not exist here.

Source: https://miniapp.sollar.com/compliance/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](/platform/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](/reference/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.