1. Restricted permissions are Play's extra gate on Dangerous, Special, Signature, and the families documented under Permissions and APIs that Access Sensitive Information. Data reached through those permissions is personal and sensitive: request only what a current, store-listed feature needs, ask incrementally, honor a deny, and never sell the data or use it for an undisclosed purpose. The Permissions Declaration Form is how Play Console collects that justification and approval before a high-risk permission stays in a published artifact. Primary policy: Play Console Help, "Permissions and APIs that Access Sensitive Information" (https://support.google.com/googleplay/android-developer/answer/16558241). Form workflow: "Declare permissions for your app" (https://support.google.com/googleplay/android-developer/answer/9214102).
2. The form is triggered by the binary, not by a checkbox you remember to tick. After you add an Android App Bundle, Play evaluates the requested permissions during Prepare and roll out a release (https://support.google.com/googleplay/android-developer/answer/9859348). If the bundle asks for high-risk or sensitive permissions — Help's examples are SMS or Call Log — and no declaration is on file, the Permissions Declaration Form appears in that release flow. Policy → App content → Permissions and APIs (or the high-risk / sensitive-permissions declaration Play shows when the permission is already in the merged manifest) is the standing place to Start or Manage the same form. An active bundle on production, open, closed, or internal that still requests an undeclared high-risk permission raises an App content alert and can block publishing, including store-listing edits, until you declare or remove the permission. Publishing API rollouts error until Play has approved the use; Help says finish the form in the Play Console web UI, then complete the rollout there. Whenever the app requests a new restricted permission, you must submit a revised form that addresses that permission.
3. Treat this as one form process that covers several permission families — not a substitute for the dedicated QUERY_ALL_PACKAGES or Accessibility FAQ entries. Families that commonly open the form: SMS and Call Log groups (READ_SMS, SEND_SMS, RECEIVE_SMS, READ_CALL_LOG, and related; default SMS, Phone, or Assistant handler required — https://support.google.com/googleplay/android-developer/answer/10208820); AccessibilityService (complete the accessibility declaration; only genuine disability tools may set isAccessibilityTool=true); QUERY_ALL_PACKAGES (declare it together with any other high-risk permissions; prefer a targeted <queries> manifest if that is enough); Photo and Video READ_MEDIA_IMAGES / READ_MEDIA_VIDEO when the app targets API 33+ and the Android Photo Picker is not sufficient for core functionality (https://support.google.com/googleplay/android-developer/answer/14115180 and https://support.google.com/googleplay/android-developer/answer/15800983); All files access (MANAGE_EXTERNAL_STORAGE); REQUEST_INSTALL_PACKAGES; and Health Connect / granular health permissions. Audit the merged manifest, including SDK-injected uses. If a minimum-scope alternative covers the feature — Photo Picker, SMS Retriever API, targeted <queries>, Storage Access Framework or MediaStore — remove the restricted permission instead of declaring it.
4. Console path and the seven Help steps: open the app → Policy → App content → Permissions and APIs → Start (or Manage). Or complete the same wizard when the release flow shows it after upload. Step 1: evaluate the permissions Play detected on the artifact — this list is what reviewers will hold you to, not an older draft. Step 2: specify core functionality from the supported use-case list; select only the checkboxes that apply. Step 3: write review instructions that take a stranger to the screen that needs the permission. Step 4: provide a short video that demonstrates that core functionality (and any required in-app disclosure). Step 5: if the feature is login-gated, give working App access credentials and navigation. Step 6 (multi-APK only): request an exception for old APKs you can no longer change — Help documents this field for SMS/Call Log leftovers; list version codes. Step 7: confirm the declaration is accurate and that you agree to the appropriate-use terms. Then finish preparing the release. Same steps: https://support.google.com/googleplay/android-developer/answer/9214102.
5. Declare accurately. Play defines core functionality as the main purpose of the app: without the feature that needs the permission, the product is "broken" or unusable, and that purpose plus its core features must be prominently documented in the store listing. The form, the listing, and the code must tell the same story. Do not pick a nearby approved use case because it is easier to get through review. Do not leave placeholder permission text in the manifest. If you change how a restricted permission is used, submit the form again with current information. Restricted-permission data may be used only for the declared core features — not advertising, marketing, or improving unrelated apps. When a user declines a non-critical permission, honor that choice and offer a reasonable alternative (manual entry instead of reading a log, for example).
6. Common rejections and the usual fixes: (a) an SDK silently added SMS, Call Log, QUERY_ALL_PACKAGES, READ_MEDIA_IMAGES, or MANAGE_EXTERNAL_STORAGE — remove or replace the SDK, or strip the permission with tools:node="remove", then upload a new bundle; (b) the form is missing, stale, or describes a different use than the code — update Policy → App content and resubmit; (c) the store listing describes a single-purpose utility while the binary requests a default-handler or broad-access permission — either the listing or the permission is wrong; (d) Photo/Video or package-visibility declared when Photo Picker or <queries> is enough — drop the permission; (e) missing, outdated, or off-feature video / review instructions; (f) a login-gated core feature with empty App access; (g) an old APK still on a testing track that carries the permission; (h) a Publishing API rollout attempted before the web-UI form was approved; (i) usage changed and the form was not filed again. Apps that fail the policy test or lack a Permissions Declaration Form may be removed from Google Play. Deceptive or undeclared use can suspend the app or terminate the developer account.
7. Plan the extra review. Help evaluates the declaration as part of release review; a high-risk permission can keep the new artifact in pending publication until the use case is approved. Do not try to skip the form by uploading another release on top of a pending one — Help warns that overriding a pending publication can add delay. If you need an urgent policy-unrelated fix, ship a bundle that no longer requests the undeclared permission. Keep every active track honest: Play reads the merged manifest on internal, closed, open, and production, not only the build you meant reviewers to see.
8. Pre-submit checklist: (a) dump the merged manifest on every track and list every restricted permission, including ones an SDK added; (b) drop any permission a minimum-scope alternative can replace; (c) complete Policy → App content → Permissions and APIs with use cases that match the listing and the code; (d) attach a current video plus review / App access instructions that actually reach the feature; (e) resubmit the form after any use-case change; (f) do not roll out a new high-risk permission through the Publishing API until the web-UI form is approved; (g) re-read https://support.google.com/googleplay/android-developer/answer/16558241, https://support.google.com/googleplay/android-developer/answer/9214102, https://support.google.com/googleplay/android-developer/answer/10208820, and https://support.google.com/googleplay/android-developer/answer/14115180 after any manifest, SDK, or handler-role change.