I have some questions about the cache directory in android.
Does anyone knows the limit for each app's cache directory?
Also what will happen if there is not enough disk space to cache data? All I know is when the device runs low on storage, the files here (cache directory)will be the ones that get deleted first and each app has its own cache directory. Now, are the files of other app's cache directory will be cleared to accommodate my app's request to add files in the cache dir when there is not enough storage?
There is no per-application limit for the cache directory. While Linux has a quota subsystem built-in, it is not used by Android. Applications share the cache filesystem without any real constraints. As it fills up, the Device Storage Monitor sends out an ACTION_DEVICE_STORAGE_LOW broadcast and calls a method of the Package Manager Service that sends a "freecache" command to the Install Daemon. The installd process then walks through the cache directory deleting files without regard to the owning application or modification date until the amount of free space available is above some threshold.
Related
When I delete files that are stored in external storage e.g. photos
Is there a way to delete the file using a 'hard' delete such that it cannot be recovered easily?
i.e. if other apps have access to external storage, I don't want them recovering photos that were deleted already
Ordinary apps without root access already have no means to recover deleted files. Once unlink is invoked, the file is gone, period.
Apps with root access can potentially recover an unlinked file by directly reading raw virtual device files (/dev/storage/*). Both removing a file and moving it to different directory merely removes directory entry without touching file contents (they are simply marked as "unused" if file is no longer referenced anywhere). Thus it is possible to gather residual sectors, that previously belonged to file and haven't been overwritten since removal. Preventing this can be varying degree of hard depending on specific filesystem. The external filesystem on most external storage is vFAT. In vFAT it is possible to prevent residual sectors by opening the file before removing and overwriting it's full length with zeroes. Other filesystems (most notably, Samsung's F2FS) might take measures, that make securely removing files a lot harder due to wear-leveling built directly into the filesystem itself.
Do not bother with defending against circuit-level wear-leveling. It happens on such low level, that recovering the data is infeasible without butchering the phone and using a tunneling microscope. Only flash controller firmware can see that data, and most controllers do not allow access to the flash firmware from OS programs.
Of course, you still have to ensure, that the file haven't been cached in some secondary storage facility (for example, the thumbnail of image may have gotten cached in thumbnail cache, or in system MediaProvider). And of course, some other program might have copied the file to somewhere prior to the removal. Therefore, the safest way to assure "secure removal" is encrypting the files: even if someone steals them prior to removal or restores their contents after removal, without a decryption key those contents are useless. Byte-by-byte overwrite comes second.
Some people might suggest a tough brute-force approach: after unlinking a file, create a throwaway temporary file and fill it with amount of random data equal to free space remaining on partition. That will efficiently defeat all forms of wear-leveling and prevent file recovery in most cases. Unfortunately, this method is very slow, extremely taxing on flash memory and does not defend against apps, that previously copied the file.
"unlinking" is a term, traditionally used to describe removal a file in Linux (google for "inodes"). Removing a file with File#delete does unlink it
I think if you are worried about data protection from recovery, you should complete next steps:
open a file for writing
write a random sequence of data instead of real data in this file
delete that file.
Background
On android, you can create temporary files as such (link here and here for documentation) :
final File temp = File.createTempFile("myFile", ".tmp", context.getCacheDir());
I'm developing an app that uses temporary files and when it's done with them (and on start of the app), it deletes them.
The question
The documentation says :
When the device is low on internal storage space, Android may delete
these cache files to recover space.
Does it mean that files can get deleted even while my app is still running? In which cases would android be allowed to delete the files?
In other words , can I assume that as long as I have the app running , android won't delete the files by itself, even if other apps create their own temporary files?
You will can test it. Create new app, app write data to file and than internal stroge full. When internal stroge full Android delete applications cache directory which app store above 1Mb. If applications cache dir trashed, Android deleted even while the app is running. Otherwise while app running Android never deleted cache files.
This is the original link shared by developer.android.com
http://developer.android.com/reference/android/content/Context.html#getCacheDir()
Note: you should not rely on the system deleting these files for you; you should always have a reasonable maximum, such as 1 MB, for the amount of space you consume with cache files, and prune those files when exceeding that space.
I am trying to decide where to store images that are sent as part of instant messages coming in to an app. These messages are viewable in a conversation history view for sometimes a significant period of time after their original receipt. You can imagine any number of other use cases that would have a similar requirement, so the question here is on the "best practice for storing an indeterminate quantity and size of images"
Assumptions
SQLite storage is clearly a bad option since the image size is not
bounded.
It is neither desirable nor undesirable that these images be publicly available to other apps or discoverable by MediaScanner. We are assumed to be perfectly neutral on this point...
This leaves two parts to this question:
1. External Storage
It seems like external storage is to be preferred when available because it is likely to have more room than anything else:
The documentation says the following:
...use getExternalCacheDir() to
open a File that represents the external storage directory where you
should save cache files. If the user uninstalls your application,
these files will be automatically deleted. However, during the life of
your application, you should manage these cache files and remove those
that aren't needed in order to preserve file space.
Unlike internal storage cache, there is no statement made about the automatic reclamation of space on external storage by Android. Still the word "cache" makes me nervous.
Question 1: Do these files remain until explicitly deleted regardless?
Question 2: Is there any other external storage other than the cache that is automatically deleted upon app uninstall AND is preferable to the external cache for some specific reason?
2. Internal Storage
Clearly not every device has external storage, so there needs to be a provision for internal storage.
Question 3: Is the only practical difference between the internal cache retrieved through getCacheDir() and files created with openFileOutput(FILENAME, Context.MODE_PRIVATE) that Android may delete files in the cache directory when under pressure for storage space?
Do these files remain until explicitly deleted regardless?
I haven't read the code, but the javadoc explicitely says
The platform does not monitor the space available in external storage, and thus will not automatically delete these files. Note that you should be managing the maximum space you will use for these anyway, just like with getCacheDir().
Is there any other external storage other than the cache that is automatically deleted upon app uninstall AND is preferable?
None that I know of.
practical difference between the internal cache retrieved through getCacheDir() and files created with openFileOutput?
It's just a facility method, AFAIK
Okay so I've noticed that even though I use the correct path for the cache folder Android doesn't register the content in the folder so the user can't delete the cache content by going into settings -> programs -> administrate -> select program -> clear cache. The folder is deleted properly on uninstal but not if the user actively try to clear the cache. This is not a major issue but its still a minor problem because the user don't get a proper idea of how much space the application uses at the SD card.
Is there anything I as developer can do to update these values or am I doing something wrong somewhere else?
From the docs:
Saving cache files
If you'd like to cache some data, rather than store it persistently,
you should use getCacheDir() to open a File that represents the
internal directory where your application should save temporary cache
files.
When the device is low on internal storage space, Android may delete
these cache files to recover space. However, you should not rely on
the system to clean up these files for you. You should always maintain
the cache files yourself and stay within a reasonable limit of space
consumed, such as 1MB. When the user uninstalls your application,
these files are removed.
I guess you should handle the removal of yourself. If you want to remove the content if the user cleans the app data create a sharedPreference and clean the cache when the app starts and that preference is not defined.
What must I do that Android can delete my cache files on the sdcard with the GUI?
I saved some data in /sdcard/Android/data/my.package.name/cache but Android tells me that my app has 0B cached data. That is wrong!
You should never hardwire paths -- for example, your path shown above is incorrect for most Android devices, as /sdcard is not where external storage resides. You should be using getExternalCacheDir() for external cache and getCacheDir() for internal cache.
Bear in mind, as the documentation states:
There is no guarantee when these files will be deleted. Note: you should not rely on the system deleting these files for you; you should always have a reasonable maximum, such as 1 MB, for the amount of space you consume with cache files, and prune those files when exceeding that space.
(emphasis theirs)
I could not find valid source of this but after multiple tests I am most certain that external storage does not show up under this "clear cache" button.
It's on you to clear cache manually