Google Play Developer Policy: A Practical Guide for Small Teams

Google Play's Developer Program Policies cover everything from malware to gambling, and most will never touch your app. The few that do tend to surface as an update rejected in launch week. This guide covers the areas that most often catch small teams, the rule on user-generated content, and what happens when Google enforces. Everything here is from Google's Play Console Help pages as of 20 September 2026.

The short version

• User data is the area most teams meet: a privacy policy, an accurate Data safety form, and account deletion if users can create accounts.
• You are responsible for every SDK in your app, including what it collects and what it shows.
• If other users can see what people post in your app, the user-generated content policy expects terms of use, moderation, in-app reporting and, for public content, blocking.
• Enforcement runs from a rejected update to a terminated account. The Policy status page in Play Console shows where you stand.

How the policies are organised

As of 20 September 2026, the Policy Center groups the policies under headings from Restricted Content and Intellectual Property to Privacy, Deception and Device Abuse; Monetization and Ads; Store Listing and Promotion; Spam, Functionality, and User Experience; Families; and Enforcement. Each page has a summary, then the full policy, which wins where they differ. Policies change, and the Policy Center keeps a section called Updates and Other Resources for what is new to skim before each major release. If you also ship on iOS, see our guide to the App Store Review Guidelines.

User data and permissions

As of 20 September 2026, Google's User Data policy is where most small teams meet the policies in practice:

• A privacy policy, linked in Play Console and inside the app, naming the developer or the app, covering collection, use, sharing, retention and deletion, on a public URL that is not a PDF.
• An accurate Data safety section that matches the privacy policy. See our guide to the Data safety form.
• Prominent in-app disclosure and consent where you access personal and sensitive data in ways users would not expect.
• Account deletion from inside the app and from a web page linked in Play Console, if users can create accounts. Freezing an account is not deletion.
• Third-party code in your app, and its providers' handling of your users' data, must comply too.

The policy on permissions and APIs that access sensitive information lets you request them when they are necessary for current features promoted in your listing, ideally in context so users understand why. Some are restricted further: SMS and Call Log permissions are for apps registered as the default SMS, Phone or Assistant handler. Before each release, read your merged manifest, including what libraries added, and remove what you cannot explain.

User-generated content

This policy most often surprises a team that adds an in-app feedback board. As of 20 September 2026, Google's User Generated Content policy defines user-generated content as content that users contribute to an app and that is visible to or accessible by at least a subset of the app's users. Apps with it must have robust, effective and ongoing moderation that:

1. Requires users to accept the app's terms of use or user policy before they create or upload content.
2. Defines objectionable content and behaviour in those terms, and prohibits it.
3. Moderates in a way that fits the content, including an in-app system for reporting and blocking objectionable content and users, and acting on reports where appropriate.
4. Keeps in-app monetisation from rewarding objectionable behaviour.

The duties scale with the kind of content:

• Apps for a verified group, such as one school or company, must offer in-app reporting of content and users.
• Features for one-to-one interaction, such as direct messages, tagging or mentions, must offer in-app blocking.
• Apps with publicly accessible content, such as social networks, must offer in-app reporting of users and content, and blocking of users.

Google's examples of violations include an app that continually fails to address complaints about objectionable content. The policy also expects accurate answers about user-generated content in the content rating questionnaire.

Does a feedback board count?

The definition turns on visibility. This is our reading, not Google's:

• A private form, where a message reaches your team and no other user, works like a support channel and does not fit the definition.
• A board other users can read is content visible to a subset of your users. We would treat it as user-generated content, and an open board in a public app as publicly accessible, which brings in terms of use, reporting and blocking.

Most voting boards are the second kind, because showing other people's requests is what stops duplicates. Plan moderation for one as you would for comments.

Deceptive behaviour and metadata

Google's Deceptive Behavior policy asks for an accurate description, images and video of what the app does, bans mimicking system warnings or other apps, and requires consent for any change to device settings. The Metadata policy, as of 20 September 2026, caps the title at 30 characters; bans emojis, repeated special characters and ALL CAPS (unless it is your brand) in the title, icon and developer name; and bans claims of rank or awards, prices or promotions, and unattributed or anonymous user testimonials in the description. That last point matters if you collect praise through an in-app channel: quoting "a user" is not allowed.

Subscriptions and families

The Subscriptions policy asks you to disclose price, billing frequency, renewal terms and whether a subscription is needed to use the app, up front. Google's examples of violations include an annual plan shown mainly as a monthly cost, and a dismiss button that is hard to see. The app must also show how to manage or cancel, for example with a link to Google Play's Subscription Center.

If any target age group you declare includes children, the Families policies apply. They cover content, ads, data and SDKs: apps aimed at children alone must not transmit the advertising ID or hardware identifiers, and must not include SDKs not approved for child-directed services.

When Google enforces

As of 20 September 2026, Google's Enforcement Process page says reviews combine automated and human evaluation, and that a notice may not list every violation, so fix the class of problem, not just the example. The actions, from mildest:

Google emails you each action with instructions on how to appeal. In Play Console, the Policy status page shows active enforcement for each app: "No issues found" means there is nothing to do, and a suspended app has an Appeal button there. Google's page on managing policy violations and appeals says it reinstates apps when it made an error and finds no violation.

Fixing and resubmitting

Google's help page for removed apps says you can usually fix the issue and resubmit yourself. Read the policy named in the notice, check the rest of the app too, and upload the fixed bundle to every track, including internal, closed and open testing, deactivating the non-compliant bundles. If you leave one active, the resubmission fails. A warning comes with a deadline in days, after which the app is removed. Our guide to publishing on Google Play covers the release steps around review.

How FeedbackKit fits in

FeedbackKit puts a feature request board inside your app, where users post, read, vote and comment. By our reading above, that is publicly accessible user-generated content in a public app, so plan for it.

Here is how that looks in FeedbackKit, with sample data from a fictional hiking app:

To be plain about where things stand on 20 September 2026: the FeedbackKit SDK screens, including the Kotlin ones, don't include a report button, user blocking or a filter for objectionable text. What you do have:

• In the native admin apps for iPhone, iPad and Mac you can remove a comment. In those apps or the web dashboard you can reject a request, and project owners and admins on Pro and Team can delete a request outright.
• The Kotlin SDK's list composable can show a single status, for example Approved, so new requests appear to other users after your team has reviewed them. Comments on a shown request are still visible.
• You choose where the board appears, so you can put your terms of use and a support contact next to it.

That covers removal, a form of pre-review and contact details. It does not cover in-app reporting or blocking, which Google's policy asks for when content is publicly accessible. Without them in the SDK, add your own: a "Report a post" link that opens an email to your support address, terms that users accept before posting, and a written process for acting on reports quickly. Setup is in the Kotlin docs, and the same board works from Flutter and React Native.

If you want users to vote instead of repeating themselves in reviews, start free.