As per the Documentation
Use scoped storage unless your app needs access to a file that's stored outside of an app-specific directory and outside of a directory that the MediaStore APIs can access. If you store app-specific files on external storage, you can make it easier to adopt scoped storage by placing these files in an app-specific directory on external storage. That way, your app maintains access to these files when scoped storage is enabled.
In my case I am creating a text file using below:
File root = new File(this.getExternalFilesDir(null), "sample");
if (!root.exists()) {
root.mkdirs();
}
File file = new File(root, "sample.txt");
Above is creating a file at below location (while having NO SD card available):
/storage/emulated/0/Android/data/<package-name>/files/sample.txt
And I am performing writing operations on it.
Below are the queries:
While referring to the mentioned documents it is still not cleared if Scoped storage enforcement is applicable for the above-mentioned scenario? Do I need to implement the Scoped Storage or It will work without any changes and there is no impact of Android 11 behavior change.
As per my understanding There ks no Impact of Scoped storage enforcement due to Android 11. As I don't have the use case where the app needs access to a file that's stored outside of an app-specific directory. Is this understanding correct?
In case if I want to read a file that is placed under the Downloads folder, I need to implement the Scoped Storage because my app wants to access the file which is stored outside of an app-specific directory. Is this understanding correct?
You are definitely allowed to make and access files in /storage/emulated/0/Android/data/ using the File API. As far as I can tell there's no change to those locations. I have done it.
For access to files in Download yes, scoped storage is required from what I've read. I haven't tested this but the docs are pretty clear that it's the law in Android 11. A bad law, but the law nonetheless.
Related
As google have changed storage security in android 11 and WRITE_EXTERANL_STORAGE won't work. So can we save images on phone without permission of user?
If you want to write any file in the External storage, then you must have WRITE_EXTERNAL_STORAGE permission in your app below android 10.
In android 10, you can use requestLegacyExternalStorage=true in the application tag in your manifest. It will provide you the access to write file anywhere in External storage.
But it's a temporary solution as it'll be removed in the future. So the best solution is using SAF (Storage Access Framework) or Scoped Storeage.
SAF : It's an Android framework to secure user's files and help developers in managing files. However, different API levels require different approaches to manage and access files. Higher API level means more restrictions given to developers.
Scoped Storage : After you update your app to target Android 11, the system ignores the requestLegacyExternalStorage flag. So you must use Scoped storage or SAF to write any file into the storage.
With scoped storage, you can't write any files in the External storage in android 11 even If you have Write storage permission. It will be ignored. You can write your files in app's internal storage or in the Media directory related to the file you're writing.
For example, if you are going to write an Image, then you must write it in DCIM directory, For Videos - Movies, For Document - Documents, and so on.
The best part about scoped storage is that you don't need write storage permission in Android 10 & above and you can still write the files in their respected directories. If you're writing the image & your custom directory is not created in the storage, then android will automatically create it while writing the file. You don't have to do file.mkdir().
But if you want to write any file in the out of your app's scope, then you have to clarify why you need to do that while releasing the apk on Playstore.
And only File operations related apps can get that approval because most of apps do not need to write files out of their scope in the External storage.
So if you are writing files in android 10 or above, then simply don't request write permission, request only read storage permission if you're using Scoped storage or SAF.
I have some downloadable content (e.g.:game character image) in a app, in iOS they are saved to path NSCachesDirectory, which I follows the guidelines of iOS that downloadable content should be saved in NSCachesDirectory, which is a cache directory. I am struggling if I should save the files to getCacheDir() in android side.
At first I think the cache folder in iOS should be equivalent (or similar) to the one in android, but after looking at some doc I doubt if they are functionally identical:
1.iOS suggest some downloadable content to save in cache folder, such content is more persist temporary file in tmp. But in android, the doc says getCacheDir() should store cache files rather than persist files, it makes me suspect android cache folder works more like the tmp folder in iOS
2.I cannot find any size limit guideline on iOS cache file, but android side says it should have reasonable size limit, say 1 MB (and I think my content would be far more than 1 MB, say 50 to 100 MB).
So my question is, are iOS cache folder works functionally equivalent to cache folder in android? Is it correct to use getCacheDir() at android side at the place that I use NSCachesDirectory in iOS side? if not,which path should I use at android side when I use NSCachesDirectory at iOS side?
No, iOS cache folder doesn't works functionally equivalent to cache
folder in android.
For more details of all the data-storage options of Android have a look at official docs here.
In Android for storing large amount of data you can go with either Internal or external data-storage options, Also you can make your data private on Internal or external data-storage options if you need so.
Internal storage
Each application has its own private internal storage to save files. This is the kind of storage to use if the user shouldn’t be able to modify the file from outside your application, and if other application shouldn’t be able to access those files. Since the internal storage is private to your application, the files will be deleted if your application is uninstalled. The internal storage is also where your application is installed by default, so your files will always be available. On some older or cheaper devices the internal storage is quite limited, so you need to be careful about the size of the data you save if you need to support those devices.
You should never hardcode the path to the storage directories, since the directory may changes depending on the version of the Android OS used. Also, Android 4.4 introduces the concept of multiple users : in that case, the internal and external storage depend on the user logged in and the files of the other users will be invisible. Here are some of the methods used to get the paths to the internal storage:
android.content.Context.getFilesDir(): returns a java.io.File object representing the root directory of the internal storage for your application from the current context.
android.content.Context.getDir(String name, Context.MODE_PRIVATE): returns a java.io.File object representing the directory name in the internal storage, creating the directory if it does not exists. The second parameter can also be used to set the directory to MODE_WORLD_READABLE or MODE_WORLD_WRITABLE so it is visible by all the other applications, but this is is risky security-wise and was deprecated in API level 17 (Android 4.2).
android.content.Context.getCacheDir(): returns a java.io.File object representing the internal cache directory for the application. This is mean for small files (the documentation suggests no more that 1MB total) that can be deleted at any time when the system needs more storage. There is no guarantee that the cache will be cleared, so you must also clear those files manually when they are not needed anymore.
As you can see, the files are represented by the File object from the java.io namepace: there is no file object specific to the Android SDK and the standard Java APIs for reading and writing files are used. Also, there is no specific application permission to set in the Android manifest to use the internal storage since it is already private to the application.
External storage
In addition of the internal storage, there is an external storage space shared by all the applications that is kept when your application is uninstalled. This is the storage that is shown when using a file explorer application and when the device is plugged in your computer. It may be implemented as a SD card that can be removed or as a partition of the built-in storage in the device, so your application should be able to work even if the card is removed or changed. To check the current state of the external storage, you can call the getExternalStorageState() method.
On device with many users (starting with Android 4.4), the external storage is specific to the current user and files for other users can’t be accessed. Also, there may be more than one external storage if the device has a built-in external storage which is a partition on the internal memory and a SD card: in that case, the built-in storage is the primary external storage. Reading files from the external storage requires the READ_EXTERNAL_STORAGE permission and writing or reading files requires the WRITE_EXTERNAL_STORAGE permission.
Here are the methods you should use to call to get the directories of the primary external storage:
android.os.Environment.getExternalStorageDirectory(): returns a java.io.File object representing the root directory of the primary external storage of the device that is shared by all applications.
android.os.Environment.getExternalStoragePublicDirectory(): returns a java.io.File object representing a public directory for files of a particular type on the primary external storage of the device. For example, you can get the path to the public music directory by calling Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_MUSIC) or the public pictures directory by calling Environment.getExternalStoragePublicDirectory(Environment.DIRECTORY_PICTURES).
android.content.Context.getExternalFilesDir(): returns a java.io.File representing the root directory of the primary external storage specific to your application, which is under the directory returned by getExternalStorageDirectory(). Unlike the other directories of the external storage, the files you store in that folder will be deleted when your application is uninstalled. So, if you need to store files that are only needed by your application you should use this folder. Also, there is no specific permission needed for the application to read or write to its own external storage starting with Android 4.4, but with older versions your application needs the READ_EXTERNAL_STORAGE or WRITE_EXTERNAL_STORAGE permission.
android.content.Context.getExternalFilesDirs(): returns an array of java.io.File representing the root directories of all the external storage directories that can be used by your application with the primary external storage as the first directory in the array. All those directories works the same as the primary storage returned by the getExternalFilesDir() method. If the device has a built-in storage as the primary external storage and a SD card as a secondary external storage, this is the only way to get the path to the SD card. This method was introduced in Android 4.4, before that it was impossible to get the path to the secondary storage.
android.content.Context.getExternalCacheDir(): returns a java.io.File object representing the cache of the application on the primary external storage. This cache is not visible to the user and is deleted when the application is uninstalled. There is no mechanism in the Android SDK to delete files in the cache directory, so you need to manage your cache to keep it to a reasonable maximum size. Starting with Android 4.4, the application does not need permission to access its own cache, but with older versions your application needs the READ_EXTERNAL_STORAGE or WRITE_EXTERNAL_STORAGE permission.
I'm trying to read a file from a folder on my Galaxy S4. When I place the file in the root directory, I can access it without problems:
File f = new File(Environment.getExternalStorageDirectory().getAbsolutePath(), "MyFile");
But I want to put my file in a subdirectory. When I make a folder 'A', place my file inside of it and try to access it with:
File f = new File(Environment.getExternalStorageDirectory().getAbsolutePath() + File.separatorChar + "A", "MyFile");
I can't read it. Do I need some kind of permission and what's the logic behind that, when I can access the root?
You can read here:
http://developer.android.com/reference/android/os/Environment.html#getExternalStorageDirectory()
that access to this folder is not recomended:
Applications should not directly use this top-level directory, in order to avoid polluting the user's root namespace. Any files that are private to the application should be placed in a directory returned by Context.getExternalFilesDir, which the system will take care of deleting if the application is uninstalled.
Also, permission is required:
Writing to this path requires the WRITE_EXTERNAL_STORAGE permission, and starting in read access requires the READ_EXTERNAL_STORAGE permission, which is automatically granted if you hold the write permission.
[edit]
Also, since you are using s4 - which is probably 4.4+ device, you should know that since KitKat Google has disallowed write access on removable media, you can only read it, or write it to your application folder:
http://commonsware.com/blog/2014/04/09/storage-situation-removable-storage.html
As a result, apps can read files on removable media using the various undocumented and unsupported tricks for finding removable media. However, apps cannot write to or otherwise modify such removable storage. Note that device manufacturers themselves may have ways of dealing with this, but ordinary app developers do not.
Where does downloaded files stored in android when there is no memory card and how to access it from my application?
They are stored in device's internal storage, if you haven't chosen to store it in the sd-card. Internal storage make use of linux file system permissions, so files will private to your application and other applications cannot access them.
If you are talking about media files, you can make them accessible everywhere by adding them in their respective content providers. To open a file use openFileOutput() which return a file stream.
You should read the article on Storage Options which also provides a code example for accessing the external storage.
I currently use Environment.getExternalStorageDirectory() to obtain a location where I can store some data temporarily and then after being used gets deleted. This data can range from 1-100MB.
This works fine but on some cases the state of the external storage is removed or unmounted etc... and I can't access to store my data...
My question is what could be a good fallback solution when this storage is not available?
I'm targeting Android 1.6 and greater.
Note that you should not use the path returned by Environment.getExternalStorageDirectory() directly:
Applications should not directly use this top-level directory, in
order to avoid polluting the user's root namespace. Any files that are
private to the application should be placed in a directory returned by
Context.getExternalFilesDir, which the system will take care of
deleting if the application is uninstalled. Other shared files should
be placed in one of the directories returned by
getExternalStoragePublicDirectory(String).
Use the path returned by getFilesDir() to store files private to your app on the internal storage, or getExternalFilesDir() to store on the external storage.
If you're storing data temporarily, consider using the cache directories.
These files will be ones that get deleted first when the device runs
low on storage.
Use the methods: getCacheDir() or getExternalCacheDir() on the external filesystem. Read the documentation for important differences between them.
If the size of the data to be stored is not large, you'd be better off using the internal storage. Otherwise, you'll have to managing the complexity of detecting if external storage is available, falling backing to internal storage if not.