Office Hours — Today, November 10

← Saturday, November 7

Nov 10
7:20 PM
Mark M.
has entered the room
Mark M.
turned on guest access
7:45 PM
Kumar V.
has entered the room
Mark M.
hello, Kumar!
how can I help you today?
Kumar V.
Hi Mark, Warm greetings.
View paste 
We are working on creating an action plan for targeting our app to android 11 (Android R).  Just to provide brief context, our app is a offline music player called Pi Music player, which has over 30M odd downloads and active users of 5M. Being a offline music player we extensively use media store api’s and some 3rd libraries to support certain features like ID3 tag editing, ringtone cutter, ….  The biggest challenge for us when targeting Android 11 would be the scoped storage thing. 

If we have to strictly adhere to scoped storage feature then we would be missing lot of our existing features which can directly impact our active users and our play store rating as well. So we are trying hard to figure out what is the best alternate (or) rather best way to handle the scope storage at the same time don’t compromise on losing the existing feature. 

So most of my questions are focussed on scoped storage related things.  
[Note : We have opted out of scoped storage in Android 10 targeting, and now when targeting Android 11 we would abide by scope storage rules, or rather are forced to do]
Mark M.
a music player probably should be working off of the MediaStore mostly, though, right?
Kumar V.
Yes, but as said since it is a offline music player to get the content and for other things we use MediaStore
7:50 PM
Mark M.
OK -- I'm happy to try to answer your questions!
Kumar V.
View paste 
What is the alternate of DATA column ? How to get path of the song ?
- I am still able to get the value though , the target sdk is 30 and scoped storage is on.
  We are using couple of 3rd part libraries, which needs input in the form of file path only.  ( The feature these libraries provide are most used)
Mark M.
are the libraries open source?
Kumar V.
Yes
Mark M.
then perhaps fork them, or contribute changes upstream, to get them to work with InputStream or FileDescriptor, things that you can get from a ContentResolver with a Uri to your media
Kumar V.
but One or two isn't
Mark M.
then contact the vendors and ask them when they intend to support InputStream or FileDescriptor
I mean, you are not the only group using these libraries that is in this position
7:55 PM
Mark M.
the libraries need to give you more flexible options for supplying the data
Kumar V.
Ok.
Will try to raise a issue and follow up with mail with them
Mark M.
you're welcome to continue trying to use the DATA column, but my understanding is that it was unreliable to begin with
and eventually Google is going to do something to break it entirely
so, I recommend trying to "get ahead of the curve" and try to eliminate your dependency on filesystem paths
(at least for files that you are not managing yourself)
Kumar V.
Is it, ok. But the recent official doc says you can use it now
Mark M.
to be honest, I have not looked, because I have heard complaints about DATA over the years, and so I have never used it personally
Kumar V.
Ok.
Moving onto second question
Mark M.
I have not had complex media needs, and InputStream has been sufficient for me
Kumar V.
We store some files outside our app directory, not large in size though. This kind of works like feature during reinstall or if app data gets cleared. 
- What is the best solution for this ? Should we migrate the data to app storage (or) use SAF to get access and continue storing in the external storage.
8:00 PM
Mark M.
I cannot tell you which of those two is "best", as that is based on your own selection criteria
personally, I prefer app storage, for simplicity and leaving less clutter behind in case of an uninstall
but SAF is a reasonable choice, if you can explain to the user why this stuff matters
just bear in mind that SAF != on-device storage, as the user can choose Google Drive and other places
so, while SAF is fine in general, for an offline music player, it may not be the best choice
Kumar V.
View paste 
Oh yes, have to consider that as well. 
The files we store are less in size, they are in kbs
We will try to decide considering user experience
Moving onto 3rd question
Now that we have scoped storage and have to get permission to edit the files, what happens to the ACTION_OPEN_DOCUMENT_TREE permission that we were taking to edit the files in sdcard ? Are both permission unified now ?
8:05 PM
Mark M.
to be clear, what do you mean by "have to get permission to edit the files"?
are you referring to MediaStore.createWriteRequest() ?
Kumar V.
If I had to delete the file / edit the file content using ID3 tag editing
MediaStore.createWriteRequest() --> yes, this is one part , but to make the changes more persistent we edit at file level as well using some library which does ID3 tag editing.
Mark M.
from our standpoint as app developers, AFAIK, MediaStore.createWriteRequest() is independent from ACTION_OPEN_DOCUMENT_TREE, in terms of permissions
it is possible that there are some connections deep inside Android somewhere
8:10 PM
Kumar V.
Follow up question of the above
How do we delete media file now with scoped storage on ?

From Android 11 and above you are forced to take uri permission before the edit. 
Based on the docs and answers that I read, the delete that we do in media store deletes physical copy of the file as well as the indexed file that is present in media store, this is in Android 

However this is not how it works in below Android 11 os, where you have to delete physical file and the entry in media store (or) do a media scan after file is deleted.

So in this case should we be having 2 flows, one delete flow for scoped storage on (Android 11 and above) and one delete flow for below Android 11. 

(I am yet to try this)
Mark M.
to be honest, I have no idea -- I do not recall doing any experiments in that area
and deleting media was always confusing with respect to dealing with the file content and MediaStore
Kumar V.
You mean deleting a media file ?
deleting media was always confusing with respect to dealing with the file content and MediaStore --> Yes
Mark M.
sorry, I was referring to deleting things out of MediaStore, and what the impacts are for the underlying file
Kumar V.
With whatever I had tried sometime back , the above what I have stated is how it works as far as I could remember
Mark M.
it certainly sounds plausible -- it's just not an area that I have worked in
Kumar V.
So just wanted to know if you had any idea related to this, I was finding hard to get something online
it certainly sounds plausible -- it's just not an area that I have worked in --> Ok, will try out
Mark M.
sorry, while I have done a fair bit on scoped storage, my focus has been more on the SAF side than the MediaStore side
8:15 PM
Kumar V.
I have some questions on SAF, let's say I want to create a folder in root dir of external storage, with the recent change that is not possible right because giving permission to the root directory of external storage is not allowed
Mark M.
correct
Kumar V.
So I have to use one of the existing folder to create my folder ?
Mark M.
yes, or (I think) create the folder outside of the app (e.g., USB cable)
Kumar V.
Sorry, didn't get this
Mark M.
I think the user can create the folder manually by mounting their Android device as a drive using a USB cable and a desktop or notebook
Kumar V.
Ok, is there way to do this programatically as well ?
8:20 PM
Mark M.
AFAIK, no
that is part of the point of these changes
Kumar V.
Yes
This scoped storage is a good idea from android, but the way it is given to developers is hell
I don't know how many apps are going to suffer.
Mark M.
locking things down, that used to be open, is always hard
but, even given that, scoped storage has been *messy*
8:25 PM
Kumar V.
That's it Mark. Will try out above things and get back in next office hours If I have anything to ask.
Mark M.
OK, sounds good!
Kumar V.
Thanks for your help.
Mark M.
I'm sorry that I didn't have more and better answers!
Kumar V.
The suggestions was helpful, will explore from here.
Good day Mark. Bye. :)
Mark M.
see you later!
8:30 PM
Mark M.
that is wrap for today's chat
the transcript will be posted to https://commonsware.com/office-hours/ shortly
the next chat is Thursday at 8:30am US Eastern
have a pleasant day!
Kumar V.
has left the room
Mark M.
turned off guest access

← Saturday, November 7

 

Office Hours

People in this transcript

  • Kumar Velu
  • Mark Murphy