Troubleshooting

App content declarations that block your review (and how to clear them)

October 13, 2026 · 4 min read

A hand holding a pen signing a document, close-up shot with focus on the paper.
Photo by Tima Miroshnichenko on Pexels

If your closed testing release won't go to review, or comes back rejected, an unfinished or inaccurate declaration under Policy and programs > App content is a likely cause. Google requires these declarations before closed testing, and they have to match what your app really does. Open that page, finish every task it lists, correct anything that no longer matches the app, and send the changes for review again.

This article is a troubleshooting guide for the declarations themselves. It assumes your account verification is already done.

Why declarations block you

Google says closed testing "requires completing app setup first" (App testing requirements). The App content section is a large part of that setup.

Declarations can block you in two ways:

  1. Not finished. Play Console keeps showing setup tasks, and your release isn't ready to send.
  2. Finished but wrong. The release goes to review and is rejected because a declaration doesn't match the app.

The second one is more frustrating, because everything looked done.

Where to find them

Go to Policy and programs > App content in Play Console. Google lists these declarations there (App content):

  • Privacy policy
  • Ads
  • Sign-in details (app access)
  • Target audience and content
  • Content rating questionnaire
  • Permissions declarations, where relevant
  • News apps
  • Others, depending on your app

The Data safety form is also required for apps on closed, open or production tracks. Only apps that are exclusively on internal testing are exempt (Data safety).

Clearing each declaration

Privacy policy

You need a privacy policy link, even if your app collects nothing. Common problems:

  • The URL returns an error or requires a login.
  • It points to a generic template that never names your app.
  • It's hosted on a document link that isn't publicly viewable.

Use a stable public URL that loads in a private browser window. More detail is in privacy policy for an Android app.

Ads

Answer whether your app contains ads, including ads from SDKs you added. If an SDK can show ads, the honest answer is yes. A mismatch between this answer and what the app does is a frequent rejection reason.

Sign-in details (app access)

If any part of your app needs a login, provide credentials so reviewers can reach it. Google asks you to "provide valid, working login credentials in Play Console so reviewers can fully test your app's features." Before you submit:

  1. Log in with those credentials on a device you haven't used before.
  2. Make sure there is no one-time code sent to your own phone or email.
  3. Make sure the account won't expire during the review.

Target audience and content

Choose the age groups you actually target. If you include children, additional policy requirements may apply, so think about this one carefully rather than ticking every box.

Content rating questionnaire

Answer the questionnaire about your app's content. The answers determine your rating, so they have to reflect what users can actually see, including user-generated content if your app has it. See the content rating questionnaire, explained.

Permissions declarations

Some sensitive permissions need a declaration explaining why the app uses them. If you added a permission you don't need, often through a library, removing it from the app can be simpler than justifying it. That requires a new build with a higher version code.

Data safety

Describe what data the app collects and shares, including what third-party SDKs collect. "No data collected" is only correct if it's true for every library in your build. The Data safety form guide goes through the form section by section.

After you clear them: send for review

Edits to declarations are changes like any other. They collect under "Changes not yet sent for review" until you open Publishing overview and click Send for review. Saving the form alone doesn't submit anything to Google.

Closed release reviews can take "a few hours or up to seven days (or longer in exceptional cases)", according to Google's managed publishing documentation. Your 14 days of testing can't start until the track is published and testers opt in, so every round of fixes pushes your timeline back. Our closed testing timeline shows where this fits.

Keep them accurate after approval

Declarations aren't a one-time task. If you add an ad SDK, a new login method or a feature that collects location, update the matching declaration in the same release. Google also checks "target age group, content rating and store listing accuracy" when you later apply for production access, so a declaration that drifted out of date during the test can hurt you there too.

Quick checklist

  • Every task under Policy and programs > App content is complete.
  • Privacy policy URL loads publicly and names your app.
  • Ads answer matches all SDKs in the build.
  • Reviewer login works without your phone or email.
  • Target audience reflects your real users.
  • Content rating answers match the app's content.
  • Data safety covers third-party SDKs.
  • Changes sent with Send for review in Publishing overview.

If a release was already rejected, reading the policy email and fixing it walks through the rejection itself. Before you start, the closed testing checklist covers everything else you need ready for day 1. Once your track is published, GoPlayTester can supply 12+ real testers for the 14 days; our guide shows the setup.

All articles