[GH-ISSUE #53] Question on storage permissions

kerem commented

2026-02-27 19:25:58 +03:00

Owner

Originally created by @IzzySoft on GitHub (Jan 22, 2024).
Original GitHub issue: https://github.com/Lambada10/SongSync/issues/53

My scanner just got "revamped" last week, and immediately found something to say about (not just) your app:

! repo/pl.lambada.songsync_301.apk declares risky permission(s): android.permission.READ_EXTERNAL_STORAGE android.permission.MANAGE_EXTERNAL_STORAGE

Could you please clarify what those permissions are needed for? Especially the latter, as that's usually reserved for applications like e.g. file managers. Thanks in advance!

Originally created by @IzzySoft on GitHub (Jan 22, 2024). Original GitHub issue: https://github.com/Lambada10/SongSync/issues/53 My scanner just got "revamped" last week, and immediately found something to say about (not just) your app: ! repo/pl.lambada.songsync_301.apk declares risky permission(s): android.permission.READ_EXTERNAL_STORAGE android.permission.MANAGE_EXTERNAL_STORAGE Could you please clarify what those permissions are needed for? Especially the latter, as that's usually reserved for applications like e.g. file managers. Thanks in advance!

kerem closed this issue

2026-02-27 19:25:59 +03:00

kerem commented

2026-02-27 19:25:59 +03:00

Author

Owner

@nift4 commented on GitHub (Jan 23, 2024):

On Android 13+, the normal READ_EXTERNAL_STORAGE now is a no-op, and split into "read audio"/"read photos"/" read videos", none of those give access to .lrc files. Google recommends requesting access to folder trees. Because Android does not allow selecting top level storage, if someone has a music track on top level storage (ie directly on internal storage or SD card), the app would have no way to discover assosicated .lrc files (used for filtering by "already has lyrics") without showing an open file dialog for each and every .lrc file. Aditionally, the code would be more complex by a great deal. As this app is not on the Play Store, we chose to use MANAGE_EXTERNAL_STORAGE to avoid running into stupid limitations (like the one mentioned above) and support SD cards conveniently, ie without additional work for the user.

Any further questions? :)

@nift4 commented on GitHub (Jan 23, 2024): On Android 13+, the normal READ_EXTERNAL_STORAGE now is a no-op, and split into "read audio"/"read photos"/" read videos", none of those give access to .lrc files. Google recommends requesting access to folder trees. Because Android does not allow selecting top level storage, if someone has a music track on top level storage (ie directly on internal storage or SD card), the app would have no way to discover assosicated .lrc files (used for filtering by "already has lyrics") without showing an open file dialog for each and every .lrc file. Aditionally, the code would be more complex by a great deal. As this app is not on the Play Store, we chose to use MANAGE_EXTERNAL_STORAGE to avoid running into stupid limitations (like the one mentioned above) and support SD cards conveniently, ie without additional work for the user. Any further questions? :)

kerem commented

2026-02-27 19:25:59 +03:00

Author

Owner

@IzzySoft commented on GitHub (Jan 23, 2024):

Hm, I see. From a security point of view, I'd rather say one shouldn't store music collections directly at top level (from an organizational point of view, I never did that even back when I was a "bloody beginner"). Of course that's a decision on your end, but were such cases really coming up frequently and not just in exceptional cases – and wouldn't it be better addressed at the end of those few having their music collection not inside (a) dedicated folder(s)?

I know it would mean a "break" with the existing setup, but thought to raise the question anyway. MANAGE_EXTERNAL_STORAGE is quite a heavy thing, even if your app is not in Google's Play Store:

Allows an application a broad access to external storage in scoped storage. Intended to be used by few apps that need to manage files on behalf of the users.

So yes, this is Protection level: signature|appop|preinstalled – and IIRC, "appop" indicates the user has to confirm it. Can it be safely denied if one does not have media files in a "root directory"? And if so, is this mentioned before the permission is requested, so users are aware they can safely deny it?

For now I've added the READ permission to your app's allow-list:

    PermIgnore:
      android.permission.READ_EXTERNAL_STORAGE: Up to Android 9, this permission is required to access media files owned by other apps.

@IzzySoft commented on GitHub (Jan 23, 2024): Hm, I see. From a security point of view, I'd rather say one shouldn't store music collections directly at top level (from an organizational point of view, I never did that even back when I was a "bloody beginner"). Of course that's a decision on your end, but were such cases really coming up frequently and not just in exceptional cases – and wouldn't it be better addressed at the end of those few having their music collection **not** inside (a) dedicated folder(s)? I know it would mean a "break" with the existing setup, but thought to raise the question anyway. `MANAGE_EXTERNAL_STORAGE` is [quite a heavy thing](https://developer.android.com/reference/android/Manifest.permission#MANAGE_EXTERNAL_STORAGE), even if your app is not in Google's Play Store: > Allows an application a broad access to external storage in scoped storage. Intended to be used by few apps that need to manage files on behalf of the users. So yes, this is `Protection level: signature|appop|preinstalled` – and IIRC, "appop" indicates the user has to confirm it. Can it be safely denied if one does **not** have media files in a "root directory"? And if so, is this mentioned before the permission is requested, so users are aware they can safely deny it? For now I've added the READ permission to your app's allow-list: ```yaml PermIgnore: android.permission.READ_EXTERNAL_STORAGE: Up to Android 9, this permission is required to access media files owned by other apps. ```

kerem commented

2026-02-27 19:25:59 +03:00

Author

Owner

@nift4 commented on GitHub (Jan 23, 2024):

and wouldn't it be better addressed at the end of those few having their music collection not inside (a) dedicated folder(s)?

The app supports downloading .lrc files to Downloads, which also isn't allowed to be opened as folder, which means we would have to add a seperate "Save as..." dialog every time
Many users, including myself, do not store their Music library in only one folder (ie I have some tracks in the Music/ folder, some in Downloads/NewPipe/ or Downloads/Telegram/ or just directly Downloads/). Android also prevents choosing Android/ and most importantly Downloads/ folder, and storing music files in Downloads/ is common enough to significantly impact the user experience.

MANAGE_EXTERNAL_STORAGE is quite a heavy thing

It's just as heavy as READ_EXTERNAL_STORAGE in the past. Google decided using storage is evil, and while there were many examples of evil usage in the past for sure, there were far more legitimate uses-

Can it be safely denied if one does not have media files in a "root directory"? And if so, is this mentioned before the permission is requested, so users are aware they can safely deny it?

No. The code is not fit for using SAF currently, and even if one does not store their files in one of the aforementioned directories, having to force the user to select EVERY directory on the whole internal storage that contains an audio file (if this isn't done, the aforementioned built-in filter options become basically useless and for every .lrc file downloaded, we need to open one dialog, which makes batch download useless as well) is a tedious task. We, as the app developers, don't understand why we should annoy users like that just because Google decided using the storage is evil.

@nift4 commented on GitHub (Jan 23, 2024): > and wouldn't it be better addressed at the end of those few having their music collection **not** inside (a) dedicated folder(s)? - The app supports downloading .lrc files to Downloads, which also isn't allowed to be opened as folder, which means we would have to add a seperate "Save as..." dialog every time - Many users, including myself, do not store their Music library in only one folder (ie I have some tracks in the Music/ folder, some in Downloads/NewPipe/ or Downloads/Telegram/ or just directly Downloads/). Android also prevents choosing Android/ and most importantly Downloads/ folder, and storing music files in Downloads/ is common enough to significantly impact the user experience. > MANAGE_EXTERNAL_STORAGE is [quite a heavy thing](https://developer.android.com/reference/android/Manifest.permission#MANAGE_EXTERNAL_STORAGE) It's just as heavy as READ_EXTERNAL_STORAGE in the past. Google decided using storage is evil, and while there were many examples of evil usage in the past for sure, there were far more legitimate uses- > Can it be safely denied if one does **not** have media files in a "root directory"? And if so, is this mentioned before the permission is requested, so users are aware they can safely deny it? No. The code is not fit for using SAF currently, and even if one does not store their files in one of the aforementioned directories, having to force the user to select EVERY directory on the whole internal storage that contains an audio file (if this isn't done, the aforementioned built-in filter options become basically useless and for every .lrc file downloaded, we need to open one dialog, which makes batch download useless as well) is a tedious task. We, as the app developers, don't understand why we should annoy users like that just because Google decided using the storage is evil.

kerem commented

2026-02-27 19:25:59 +03:00

Author

Owner

@Lambada10 commented on GitHub (Jan 28, 2024):

@IzzySoft Can I close this?

@Lambada10 commented on GitHub (Jan 28, 2024): @IzzySoft Can I close this?

kerem commented

2026-02-27 19:25:59 +03:00

Author

Owner

@IzzySoft commented on GitHub (Jan 28, 2024):

@Lambada10 it seems I miss some notifications lately, so I didn't see the previous comment, apologies! And thanks for the ping! Let me check that first…

Google decided using storage is evil

So you should store everything in the cloud probably (according to Google). I agree with you that one should always look at their reasoning with both eyes open, lest one misses some "hidden truth".

So if I get that right, MANAGE_EXTERNAL_STORAGE cannot be avoided – at least not at this time (or in the near future). And yes, full ack, storage permissions on Android are quite a mess. What would you recommend I should put as reason then when adding this permission to SongSync's allow-list – in a way that it doesn't get much longer than 80 chars?

"storage access restrictions especially on Android 9 and below make this needed to use music files in different locations"

OK, that's 120 chars. And wouldn't hold true as… when was MANAGE_EXTERNAL_STORAGE introduced? SDK 30 aka Android 11. "Allows an application a broad access to external storage in scoped storage." So Downloads/ is probably outside of MEDIA_* grounds – and can only be accessed with MANAGE, did I get that right? So

"needed on Android 11+ to access your music files in e.g. Downloads"

should fit then? If so I'll set that, and then this issue can be closed indeed.

(how should the average Jane and Joe not get lost in those "storage woods" if even those with some technical insights do? No, not blaming you, but those who created that permission-mess…)

@IzzySoft commented on GitHub (Jan 28, 2024): @Lambada10 it seems I miss some notifications lately, so I didn't see the previous comment, apologies! And thanks for the ping! Let me check that first… > Google decided using storage is evil So you should store everything in the cloud probably (according to Google). I agree with you that one should always look at their reasoning with both eyes open, lest one misses some "hidden truth". So if I get that right, `MANAGE_EXTERNAL_STORAGE` cannot be avoided – at least not at this time (or in the near future). And yes, full ack, storage permissions on Android are quite a mess. What would you recommend I should put as reason then when adding this permission to SongSync's allow-list – in a way that it doesn't get much longer than 80 chars? "storage access restrictions especially on Android 9 and below make this needed to use music files in different locations" OK, that's 120 chars. And wouldn't hold true as… when was `MANAGE_EXTERNAL_STORAGE` introduced? SDK 30 aka Android 11. "Allows an application a broad access to external storage in scoped storage." So `Downloads/` is probably outside of `MEDIA_*` grounds – and can only be accessed with `MANAGE`, did I get that right? So "needed on Android 11+ to access your music files in e.g. Downloads" should fit then? If so I'll set that, and then this issue can be closed indeed. (how should the average Jane and Joe not get lost in those "storage woods" if even those with some technical insights do? No, not blaming you, but those who created that permission-mess…)

kerem commented

2026-02-27 19:25:59 +03:00

Author

Owner

@Lambada10 commented on GitHub (Jan 29, 2024):

@IzzySoft "needed on Android 11+ to access your music files in e.g. Downloads" is good

@Lambada10 commented on GitHub (Jan 29, 2024): @IzzySoft "needed on Android 11+ to access your music files in e.g. Downloads" is good

kerem commented

2026-02-27 19:25:59 +03:00

Author

Owner

@IzzySoft commented on GitHub (Jan 29, 2024):

Thanks! Done then:

(still marked "bold" as it's considered a sensitive permission, but no longer using the "warning color" and showing the reason instead).

@IzzySoft commented on GitHub (Jan 29, 2024): Thanks! Done then: ![image](https://github.com/Lambada10/SongSync/assets/6781438/cd410453-d4ad-4cff-ac9b-550d3bdb2234) (still marked "bold" as it's considered a sensitive permission, but no longer using the "warning color" and showing the reason instead).

kerem referenced this issue

2026-02-27 19:26:39 +03:00

[PR #37] [MERGED] Icon fix #175

Rows
Columns

[GH-ISSUE #53] Question on storage permissions #37