What does Google Play's core purpose rule say about proxy functionality?

Under Device and Network Abuse, the Google Play Developer Program Policy states: "Apps that facilitate proxy services to third parties may only do so in apps where that is the primary, user-facing core purpose of the app." The same requirement is repeated on that page in the "Don't" column of the key considerations table, worded slightly differently. It is a rule about what the app is for, not about how well a feature is disclosed.

Does a default-off, opt-in consent flow satisfy the core purpose rule?

They answer different questions. Consent and disclosure govern what a user was told and agreed to; the core purpose clause governs what the app is primarily for. Careful consent practice is worth doing on its own merits and is the first thing a reviewer will ask about, but it does not change an app's primary user-facing purpose, and we know of no published Play decision confirming that a disclosed, default-off integration inside a game or utility satisfies the clause.

2026-09-04 · GetPassive Team · 8 min read

Google Play's core purpose rule, and what it means for a bandwidth SDK in your app

Q: If a third-party SDK breaks a Play policy, who is held responsible?

The developer who published the app. Play policies apply to the app as distributed, including code the developer did not write. Google's guidance on declaring data use puts it directly: "you alone are responsible for making complete and accurate declarations in your app's Play store listing." A vendor's assurance, or an indemnity clause in a vendor contract, may matter commercially but does not restore a suspended listing or a terminated developer account.

If you are evaluating a bandwidth-sharing SDK for an Android app, there is one paragraph in Google's policy you should read before you read anything a vendor sends you — ours included. It is short, its wording is not ambiguous, and it sits above every other consideration: consent design, revenue share, integration effort. None of those matter if the app cannot be listed.

We sell an SDK that routes traffic through the devices of users who have agreed to it. We would rather lose an integration to a publisher who read this clause and decided against it than sign one who finds it after launch and concludes we hid it.

The clause

Google Play Developer Program Policy, under Device and Network Abuse:

> "Apps that facilitate proxy services to third parties may only do so in apps where that is the primary, user-facing core purpose of the app."

It is at support.google.com/googleplay/android-developer/answer/16559646. The same requirement appears again further down that page, in the "Don't" column of the key considerations table: "Don't facilitate proxy services to third-parties unless it's the primary, user-facing core purpose of the app." Both were confirmed on 4 September 2026. Policies get edited, so open the page and read it yourself rather than trusting a date on someone else's blog.

Read the words, not a summary of them. Primary — not present, not optional, not disclosed. User-facing — visible to the person holding the phone, part of what they opened the app for. Core purpose — what the app is.

What that plainly means

A worked example. Three apps, all shipping the same SDK, all with an identical, well-built consent flow.

A VPN or proxy client. Routing traffic is what the user came for. It is the first line of the store listing and the main screen of the app. The clause describes this app.

A puzzle game with a "support the developer by sharing your bandwidth" option in settings. The user came for the puzzles. Bandwidth sharing is a monetisation mechanism, however clearly it is explained. On any ordinary reading of the sentence, it is not the primary, user-facing core purpose.

A file-manager utility with the same option. Same answer.

That is the uncomfortable part for this category, ours included. The clause is not a disclosure rule, so it cannot be satisfied with a better consent screen. A reviewer applying the words as written asks what the app is primarily for, and the most convenient place to find the answer is the publisher's own store listing.

What the public record shows

Two things are documented, and they point in the same direction without settling the question.

The first is enforcement. In January 2026 Google's threat intelligence team published an account of disrupting a large residential proxy network. The relevant sentence for a publisher: "These apps were largely benign in function (e.g., utilities, games, and content) but utilized monetization SDKs that enabled [the] proxy behavior." Google put the number at over 600 applications, and said Play Protect "automatically warns users and removes applications known to incorporate" those SDKs, and blocks future installs. Google described the software as trojanizing — the devices were enrolled covertly, which is not what a disclosed integration does. But note what the sentence says about the host apps: utilities, games and content. The enforcement reached ordinary apps whose function was fine, because of what the embedded SDK did.

The second is Honeygain, whose product is bandwidth sharing and nothing else. Its Android app is not on Google Play, and the company publishes its own explanation on its help site: it says the app was removed under this policy area, quotes the same core purpose clause, and argues that bandwidth sharing is precisely its core purpose. That is one side of a dispute and we only have their account of it. Taken at face value, it is still the most instructive public data point available, because it is a case where the proxy function was the whole app and that did not resolve the question in the developer's favour.

What we could not find is any published Play enforcement action against a bandwidth-sharing integration that was disclosed in the app, opt-in, and off by default. That is an absence, not evidence of safety, and an absence of published decisions is a weak thing to put a developer account behind. The written rule and observed enforcement are two different objects, and we are not going to pretend to know how the second one behaves.

Who carries the violation

This is the part publishers most often get wrong, and it is not a close question.

Play policies apply to your app as distributed. That includes code you did not write. Google spells the principle out in its guidance on declaring data use: "If a third-party SDK or library in your app collects or shares user data, you must reflect this collection and sharing in the Data safety form." The same page removes any ambiguity about where responsibility sits: "you alone are responsible for making complete and accurate declarations in your app's Play store listing."

In practice:

The enforcement email arrives at your developer account, not the vendor's.
The removed listing is your listing. The suspension is yours, suspensions count as strikes, and Google's enforcement process says repeated or serious violations result in termination of individual or related developer accounts — so a second account is not a hedge.
Google allows one appeal per enforcement action. You get a single considered attempt, not an argument over several rounds.
"The vendor told us it was fine" is not a defence recognised anywhere in the policy.
An indemnity clause might get you money later. It does not get your app back, and it does not get a terminated account reinstated.

Any SDK vendor, us included, is asking you to put your listing behind their assurances. Price that accordingly.

If you proceed, what careful practice looks like

None of this satisfies the core purpose clause. It is the work that a reviewer will ask about, that a user deserves regardless, and that gives you something to say if you are ever asked.

Disclosure that is genuinely user-facing. Not clause 14 of terms nobody opens. A screen, inside the app, in the user's language, in the words a normal person would use: your device will carry internet traffic for other people, it will use your connection and your data allowance, here is who receives it, here is what is not touched. The test is simple — could a user who tapped through describe the feature a week later? If not, it was not disclosure. Do not stack it against an unrelated permission prompt, and do not put it in the "rate this app" moment.

Consent that is explicit and default-off. Default-off means no traffic before the tap. Not enabled at install with a toggle buried in settings. Not enabled when the trial ends. If your build routes a single byte before the user has affirmatively chosen it, the flow is opt-out no matter how the screen is worded. Give one control that means yes and one that means no, equally easy to reach, neither pre-selected, and no "Continue" that quietly means yes. Do not gate app functionality on the answer, and do not re-ask on every launch until they relent — coerced consent is exactly what a reviewer is looking for.

Revocation that actually works. In the obvious place in settings, not three levels down. Off takes effect immediately, not at the end of the session or on next launch. No re-prompt for a meaningful period after a refusal. Uninstall stopping everything is not a substitute for an in-app path that works.

A store listing and Data safety form that match the build. If a feature is worth a disclosure screen inside the app, it is strange for the listing to be silent about it — and a reviewer comparing listing to binary should find the same app in both. Declare your configuration, not the theoretical maximum of what the SDK could do, and not less than what your build actually does. Update it when your configuration changes; a form that was accurate at 3.1 and wrong at 4.0 is worse than one that was always cautious. The mechanics of the Play form and Apple's privacy manifest are a separate subject and we cover them separately.

Document it while you build, not when the email arrives

Appeals run on a clock, you get one, and it is read by someone who has your binary and your listing but not your intentions. Assemble the evidence at release time, per release:

The consent copy exactly as shipped, taken from the release strings, with the version it went out in.
A dated screen recording of the flow on a real device, from the shipped build.
The SDK version integrated, plus the vendor's dated written statement of what that version does on the wire.
A network capture from a clean install showing nothing relevant leaves the device before consent, and a second one after revocation showing it stopped.
Your Data safety declarations as submitted for that release, saved next to the rest.
A one-page change log: app version, SDK version, what changed in the flow, what changed in the declarations.

If someone asks what version 4.2.1 did, you want to answer with artefacts from 4.2.1 rather than a description of the build currently on your desk. That file is short, it is assembled once per release, and it is the difference between an appeal with evidence and an appeal with adjectives.

What we will and will not put in writing

We will document, per SDK version and dated: what the SDK transmits, to whom, for whose purposes, what it does not touch, when it starts, and what happens on revocation. Precise enough for your reviewer to hold us to it, and precise enough that you can verify it with a packet capture instead of taking our word.

We will not tell you that the integration is compliant, permitted or approved. That is not ours to decide, it is not any vendor's to decide, and a vendor who tells you otherwise is telling you something they cannot know.

The clause is one sentence. Read it, put your own store listing next to it, and make the call for your own account. If the answer is no, that is a legitimate answer, and we would much rather you reached it now than after launch.