Trying to make some sense of this complete mess of scoped storage.
So I'm storing some files (logs) generated by App A inside the Download folder.
I'm using Mediastore/ContentResolver and no problems with that either for read or write access as long as it's from App A.
But then App B needs to read these files and here comes the problem.
Same way using Mediastore/ContentResolver but the files seem invisible for queries.
Download is supposed to be a Shared Storage, but files are indeed generated as -rw-rw--- which means no permission for others which could explaind why App B does not sees files from App A if they are not in the same group.
Would the Storage Access Framework method work around this?
Thi not tried it yet because poping system window's is definitely not something I wanted as a user experience for my App.
Thanks.
If the second app has 'all files access' with MANAGE_EXTERNAL_STORAGE it can also list the files of the first app.
Otherwise you can let the user of the second app pick those files with ACTION_OPEN_DOCUMENT of Storage Access Framework.
You better store your files in a sub directory as then second app can pick complete directory with ACTION_OPEN_DOCUMENT_TREE and list all the files.
Related
I want to share app specific directory(/data/data/packageName/files/target) and its children to other (my) app.
These are my scenarios and conditions.
App A creates and downloads random files on /data/data/packageA/files/target
App B wants to retrieve and delete /data/data/packageA/files/target recursively without user interaction. (SAF is not an option)
All apps are mine.
Shared storage(ex. /emulated/0/Documents etc) is not an option.
sharedUserId using createPackageContext works perfect for me, but it is deprecated.
Is there any solution to solve this problem?
EDIT: I'm looking for the way not to manage nor inspect every files creating structed data like StorageProvider Sample. I wish App B could access files dynamically with only root directory (target in this example)
I looked up scoped storage but that won't work because of the permission request seeing my apps feature has to delete files on backpress (if user changes folder name)/ onstop, and also multiple .txt files need to be loaded when user restores/backsup notes.
Media store doesnt say anything about .txt files nor about deleting them, that i could find. And it cant be public storage(documents or downloads) because it also writes to folder name that user types. Any help would be great, currently app is rejected from using manage_external_storage. It seems like manage external storage is the only way to go.
Thanks
this is my current code
FileUtil.writeFile(FileUtil.getExternalStorageDir().
concat("/Folder/text.txt"), e2.getText().toString());
FileUtil.deleteFile(FileUtil.getExternalStorageDir().
concat("/Folder/text.txt"));
I am confused with the new app storage system in Android. I am not sure where my use case falls under and I need your help in telling me the right approach for this
My app captures images and generates pdf documents. Prior to Android 10, I used to store them in an app directory where the user can easily navigate to them through other files browsing app (like Files app on Samsung). In addition, these files can be accessed from within my app (so essentially read and write).
With the new storage, I am not sure how to accomplish the same thing. If I use the internal storage then user can't see them. If I use the media approach, well it seems it is only for Audio/video plus they will not be organized in a folder like I have them organized.
Am I missing something? How would I solve this problem?
Thank you
On an Android 11 device you can store your files in a subdirectory of the public Documents directory.
You can do that using classic File means or the media store or SAF.
Other apps can see them using SAF or the media store. Or with classic file means when requested all files access.
The user can see them using the default Files app on the device.
I am writing a specific use-case camera app that targets Android 11. When I hit record I would like to create a new directory somewhere (with a name based on the timestamp etc) that contains the resulting video as well as a whole heap of other custom YAML/JSON/CSV files that also get written during the recording process (belongs logically to the "output" of the recording).
I would like all of the generated files to survive an app uninstall/reinstall as I do not want to risk users losing everything they've ever recorded if they uninstall the app. How do I do this with the new scoped storage changes etc in Android 11?
Looking at the overview here, I can see that:
App-specific files, App preferences and Database are clearly not suitable as amongst other things these files do not survive an uninstall
Documents and other files uses the Storage Access Framework, but this is not suitable because it requires a system file picker every time you want to write something. This would disrupt the flow of recording/user experience, and no camera app works like that.
Datasets/BlobStoreManager (here) also is not appropriate for my use case.
MediaStore API looks like it should be the one, but it can't seem to do what I want in terms of producing a whole directory of outputs, including custom YAML/JSON/CSV text files, that all belong together. My aim is that the user at all times can simply go to the file explorer, navigate to the appropriate folder, and just copy out the folder(s) with the recordings to their computer or whatever, to save/view the data. Even MediaStore.Files does not seem to guarantee you can actually do that if your app is using scoped storage.
The only option that seems to be left is using MANAGE_EXTERNAL_STORAGE and putting the data wherever I want in the home directory, but that seems like a bit of an extreme permission to be asking for just in order to be able to save some text files along with my produced videos. Also, that permission is Android 11 specific. If I want to support older Android versions, what would I need to do?
What is my best choice here? Is there an option I've missed?
but this is not suitable because it requires a system file picker every time you want to write something
No.
Use ACTION_OPEN_DOCUMENT_TREE to let the user pick a document tree. In there, you can create your own sub-tree and put your own documents into that sub-tree. You do not need the "system file picker" for anything beyond the initial ACTION_OPEN_DOCUMENT_TREE request itself. And the resulting documents will survive an uninstall.
You can create your own directory in a public directory like DCIM, Pictures, Music or Movies with classic File methods.
I am making a application wherein when I download the file through my application it gets downloaded inside my application data space. I am doing this basically because the files downloaded will not be accessed by users as they can access it if its stored in sdcard or internal memory.
So my question is that I want to open the file when user taps on the file by any third party application.ie. when the file is downloaded it will pop to open or not.If tapped on open then it should open by some other 3rd party application.
for e.g. if i download abc.doc then it should ask me to open through various readers.
Is this possible to do? and if not what solution can i implement?
Does this require the device to root..?
I am doing this basically because the files downloaded will not be accessed by users as they can access it if its stored in sdcard or internal memory.
First, "internal memory" is "application data space", assuming "application data space" refers to file storage and not RAM. There are only two places that you can write to in Android: internal storage and external storage.
Second, users who want to can access your file even on internal storage, such as by rooting their device.
So my question is that I want to open the file when user taps on the file by any third party application.ie. when the file is downloaded it will pop to open or not.If tapped on open then it should open by some other 3rd party application. for e.g. if i download abc.doc then it should ask me to open through various readers.
You could elect to make the file be MODE_WORLD_READABLE when you create it using openFileOutput(). This may allow some third-party applications to access the file. Or, you could implement a ContentProvider to serve this file. Either of these will also allow the user to access the file (e.g., via "share" options in those viewer apps), which runs counter to your original aim.
The only way you can have a file that is not accessible by users except through your app is if your app is the one to view (or otherwise work with) the file. And, as I noted above, even then rooted device owners can still elect to get to the file.