The new year always sparks fresh ideas, and for me, it began with a thought-provoking conversation with another Android developer. The topic? Google’s shift in storage permissions starting with API 33 and its implications for apps. Many developers still seem to misunderstand how these changes affect their applications.
In the official Android documentation, we find a clear statement about the READ_EXTERNAL_STORAGE permission:
Starting in API level 33, this permission has no effect. If your app accesses other apps' media files, request one or more of these permissions instead: READ_MEDIA_IMAGES, READ_MEDIA_VIDEO, READ_MEDIA_AUDIO. Learn more about the storage permissions that are associated with media files.
This means that even if you add READ_EXTERNAL_STORAGE to your manifest, you won’t be able to access files in downloads unless they are images, videos, or audio. When this fails, many developers turn to the MANAGE_EXTERNAL_STORAGE permission.
However, this introduces another issue. While using this permission might give you access to all files on external storage, Google Play will not allow your app to be published unless it meets specific criteria. The documentation makes this clear:
Google Play allows the use of MANAGE_EXTERNAL_STORAGE only for apps that need to access files on a device and are related to core functionality like file management, backup and restore, antivirus, document management, device search, file encryption, or data migration.
Android Studio’s linter will flag a warning when this permission is included in the manifest, alerting you to its restricted use. To clarify, only the following types of applications are eligible to use MANAGE_EXTERNAL_STORAGE:
- File managers
- Backup and restore app.
- Antivirus app.
- Document management apps
- Device file search apps
- File and disk encryption tools
- Data migration apps (e.g., transferring data from one device to another)
If your app doesn’t fall into one of these categories, you’ll need to find alternative solutions for handling files.
Why is Google doing this?
The reason is simple: Google wants to prevent apps from having unrestricted access to a device’s storage, which could compromise user privacy and security. For something as straightforward as generating a document, the solution isn’t to request excessive permissions but to write it to your app’s sandbox or, even better, create it temporarily and use the share dialog. This dialog allows users to choose where to save the file without requiring special permissions.
My Recommended Solution
Instead of asking for unnecessary permissions, leverage the share dialog. This approach empowers users to decide where to save or share their file, all while adhering to Android’s privacy principles.
Here’s how you could implement creating and sharing a temporary file:
This approach not only complies with the new policies but also enhances the user experience by giving them control over where to save or share their file.
A Note for Flutter Developers
These changes also significantly impact Flutter developers. When building apps for Android with Flutter, you not only need to understand how permissions work but also ensure they are loaded and handled appropriately. Using packages like path_provider and share_plus can help manage permissions, but it’s crucial to align with Android’s latest policies. Moreover, when sharing files, using platform channels to properly implement native functionality might be required for a seamless experience.
Here’s an example of how you can handle file sharing in Flutter:
This method ensures that your app remains compliant with Android’s new storage policies while providing a user-friendly way to handle files.
Conclusion
Android’s changes to storage permissions might seem restrictive at first, but they align with a broader goal of improving user security and privacy. Instead of resisting these new rules, embrace creative and secure solutions like the share dialog.
As developers, it’s our responsibility to adapt to these changes and continue building applications that not only work well but also respect the rights and security of the users who rely on them.
Here’s to a productive 2025 filled with clean, secure, and user-friendly code!
Comments
Post a Comment