I am writing a small medical app as means of trying out my newly learned Android skills. I want to be able to read a text file from a specific folder on the device (not the SD card) where the user can put some medical information (when the app starts upp) without having the user need to pick the file destination, but I am not sure how to implement it. I may also want to write to the file.
The file may change frequently. The truth is, I need to read from a directory with a variable number of subdirectories, each with 4 files in them. It is those files I need to read and then display, but for the sake of simplicity I limited the question to just reading the file. It seems like this would be a file which would be in "Internal Storage/Android/data/com.me.myapp/medical_information", but I am not sure how convenient that would be for the user to constantly have to find the app among all of the app folders, and then navigate to the folder. Where would be the best place to put this folder/file, and how would go about writing/reading from it?
It is preferrable that answers be written in Kotlin, but not essential.
Related
first question on this site, if improper just tell me.
I am creating an app on an adroid platform. With this app I create some files and folders in the shared document folder.
What happens is this: with every build, at least with the -cleaninstall parameter set, it is impossible to overwrite existing files and/or folders. Even after deleting them on the phone.
Probably this is due to the fact that the filesystem thinks that the new build is not the original owner of the file/folder and is therefore not authorized to delete or overwrite.
As a bypass solution I am using an "appname" variable to create a folder to store data in, if necessary I update the "appname" variable so a fresh set of folders is created, based on the "appname" but this a pretty crooked way to work.
DocumentFolder := System.IOUtils.TPath.GetSharedDocumentsPath;
AppName := 'ExpensesV2';
AppFolder := DocumentFolder+PathDelim+AppName;
if NOT DirectoryExists(AppFolder) then ForceDirectories(AppFolder);
Is there a proper way to really remove/clean up that specific folder OR get the proper autorisation.
Thank you for your valued responses!!
You don't specify how you're going about creating the folders and writing the files. There are different mechanisms for doing so depending upon the type of file you want to write (media files, documents, generic files) and who you want to have access to it (public vs app private storage). There are also additional complications with permissions and things depending upon what OS version you're targetting.
Given the information available, the best I can suggest is having a look at these links:
https://developer.android.com/training/data-storage
https://developer.android.com/training/data-storage/use-cases
The latter gives some sample cases of types of file and purpose and suggests the mechanism to use to write/read it.
In the most general of senses, if you want to write to public external storage then use getExternalStoragePublicDirectory(); but the warning note here is that the user can do as they wish with the files in the storage area; putting their own files there, renaming files, deleting files etc etc It is beyond the control of your app to manage.
If you want your app to manage the storage space properly then you need to use something like Context#getExternalFilesDir(), but then if you want those files to be externally visible you will have to share them with the system and look into things like file sharing or content providers.
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.
My company has three different Android apps that provide functionality for sales reps. We opted to separate the apps into "modules" because not all reps need all the modules. Up to now we have been using a JSON file in a directory on the SD card of the devices to set some configuration data for the apps. However, it appears that with Android 10 and beyond this will no longer be possible.
Currently we use getExternalStorageDirectory() to access the SDCARD and then open a file inside a directory our app creates.
Since we want the file access to not be something the sales reps have any control over we want it to happen transparently. However it does not seem this will be possible going forward.
Will using a custom FileProvider or even a DocumentsProvider be a way to continue to share data between our apps?
Another question, although not as important, is, can we change the default location of the DB files our app creates as we do now in earlier versions of Android?
Thanks
Rich
I have an android app which allows the user to gather research data. I want to export the gathered data as an excel file. So the user can work with the data on a desktop computer.
The question is, what is the best way in terms of usability to offer file export to the user?
On idea was to start the email client with the excel file as attachment. But if you have to send this email to yourself just to get the files seem kind of a workaround.
The second idea is to store the file in the android file system. But is there a commen folder for something like that? Like the "Documents" folder in windows? I dont want the user to search too long for his file. And is this really best practice?
The common way, is using the shared intent system and allowing the user to pick which app "he" or "she" wants to use to share the file. You can also save it to the android file system just as easily. There is no common folder which everyone should use. But if you want ease of accessibility for the file, create a new sub-directory under the top-level directory on the device. Use this method to get a reference to the top-level, Environment.getExternalStorageDirectory(). You must have the android.permission.WRITE_EXTERNAL_STORAGE permission declared in your app Manifest. The sub-directory name should be something obvious to that user that the data inside belongs to your app. Furthermore, display a toast that indicates to the user where the file is stored to make it even easier for them.
According to the Android Development Documentation, you can't just open any file you want ("Open a private file associated with this Context's application package for writing.").
What, however, when I want my application to read files created by other applications? Let's say I have a file in /data/app_1/hello.txt, but my application has nothing to do with it because my app is called app_2, how would I still be able to open this file (and write back to it)?
You can't in general, Applications on Android are isolated and sparated. A application can only write and read its own files.
There are exceptions: As the documentation states: "It's possible to arrange for two applications to share the same Linux user ID, in which case they are able to access each other's files. To conserve system resources, applications with the same user ID can also arrange to run in the same Linux process and share the same VM (the applications must also be signed with the same certificate)."
Another possiblity is that the files are created as "world readable" so that every application can read it.
So to summarize and come back to your question: If you can not modify "my_app_1" then it is impossible. Of you can modify both applications choose one of the solutions above.
Two options:
If you are designing both applications and want to share the file, keep it somewhere else (for example - external storage) or make it world readable.
If you are trying to read another app's file - well, you shouldn't, that's a key element in the android security architecture.