SeekerAndroid
SeekerAndroid copied to clipboard
jackBonadies
Using seeker on Android 12 requires setting directory everytime
Before updating to android 12 the app worked fine but now I can't choose the base download folder for seeker and even after creating another folder that works with it after every boot of the app I need to reselect it.
So I am able to select the download folder location in android 12. But after the app has been closed or shutdown when you boot it again it asks for the download folder location again and asks for folder access confirmation again. What is odd is sometimes it still has the location preserved when I boot it, yet more often it asks again. Wasn't an issue before and I've been using it on android 12 so I don't think it's only os related.
Seeker will always remember the download folder location. The problem seems to be that on some devices the OS seems to revoke privileges, so even though Seeker remembers the location, it does not have proper privileges to write to it. I am not sure how to fix this. On invoking the intent to have the user select the folder I use flag "FLAG_GRANT_PERSISTABLE_URI_PERMISSION" and when they select the folder I call TakePersistableUriPermission which according to the docs is all that needs to be done (https://developer.android.com/reference/android/content/Intent#FLAG_GRANT_PERSISTABLE_URI_PERMISSION). I have not been able to reproduce the issue on Samsung Android 12, unfortunately. Any ideas?
The documentation says "Only URI permissions granted with Intent#FLAG_GRANT_PERSISTABLE_URI_PERMISSION can be persisted." When using takePersistableUriPermission. But using FLAG_GRANT_PERSISTABLE_URI_PERMISSION needs combination with FLAG_GRANT_READ_URI_PERMISSION and/or FLAG_GRANT_WRITE_URI_PERMISSION, the URI permission grant can be persisted across device reboots until explicitly revoked with Context#revokeUriPermission(Uri, int).
This flag only offers the grant for possible persisting; the receiving application must call ContentResolver#takePersistableUriPermission(Uri, int) to actually persist.
I think this last bold part is maybe what you may be missing
On a real note even if I must select a folder every boot I wouldn't really mind too much because having soulseek on my mobile is amazing and worth the little inconvenience of selecting the folder just for this app simply working. I thank you for your work on this, sincerely.
TakePersistableUriPermission is called at what I believe are the two relevant places: https://github.com/jackBonadies/SeekerAndroid/blob/master/AndriodApp1/MainActivity.cs#L10073 https://github.com/jackBonadies/SeekerAndroid/blob/master/AndriodApp1/MainActivity.cs#L10153
And thanks for the kind words :) but I would still like to get this issue figured out somehow.. I know that for those who do have this problem it must be quite annoying.
Would it help if I enabled diagnostics and had the app prompt me a few times maybe a boot when it was preserved still and a few when it is asking for folder again and include log here? What is odd is that it was working before without this issue just recently did it begin to do this for me.
Also while we are here I noticed in the play store under your description/app info your url hyperlink to source is including " ). " at the end so when you simply click it you get sent to github 404 page I figure this is a simple fix might as well let you know. Lol
TakePersistableUriPermission is called at what I believe are the two relevant places: https://github.com/jackBonadies/SeekerAndroid/blob/master/AndriodApp1/MainActivity.cs#L10073 https://github.com/jackBonadies/SeekerAndroid/blob/master/AndriodApp1/MainActivity.cs#L10153
And thanks for the kind words :) but I would still like to get this issue figured out somehow.. I know that for those who do have this problem it must be quite annoying.
I am just curious if I'm reading the code correctly for takePersistableUriPermission the ints that are taken in are bitwise or?
Perhaps enabling diagnostics would be helpful, if you would not mind! Though I don't know if diagnostics would reveal anything useful off the top of my head. I need to look closer at what it would be logging. And yes they are bitwise or - i.e. I want both Read and Write permission.
Perhaps enabling diagnostics would be helpful, if you would not mind! Though I don't know if diagnostics would reveal anything useful off the top of my head. I need to look closer at what it would be logging. And yes they are bitwise or - i.e. I want both Read and Write permission.
Well bitwise or would be more like I want both or either to be true. .... if neither then false. I don't really know c# just some c++ but if the code happens to be kinda similar wouldn't you want to && them?
The call wants to know which flags we want to persist. And I want both read (say 0x0001 for example) and write (0x0010) to persist. And so I OR them for 0x0011. If I AND'd them then I would get 0x0000 since the flags are exclusive. bitwise OR would combine them in this case, whereas bitwise AND would mask them.