Skip to content
GetClosedTesting
LoginStart Testing

Permissions Declaration Form: Why Your Closed Test Stalls

A restricted permission can hold your test release in pending publication for weeks, before the 14-day clock starts. What to strip, what to declare.

Google Play Testing14 min read

What the Permissions Declaration Form does to a closed test

The Permissions Declaration Form is a release gate for high-risk permissions, and it runs on the app bundle you upload, not on the track you upload it to. A closed test build that requests broad app visibility, all files access, background location, SMS or Call Log, or photo library access can be held in pending publication while Google reviews the justification. Google's wording is that the review “may require up to several weeks to process”, and during that window the release is not published: testers cannot install it, and the 14-day clock has nothing to count.

That is the part most guides miss. Articles about this form usually frame it as a production problem for apps that ship dangerous permissions. In practice, a new developer with 12 testers waiting hits it on the closed track, because the closed track is the first place a real app bundle is uploaded, and because one alert on the App content page blocks every publishing action on the app, including store listing edits.

This guide covers which permissions trigger the form, the two ways out (declare or strip), what each step of the form actually asks for, and how to sequence the work against the 12-tester requirement so a permission review does not eat the first two weeks of your timeline. Every policy claim below is sourced to Google's Play Console documentation, verified on 8 November 2026.

Which permissions trigger the declaration form

The form is generated from your bundle. When you add an app bundle that requests a restricted permission for which Google Play holds no current declaration, the form appears during the release process and an alert appears under App content. These are the permissions that most often trigger it for apps built with AI builders and cross-platform frameworks, which tend to inherit permissive manifests from plugins.

  • QUERY_ALL_PACKAGES — broad app visibility. Google treats the inventory of installed apps as personal and sensitive data, and permits the permission only where core functionality needs awareness of any and all installed apps, such as device search, antivirus apps, file managers and browsers.
  • MANAGE_EXTERNAL_STORAGE — all files access, for apps targeting API 30 or higher. Allowed only where platform intents such as the Storage Access Framework are not sufficient.
  • READ_MEDIA_IMAGES and READ_MEDIA_VIDEO — for apps targeting API 33 or higher, only where the Android Photo Picker is not sufficient.
  • ACCESS_BACKGROUND_LOCATION — background location, which carries the heaviest paperwork: the form, a video demonstration, a prominent in-app disclosure, and a privacy policy both in the app and on the store listing.
  • SMS and Call Log permission groups — READ_SMS, RECEIVE_SMS, READ_CALL_LOG and relatives. Your app must be registered as the device's default SMS, Phone or Assistant handler before it may even declare them.
  • REQUEST_INSTALL_PACKAGES — installing packages, permitted only where installation is part of core functionality such as file transfer, backup and restore, enterprise device management or a browser. Using it to self-update is not permitted.
  • Health Connect data types — health data access runs through its own declaration and review path.
  • VpnService — allowed only where VPN is core functionality, with the use documented on your store listing and traffic encrypted to the tunnel endpoint.

The reliable check is the merged manifest, not your source tree. A Unity, Capacitor, Flutter or React Native build can inherit a permission from a plugin, and an AI-generated Android project can arrive with broad storage or package visibility already declared. Build the release bundle, then dump the manifest from the AAB with bundletool dump manifest --bundle app-release.aab before you upload, and compare the permission list against what the app actually does.

Why a test-track bundle triggers the same review as production

Google's release documentation is explicit about the scope: “If you have an active app bundle that requires a Permissions Declaration, including releases on the Open, Closed, or Internal test tracks, an alert is displayed on the left menu under App Content. You cannot publish any changes to your app, including changes to your Store Presence (for example, Store Listing, Pricing, and Distribution) until you address this alert by creating a release that includes a Permissions Declaration or removes the permissions.”

Two consequences follow, and both cost time. The first is that permission review is not a production-only step — your first internal or closed build can trigger it. The second is that the alert is not scoped to the release that caused it. It blocks unrelated work such as fixing a store listing, adding screenshots or changing pricing, so a permission problem can stop you from preparing the listing you need before the test can start anyway. It also stacks on top of the pre-review checks that decide whether a release goes live at all.

Google's background location article adds the same point from the review side: “app bundles or APKs across all active release tracks (including closed and open tracks) are subject to review.” A test build is not a private sandbox as far as permission policy is concerned.

One piece of housekeeping is worth doing regardless. Google advises developers to “consider deactivating any Open, Closed, or Internal testing tracks that are not currently in use if they are not compliant with this policy.” An old internal build from a prototype, still carrying MANAGE_EXTERNAL_STORAGE, keeps the alert alive and keeps blocking publishing.

The order to do it in

  1. Build the release bundle and inspect the merged manifest.
  2. Remove every restricted permission the app does not need, and rebuild.
  3. Upload the clean bundle, or complete the Permissions Declaration Form for the permissions you are keeping.
  4. Wait for the release to leave pending publication. Only then is the build live on the track.
  5. Send the opt-in link and confirm testers show as opted in, not merely invited.
  6. Start counting: 12 opted-in testers held continuously for 14 days before you apply for production access.

Decide first: strip the permission or declare it

Google gives an unusually direct instruction for the case where speed matters: “If you need to urgently release an app update, you must remove the high-risk or sensitive permissions from your app bundle and roll out a new release. This new release would only be reviewed for standard compliance with policies, and be published within several hours.”

Read that against “up to several weeks” and the decision is usually already made. A permission review is worth entering when the permission is genuinely part of your app's core purpose. It is a bad trade when the permission arrived by accident, because you are then asking Google to approve a feature you cannot describe in your own listing.

Four questions, in order:

  1. Is the feature in your store description? Google requires core functionality to be prominently documented and promoted in the app's description. If the permission supports something your listing does not mention, the declaration fails on its own terms.
  2. Is there a scoped API that does the same job? The Photo Picker instead of READ_MEDIA_IMAGES, the Storage Access Framework instead of all files access, targeted package queries instead of QUERY_ALL_PACKAGES, the SMS Retriever API instead of READ_SMS, foreground instead of background location, the in-app updates API instead of REQUEST_INSTALL_PACKAGES.
  3. Did a library add it? Check the merged manifest before rewriting any code. Removing an inherited permission is a manifest line with tools:node="remove", not a product decision.
  4. Can version one ship without the feature? A closed test exists to get 12 testers opted in for 14 days. Cutting a permission and shipping a smaller build in hours usually beats waiting weeks for an approval that may not arrive.

Our rule of thumb: if the permission is not in your store description, strip it. Declarations succeed on apps whose entire purpose is the restricted feature — a file manager, a phone dialler, a fitness tracker that records runs — and fail on apps that use the permission for convenience.

What each step of the form asks for

The form has seven steps. Each maps to something a reviewer will check, so treat them as evidence rather than paperwork.

  1. Evaluate requested permissions. Previously declared permissions carry a checkmark; newly requested ones carry an alert. If a permission you do not want appears here, Google's instruction is to remove that bundle and upload one with the correct permissions before continuing.
  2. Specify core functionality. You select from a list of supported use cases. This is where most rejections originate: the use case must match what the app actually does, and the permission must be required for it.
  3. Instructions for review. If demonstrating the functionality needs a path through the app, describe it here.
  4. Video demonstration. Required, not optional. A YouTube link is preferred; a cloud storage link to an mp4 is also accepted. Show the feature that needs the permission, including the permission prompt and the behaviour it unlocks.
  5. Instructions for restricted content. If the app requires sign-in, provide a test account. Google's instruction is to provide only credentials used for testing, never a real user's. Our guide to reviewer test credentials for app review covers what a usable sign-in block looks like.
  6. Multi-APK exception. Appears only for multi-APK configurations where an APK variant requests Call Log or SMS access and old APKs can no longer be changed. AAB-only projects skip this step.
  7. Confirm. Tick the boxes confirming the declaration is accurate and that you accept the terms for the permissions declared.

The pattern across all seven is the same question: is the permission required by the app's stated purpose, and can you prove it on video? An app that requests all files access in order to save a PDF fails that test no matter how well the form is written.

What happens after you submit

The declaration is not a form you file and forget. Once you complete it and roll out the release, the app enters an extended review by the Google Play team, in addition to the standard compliance review. While that runs, the release sits in pending publication.

Three operational details matter:

  • Overriding adds delay. Google warns that if you override a pending publication with a new release, you may see additional delays to the review.
  • The Publishing API will refuse the release. Rolling out through the Play Developer Publishing API before approval returns an error. Upload and roll out through the Play Console web UI for the release that carries the declaration.
  • New permissions need a new form. Previously declared permissions keep their checkmark, but any permission the app has not declared before requires a revised declaration, completed in the UI.

Approval and rejection emails go to the account owner and the contact address on the developer account. If the request is rejected, the app stays unpublished until you fix the compliance problem or remove the permission — there is no partial approval that lets the build through.

Five ways this goes wrong

  1. Declaring a permission you do not use. Google's policy text is blunt: “Deceptive and undeclared uses of these permissions may result in a suspension of your app and/or termination of your developer account.” A declaration padded to cover a library's permission is a compliance risk, not a shortcut.
  2. Uploading a new bundle mid-review. The new bundle overrides the pending publication, and Google states this adds delay to the review. Finish the declaration on the version you actually sent.
  3. Leaving non-compliant builds in an active track. The alert follows the app bundle, so an old internal build with the permission keeps blocking publishing until it is superseded or the track is deactivated.
  4. Treating background location like the other permissions. It needs four artefacts, not one: the declaration form, a video, a prominent in-app disclosure, and a privacy policy in the app and on the listing. Missing any one is a rejection.
  5. Recruiting before the release is live. If testers open the opt-in link while the release is still in pending publication, they land on an unavailable listing. Our breakdown of why your app is not visible during closed testing covers the other causes of that same symptom.

The 2027 changes worth planning around

Google has published changes to the same policy that take effect after this article's verification date, and they add declarations rather than remove them. Effective 27 January 2027, apps targeting Android 17 (API 37) or higher must use the Android location button for one-time or infrequent location requests, and must submit a Play Console declaration to use ACCESS_FINE_LOCATION at all, justifying why coarse location or the location button is insufficient. The same date restricts broad access to contacts, with the Android Contact Picker as the expected route for apps that do not need broad access for core functionality.

Two further dates: effective 25 August 2027, apps targeting Android 18 (API 38) or higher must submit a declaration to use the manage contacts permission, and apps targeting Android 17 or higher must declare local network permission. If your build targets 2027 API levels, design the manifest without those permissions now rather than discovering the requirement in the middle of a closed test. Broad contacts access is already restricted enough that most apps should not be asking for it at all — see our notes on the contacts permission policy for the narrower path.

Sequencing this against the 12-tester clock

Permission review has no published service level. Google says up to several weeks, which is compatible with four days and with a month. The 14-day clock, by contrast, is exact, and the requirement is 12 testers opted in continuously for the 14 days before you apply.

So do the permission work before recruiting. Build, inspect the manifest, strip what you do not need, upload, and wait until the release is genuinely live on the closed track. Only then send the opt-in link and treat the test as started.

Based on our analysis of 1,500+ closed-testing campaigns, releases that stall before a single tester opts in are usually waiting on an App content declaration rather than a build defect — a permission prompt that never resolved, or a release that never left pending publication. The symptom is identical in both cases: testers report the app is unavailable and the developer assumes the link is broken.

If the release is already live and the clock is running, do not push a new bundle carrying an unresolved restricted permission mid-window. The risk is the live release being replaced by one that is not published, and the drop-below-12 rules are already unforgiving without adding a permission review to the middle of the 14 days.

Does the Permissions Declaration Form apply to internal testing?

Yes. Google's release documentation covers bundles on the Open, Closed and Internal test tracks, and the App content alert appears for any of them. That is why Google also suggests deactivating unused test tracks that are not compliant: the alert follows the bundle, and an internal build is enough to trigger it.

Can testers install my app while the declaration is in review?

No. The release stays in pending publication until the declaration is reviewed, so the track has no published build for testers to install. An opt-in link that opens an unavailable listing during this window is expected behaviour, not a broken link.

How long does a permissions declaration review take?

Google says the request “may require up to several weeks to process” and publishes no fixed number, so treat any specific figure you read elsewhere as guesswork. Removing the permission is the only route with a stated fast path: a release without it is reviewed for standard compliance and, in Google's words, published “within several hours”.

I removed the permission but the alert is still in App content. Why?

The alert is tied to an app bundle in an active release, not to your source code. Uploading a clean bundle normally clears it once that release is the one on the track, but any older bundle still present in an active track keeps the alert alive until it is superseded or the track is deactivated. Check App bundle explorer for which version is active before assuming the fix failed.

Does a permission review reset the 14 days?

It does not reset the count the way a tester opting out does. What it does is stop the clock from starting, or interrupt a running test if the release is no longer available to testers. The days only count while 12 testers are opted in to a live closed test.

Do I need the form again for the next release?

Not for permissions you already declared — those show a checkmark in later releases. You do need a revised declaration for any permission the app has not declared before, and Google requires that revision to be completed in the Play Console UI rather than through the API.

Sources

Ready to Start Your Closed Test?

Register, create the app and choose your tester count. Every plan includes the same monitoring, support and participation guarantee.

Start TestingView Pricing