Storage is this thing we are all aware of, but always take for granted. Not long ago, every leap in storage capacity was incremental and appeared to be impossible. Nowadays, we don’t give a second thought when contemplating how much of it our devices have (and could care less about the differences).
A bigger point would be to look at the evolution of what is stored in memory. Before smartphones, we saved the occasional photo or two, some games and a ton of text messages. But now, any standard phone will have a concoction of applications, documents, photos, videos, music files, and more. Let’s find out how we can utilize a devices’s storage space for our applications.
What we’re going to cover in this article is:
- The different types of storage on Android phones
- Differences between the types of storage
- How to use storage in your application
Each application has access to two different types of storage: internal and external. There are major differences between these two types of storage, and knowing them will help you when designing your next application.
Before we begin, one thing must be said about storage and cache. Storage is meant for things you want to save persistently, while cache is there to save things temporarily.
When each application is run on the operating system, it has it’s own internal storage. This storage is private and only for the use of the application. Meaning, other applications cannot access it, nor can the user. Another thing to keep in mind when using internal storage is the availability of it. Unlike external storage, internal storage is always available for your application.
Using this storage has it’s drawbacks, though. If the user removes the application, all the data stored in your app’s internal storage is removed as well. Imagine what would happen if you installed a game on your phone and somewhere down the road decided to remove it. You would like to have your game progress saved, if by any chance you would install the game again.
So, how do we save a file to internal storage?
As you can see in the code example, we are saving a file called hello_world_file that contains the text, “Hello From Internal Storage!”. I have created two catch clauses just to demonstrate the exceptions that may occur when trying to do this, but you can minimize them to one catch clause with the general Exception object.
Pay attention that the method openFileOutput will open the file if it already exists, but if not, will create it. The second parameter to this method is the file mode. This parameter designates the scope of the file and access to it. The default value is MODE_PRIVATE, which makes the file accessible to your application only. The other two values for this parameter are MODE_WORLD_READABLE and MODE_WORLD_WRITEABLE, but they have been deprecated since API 17. Sharing private files with other applications uses a different set of logic that you can read more about here. Finally, when writing to the file, we convert our string to bytes and we make sure to close the file at the end.
Contrary to what the name implies, this is storage that is defined by the fact that it is not always accessible. This may mean that it can be an external SD card (secondary external storage), but it can also be storage found on the device (primary external storage). To bring the fact home, external storage is storage that can be accessed when you connect your device to a computer via a USB cable. As you may have guessed, anything stored in this type of storage is accessible to other applications on your device, but will be kept if you uninstall the application.
Before we can demonstrate how to save files to the external storage, we need to do two things:
- Make sure there is enough space there to save the file
- Ask for permission during runtime
Making sure there is enough storage space requires the following lines of code:
To get access to the external storage, we need to add the following permission to our AndroidManifest.xml:
Furthermore, since API 23, dangerous permissions aren’t authorized during install time, but during runtime. Writing to external storage is categorized as one, so we need to add logic to allow the user to decide whether to grant the application permission or not.
Our writeFileToExternalStorage looks like this:
If you want to see an example of all the code presented here, you can head over to this GitHub repository.
Good To Know
Above were just two simple examples of how to work with the different types of storage for your application. Since we are dealing with a resource that the system manages, we should also be aware of the behaviors associated with it.
By default, your application will be installed to internal storage (see internalOnly explanation), but from API level 8, you can add an attribute, installLocation, to your manifest that lets your application be installed to external storage. One reason for doing so is if your application is very large, and you would prefer the user to install it on the device’s external storage since there is more space there.
There are three values for this attribute:
- auto – means that you don’t have a specific preference where the application will be installed. The application will try to be installed to internal storage, but if it is full, it will install it inside external storage
- internalOnly – the application will only be installed to internal storage, and if there isn’t enough space there, it will not be installed
- preferExternal – means that you want your application to be installed to external storage, but if there is not enough room there, it will be installed internally
For both the auto and the preferExternal options, the user has the option of moving the application from external storage to internal, and vice versa.
Keep in mind that once a user connects their device to a computer and enables it to share data or unmounts an SD card, all applications running from the external storage are destroyed. If your application uses one of the following features, you should not install it to external storage:
Various services (alarm services in particular), Input Method Engines, Live Wallpapers, Application Widgets, Account Managers, Sync Adapters, Device Administrators and Broadcast receivers listening for boot completed.