Google Play VPN Declarations for a Branded App

A VPN app can intercept traffic. Junk apps have used that to mess with ads, to watch payloads, to pretend to be a 'cleaner.' Play's answer is a short allow-list: core VPN, or exceptions like parental control, enterprise management, device security, network tools, browsers, carrier apps. If you are a consumer privacy VPN, you are in the core-VPN bucket. Say so. Do not dress as a game with a hidden tunnel.

The sensitive-permissions policy (the page at answer/9888170) is the parent. VpnService has its own subsection there and a dedicated explainer (answer/12564964) with a preview of declaration questions. Use both. The parent page also covers other restricted APIs. Do not skip it because you think you only need 'the VPN form.'

Encryption to the tunnel endpoint is mandatory in the policy text. WireGuard, OpenVPN, OpenConnect, and Shadowsocks are how Klox-shaped clients do that job. You still have to tell the truth in the listing: this app creates a VPN tunnel. If the store description reads like a wallpaper pack, you failed documentation even if the binary is honest.

Google's help page says apps using VpnService need to complete the declaration in Play Console, subject to approval. Historically they even published a deadline for existing apps. Your deadline is: before production users, not after a strike.

Process I actually run: (1) freeze the binary that uses VpnService, (2) write listing text that says it is a VPN, (3) ship the in-app disclosure, (4) record two short videos, (5) fill Data safety so it does not fight the declaration, (6) answer the Console questionnaire from the live form, (7) keep a copy of what you submitted. If you change how the API is used, Google says you must submit again. Treat that as true.

I will not invent every label in your tenant. The preview questions include core yes/no, exception categories, a video of the app opening and the VPN being used, what data the VPN service collects or shares, a video of the prominent disclosure, and whether you redirect traffic for monetization. If your form is grouped differently, follow the form.

Google's VpnService help repeats User Data rules. The disclosure must be in the app, shown in normal use, not only a website. It must not require a scavenger hunt through menus. It must say what is accessed or collected through VpnService, and how it is used or shared. It must require an affirmative action — tap to accept, tick a box. It cannot be only a privacy policy. It cannot be mixed into a pile of unrelated consents. Separate screen. VPN-shaped words.

Write like a human. 'This app creates a VPN tunnel to the operator's servers so your device traffic is encrypted in transit. Account email is used to bill and support you. We do not sell your traffic to advertisers.' If you collect more, say more. If you do not run the nodes, do not say 'we operate servers in …' unless that is true. Link the operator notice if that is the honest model.

System VPN dialog is not a substitute. Android's prompt is required to start the service. Play still wants your disclosure first. Two steps. Do not skip yours because the OS has one.

Google's preview asks for a short video (90 seconds or shorter) of the app opening and the VPN being used, with voice-over or captions if it is not obvious. It asks for another showing the prominent disclosure. The guidance block is specific: open the app, walk to the disclosure, show the full text (scroll if needed), show consent including granting VpnService, and show the path when the user does not consent and later sees the screen again.

That last bit is the one teams skip. Record the decline path. If decline does nothing, or if the screen never appears again, you built a trap or a dead end. Fix the app, then shoot.

Upload a YouTube or cloud URL to an MP4 or similar. Unlisted YouTube is fine. A 4K cinematic of a skyline is not. I want a Pixel on a desk and a thumb.

The preview includes whether the VPN service collects or shares data, then a type list that looks a lot like Data safety categories: location, personal info, financial, messages, photos, browsing, crash logs, device IDs, and so on. I am not going to pretend I know every toggle in your Console this week. I am going to tell you to answer from the binary, not from the homepage.

Account email for login is collection. Crash SDK is collection. A payment SDK is collection. Destination hostnames stored for 'analytics' is the kind of collection that fights a privacy brand and may fight policy if you did not disclose. Payload inspection for ads is how you lose.

Data safety is a separate form. Reviewers compare. If declaration says no browsing history and an SDK is logging URLs, you did it to yourself.

Policy: document use of VpnService in the Google Play listing. That means the public description should say this is a VPN app that creates a device tunnel. Not only in a support site. Not only in the declaration form.

Write a short paragraph: what the tunnel is for, platforms, that WireGuard, OpenVPN, OpenConnect, and Shadowsocks are available if that is true for your binary, that a system permission will appear. Do not promise city counts you cannot defend. Do not paste Klox consumer pricing into a partner listing unless it is your price.

Full description and short description both matter. The feature graphic should look like the app, not a hoodie spy. That is the screenshots article. Mention it because listing documentation is words and pixels.

Policy requires encryption from the device to the VPN tunnel endpoint. That is the job of the protocols you ship. Klox-shaped apps use WireGuard, OpenVPN, OpenConnect, and Shadowsocks for that path. You still should not write 'military grade' in the listing. Say encrypted tunnel. If someone wants cipher details, put them in a help article you can keep true.

Split tunnel, if you have it, is a disclosure issue: not all traffic may go through the tunnel. Say so in the app if users can exclude apps. If you cannot exclude, do not screenshot a per-app list.

Google's preview asks whether you redirect or manipulate user traffic from other apps for monetization. The correct answer for a honest consumer VPN is no. If you answered yes, the help text says you are outside allowed use unless you can explain a policy-fitting case. I cannot think of one I want a Klox partner to run.

Ad SDKs in a VPN app are a mess even when they do not touch the tunnel. They create Data safety rows and user distrust. If you must run ads, they still cannot use tunnel payloads. Most brands should just charge money. Klox consumer is a paid product with a refund window. Copy that idea, not a rewarded-ad interstitial on the connect button.

Undeclared VpnService. Declared, but listing never says VPN. Disclosure only in a policy URL. Video of a different app. Video too fast to read. Data safety empty. Exception category selected for a consumer VPN. Monetization left blank by a contractor who did not understand the question. Demo account expired so review could not even reach the disclosure.

None of these are crypto failures. They are packet failures. The same energy as Apple review notes. Slow down.

Policy strikes can sit on the account, not only the app. Do not buy 'aged' Play accounts to skip this. That is how you buy someone else's sins.

Branded VPN launches die when Android is 'ready' and iOS is still waiting on an entitlement, or the other way around, and ads already spend. Play declarations have their own queue. Apple has Guideline 5.4 and Network Extension. Do not paste Data safety answers into App Privacy. Do not paste a Play video into App Review notes and hope.

Build a dual calendar: disclosure screen exists in both clients (the words can match; the UI will not). Play videos recorded. Apple review notes written in the same honest voice. Demo accounts that last. Nutrition labels and Data safety filled from the same SDK inventory. Then submit the slower store first if you cannot afford a split launch. I would rather both be late than one storefront convert people onto a brand that does not exist on the phone they own.

White-label does not merge those queues. You inherit protocol behavior. You own both consoles. If that sentence makes you tired, reseller exists so you can stop.

Operators typically want a status channel and a way to disable a subscriber without a payload log. Confirm what Klox includes on a call. Do not put a fictional Play API path in your runbook because a Stack Overflow answer used one in 2022.

Live policy tabs: 9888170 and 12564964. Binary with VpnService. Listing paragraph that says VPN. Disclosure screen in the first-run connect path. Decline path. Two videos under 90 seconds. Data safety matches SDKs. Declaration answers match the binary. Demo login that lasts through review. Internal note of version code and recording date.

Then have a second human watch the videos without sound. If they cannot explain what the app is, shoot again.

Confirm with Klox on a call what the partner Android build includes. I will not invent endpoint names or an SLA percent for that build. Ask. Write down the answer. Put only that in your own wiki.