Describe the Feature
Proposal: Removal of WRITE_EXTERNAL_STORAGE permission
What problem are we trying to solve?
react-native-share into an existing React Native project, and uploading a release .apk file to the store, we were presented with a warning that the
android.permission.WRITE_EXTERNAL_STORAGE was added. Ideally, the permission should be added into the implementing app’s manifest, rather than merged in by
react-native-share. We see this was added as part of #294, as part of base64 sharing.
Why should we solve it?
This permission, in the context of our app (and potentially other apps too), is unnecessary (of course, we understand other apps are likely to use this, so we’d love to discuss this!). Out of an abundance of caution, we also actively reduce the number of ‘dangerous’ permissions our app ships with, even if we know they will not be used by ourselves. This has the added benefit of reducing the number of permissions listed on the Google Store page, which some users may look at before installing a new app.
While we appreciate that other apps are likely to use this functionality & permission, and automatically adding this permission makes it easier to work with the library, we feel that adding ‘dangerous’ permissions feels more like the responsibility of the implementing app. The Android Developer documention also mentions
Add only the permissions that your app needs.
The Android API docs also mention
WRITE_EXTERNAL_STORAGE as dangerous here.
How do we propose to solve it?
We already have a patch file in our project that handles this change, where we removed
<uses-permission android:name="android.permission.WRITE_EXTERNAL_STORAGE" />
src/main/AndroidManifest.xml. A further change would be to update documentation (such as here) to detail this change, and to explain that the permission should be added into the implementing app’s AndroidManifest.xml file.
I’m happy to move our patch into a PR, and to provide new documentation, if the consensus is to move forward with this.
What other approaches did we consider?
- Leaving the permission as is, and pushing the .apk to the store
- We chose not to do this, as the permission is not utilised in our app. We also did not want users to be met with any barrier to uploading, or to deal with queries from customers as to why our app needed to suddenly use these permissions.
- Patching the module via
- We have done this as a temporary measure, and upon auditing our patches have decided that this would be good to discuss with the community, so more can benefit from this.
We feel, that by changing the manifest to force implementing apps to include the permission, this will benefit:
- developers and companies, who have less permission requirements in their apps
- and users, who may (or may not) notice their apps require fewer permissions.
What could go wrong?
- Upon upgrading to a version of this library without this permission pre-added, developers may not add the permission to their manifest file.
- This may cause issues in base64 sharing functionality, although it seems like the fallback logic is already in place.
- To resolve this, migration documentation can be included, and a note added to here