1. What the policy actually is. Google Play treats All files access as a high-risk special app access. "Google Play restricts the use of high-risk or sensitive permissions, including special app access called All files access. This is only applicable to apps that target Android 11 (API level 30) and declare the MANAGE_EXTERNAL_STORAGE permission, which is added in Android 11. Also, this policy does not impact the usage of the READ_EXTERNAL_STORAGE permission." (https://support.google.com/googleplay/android-developer/answer/10467955)
2. If you do not need it, you must take it out of the manifest. This is the single most common fix for a permission-related review rejection: "If your app does not require access to the MANAGE_EXTERNAL_STORAGE permission, you must remove it from your app's manifest in order to successfully meet the policy review requirements. Details on policy-compliant alternative implementations are also enumerated below." (https://support.google.com/googleplay/android-developer/answer/10467955)
3. If you do need it, the declaration is mandatory - and skipping it is itself a violation. "If your app meets the policy requirements for acceptable use or is eligible for an exception, you will be required to declare this and any other high-risk permissions using the Permissions Declaration Form in Play Console." And: "Apps that fail to meet policy requirements or do not submit a Permissions Declaration Form may be removed from Google Play." (https://support.google.com/googleplay/android-developer/answer/10467955)
4. The bar is "no effective alternative", not "it is convenient". "You should only access the All files access permission when your app cannot effectively make use of the more privacy-friendly best practices, such as the Storage Access Framework or the MediaStore API. Keep in mind that your app shouldn't declare permissions that it doesn't need or use." (https://support.google.com/googleplay/android-developer/answer/10467955)
5. Core functionality is defined by Google, and it has to be visible in your store listing. "Additionally, the app's usage of the permission must fall within permitted uses and must be directly tied to the core functionality of the app. Core functionality is defined as the main purpose of the app. Without this core functionality, the app is "broken" or rendered unusable. The core functionality, as well as any core features that comprise this core functionality, must all be prominently documented and promoted in the app's description." "When an app's core functionality requires All files access permission, the developer must complete the Permissions Declaration Form and receive approval from Google Play." (https://support.google.com/googleplay/android-developer/answer/10467955)
6. The permitted use list, and its asterisk. "For apps requesting access to the All files access permission, intended and permitted use includes file managers, backup and restore apps, anti-virus apps, and document management apps." The policy table adds: file management ("App's core purpose involves the access, editing, and management (including maintenance) of files and folders outside of its app-specific storage space"), backup and restore ("App must have a need to automatically access multiple directories outside of its app-specific storage space for the purpose of backup and restore"), anti-virus ("App's core purpose is to scan the device and provide anti-virus security features to the device user"), document management ("Apps that must locate, access, and edit compatible file types outside of their app-specific or shared storage"), on-device search, disk/folder encryption and locking, and device migration/phone transfer. Every row carries the footnote "* Subject to Google Play review and approval", and "Apps granted access to this permission may not extend its use to undisclosed or invalid purposes." (https://support.google.com/googleplay/android-developer/answer/10467955)
7. What earns a temporary exception. "Google Play may provide a temporary exception to apps that do not qualify as permitted use designated above, when: The use of the permission enables the app's core functionality. There is currently no alternative method to provide the core functionality, or the use of privacy-friendly alternatives (for example, MediaStore API or Storage Access Framework) has a substantially detrimental impact on the critical features of the app that are tied to the core functionality. The impact on user privacy is mitigated by security and privacy best practices." The closing condition is on you: "The developer must justify in their Console declaration why the Storage Access Framework or MediaStore API is not sufficient for their app's purpose." (https://support.google.com/googleplay/android-developer/answer/10467955)
8. Uses Google has already ruled out. "Below is a list of common use cases that won't be permitted to request the MANAGE_EXTERNAL_STORAGE permission: Media Files access (see Alternatives below); Any File selection activity where the user manually selects individual files (see Alternatives below)." Note that the list is illustrative only: "This list is not exhaustive. For in-depth guidance, refer to the All files access documentation and Scoped storage best practices guidance for developers." (https://support.google.com/googleplay/android-developer/answer/10467955)
9. The two replacements, and why they are usually enough. For media, "With the MediaStore API, apps can contribute and access media that's available on an external storage volume without the need for the access All files permission. With the MediaStore API, users can easily retrieve and update media files. These files remain in the external storage volume on the user's device - even after the app is uninstalled." For user-chosen files, "Developers should consider using Storage Access Framework as the privacy-friendly option for accessing files in shared storage. This framework supports the vast majority of use cases for apps to accomplish a full range of functionality." SAF is also the only one of the three that needs no runtime permission at all: "Because the user is involved in selecting the files or directories that your app can access, this mechanism doesn't require any system permissions, and user control and privacy is enhanced." (https://support.google.com/googleplay/android-developer/answer/10467955 / https://developer.android.com/training/data-storage/shared/documents-files)
10. How the permission is requested, and what it actually unlocks. "An app can request all-files access from the user by doing the following: Declare the MANAGE_EXTERNAL_STORAGE permission in the manifest. Use the ACTION_MANAGE_ALL_FILES_ACCESS_PERMISSION intent action to direct users to a system settings page... To determine whether your app has been granted the MANAGE_EXTERNAL_STORAGE permission, call Environment.isExternalStorageManager()." Once granted it gives "Read and write access to all files within shared storage" (and "The /sdcard/Android/media directory is part of shared storage"), "Access to the contents of the MediaStore.Files table", "Access to the root directory of both the USB on-the-go (OTG) drive and the SD card", and "Write access to all internal storage directories except /Android/data/, /sdcard/Android, and most subdirectories of /sdcard/Android". It still does not reach other apps: "Apps that are granted this permission still can't access the app-specific directories that belong to other apps, because these directories appear as subdirectories of Android/data/ on a storage volume." (https://developer.android.com/training/data-storage/manage-all-files)
11. Do not mix up the two mechanisms. Holding the permission narrows what SAF can see rather than widening it: "When you use the Storage Access Framework, however, you can only access a file or directory if you can do so without having the MANAGE_EXTERNAL_STORAGE permission." So a permission declared "just in case" can degrade a path that already worked. On Android 12 (API 31) and higher, apps that hold both MANAGE_EXTERNAL_STORAGE and QUERY_ALL_PACKAGES (file managers) can use getManageSpaceActivityIntent() to send the user to another app's custom space management activity. (https://developer.android.com/training/data-storage/manage-all-files)
12. The migration itself: requestLegacyExternalStorage dies the moment you target Android 11. "Apps that run on Android 11 but target Android 10 (API level 29) can still request the requestLegacyExternalStorage attribute... After you update your app to target Android 11, the system ignores the requestLegacyExternalStorage flag." So do the work in order: "If your app uses the legacy storage model and previously targeted Android 10 or lower, you might be storing data in a directory that your app cannot access when the scoped storage model is enabled. Before you target Android 11, migrate data to a directory that's compatible with scoped storage." Two more mechanical changes: "Starting in Android 11, apps cannot create their own app-specific directory on external storage. To access the directory that the system provides for your app, call getExternalFilesDirs()." And to test, untick scoped storage behaviour per app compatibility flag - "DEFAULT_SCOPED_STORAGE (enabled for all apps by default)" and "FORCE_ENABLE_SCOPED_STORAGE (disabled for all apps by default)". (https://developer.android.com/about/versions/11/privacy/storage)
13. Keeping the permission after changing your use of it is the expensive mistake. "If you change how your app uses these restricted permissions, you must submit the form again with updated and accurate information. Deceptive and undeclared uses of these permissions may result in a suspension of your app and/or termination of your developer account." In practice this means re-running the declaration whenever a new feature starts touching broad file access - and for apps whose storage use is ordinary (documents the user picked, photos, exports), the cheapest path is still to drop MANAGE_EXTERNAL_STORAGE from the manifest and ship MediaStore + SAF + the photo picker instead. (https://support.google.com/googleplay/android-developer/answer/10467955)