jamal2362 / URL-Radio

Simply URL Radio Application for Android
MIT License
165 stars 6 forks source link

Remove storage permissions #31

Closed Bnyro closed 1 year ago

Bnyro commented 1 year ago

First of all, thanks for maintaining such a beautiful MD3 app!

I've wondered why the app requires the permissions android.permission.WRITE_EXTERNAL_STORAGE and android.permission.READ_EXTERNAL_STORAGE, since it uses the Android Storage Access Framework for m3u exports and backups which does not require any permissions. I've tested the app (doing backups and restoring them) on SDK 33 and SDK 28 (since that seems to be the last one that required storage write permissions previously), and they worked flawlessly. Maybe those have been left-overs from the time before the upstream app switched to using SAF?

However, if there's anything left over that needs to be migrated before removing the storage permissions, I wouldn't mind migrating that to SAF too in order to get rid of them. Cheers

jamal2362 commented 1 year ago

Hey 🙂

I will test these changes, thanks for the PR. I have to see if there are no problems with Android 5 and higher. If there are no problems then I will merge this PR.

jamal2362 commented 1 year ago

I have tested this change.

Unfortunately, with this change on Android 12 and below, images can no longer be set for the radio stations. Therefore, this permission is still required. android.permission.READ_EXTERNAL_STORAGE


android.permission.WRITE_EXTERNAL_STORAGE" android:maxSdkVersion="28" This permission is no longer required. This does not restrict the app.

Bnyro commented 1 year ago

Where is the code for saving the images? Couldn't we migrate that to SAF too or instead just save the images in the app internal files?

jamal2362 commented 1 year ago

The pictures are stored in Android/data/com.jamal2367.urlradio/files/Pictures This is necessary because of exporting the stations.

If there is a way to set the images via SAF, it would be good. Then android.permission.READ_EXTERNAL_STORAGE would no longer be necessary.

You can find the code in the PlayerFragment.kt file starting at line 587.

Bnyro commented 1 year ago

Seems doable, I'll try my luck and keep you updated ;)

jamal2362 commented 1 year ago

All right 👍

Bnyro commented 1 year ago

We're using the PhotoPicker now on Android 11 and up, any lower Android versions will automatically launch the file picker instead now. Therefore I had to add androidx.activity:activity-ktx:1.6.1 as dependency, I hope that is fine! Tested on Android 13 (SDK 33) and Android 6 (SDK 23), works without issues :)

Bnyro commented 1 year ago

Please also consider adding applicationIdSuffix '.debug' to the debug buildType, since that allows us to keep the latest version from IzzyOnDroid and the debug version for testing on the same device at the same time :)

jamal2362 commented 1 year ago

The PR looks good now. It seems to be working as usual now.

Bnyro commented 1 year ago

Awesome, thanks for your time!

jamal2362 commented 1 year ago

Np 😉😊

Bnyro commented 1 year ago

Also thanks to removing the WiFi state and vibration permission, the app now has a light green (5/5, so the best) rating, while it had a rating of 3/5 regarding the permissions before the update. That's awesome as it makes it easier for all the privacy nerds to trust the app :wink:

jamal2362 commented 1 year ago

I'm glad to hear that! I haven't paid attention to the permissions in the manifest for a while, so they've been removed since they're not necessary in the app. There is nothing hidden. The code can be searched and you won't find anything that reveals privacy. My philosophy is to offer no analytics and no ads in all my apps. My ultimate goal is to design the apps in such a way that they are easy to use and the user interface is appealing. Everyone is also welcome to participate in the code. You can discuss about everything. 🙂

Bnyro commented 1 year ago

Unfortunately not everybody has the knowledge and time to inspect the code of all apps they're using, so if the app only uses very few permissions that's always a good thing. Though that's obviously never been an issue here and probably very rare with FOSS apps, but it's still nice to have ;) And I do agree with your philosophy, I feel like those could have been my slogans too, with these aims you can never do anything wrong :) I'm always interested in contributing a bit to some other apps, but to me URL Radio looks already very feature complete while having a great UI, it's great for me for usage as daily driver <3