What are the different storage methods in Android?

Overview of data and file storage

Android offers several options for you to save your application data. The solution you choose depends on your specific needs, such as how much space your data requires, what type of data you need to store and whether the data must be private for your application or accessible for other applications and the user.

This page presents the different data storage options available on Android:

What are the different storage methods in Android?

Internal file storage: Store private application files in the device’s file system.

External file storage: Store files in the external shared file system. Save public data to the shared external storage

Shared preferences: Store private primeval data in key/value pairs. This is sometimes limited because it only offers key-value pairs. You cannot save your own Java types.

Databases: store structured data in a private database.

Except for some types of files in external storage, all these options are intended for private application data; The data is not naturally accessible to other applications. If you want to share files with other applications, you must use the FileProvider API. 

If you want to expose your application data to other applications, you can use a ContentProvider. Content providers give you full control of what read/write access is available to other applications, regardless of the storage medium you have chosen for the data (although it is usually a database). 

Related post: Overview of Android Application Development

Internal storage

By default, files stored in internal storage are private for your application, and other applications cannot access them (or the user, unless they have root-access). This makes internal storage a good place for internal application data that the user does not need to access directly. The system provides a private directory in the file system for each application where you can organize any file your application needs

When the user uninstalls his application, the files saved in the internal storage are deleted. Because of this behavior, you should not use internal storage to save anything that the user expects to persist regardless of your application. For example, if your application allows users to capture photos, the user would expect them to be able to access those photos even after uninstalling their application. Therefore, you should use the MediaStore API to save those types of files in the appropriate media collection.

Internal cache files

If you want to store certain data temporarily, rather than store it persistently, you must use the special cache directory to save the data. Each app has a private cache directory specifically for these types of files. When the device has limited internal storage space, Android may delete these cache files to recover space. However, you do not have to rely on the system to clean these files for you. You must always maintain the cache files yourself and stay within a reasonable limit of space consumed, such as 1 MB. When the user uninstalls your app, these files are removed.

External storage

Each Android device supports a shared “external storage” that you can use to save files. This space is called external because it is not guaranteed to be available – it is a storage space that users can mount on a computer as an external storage device, and it can even be physically removed (such as an SD card). Files saved to external storage are world-readable and can be modified by the user when they allow USB mass storage to transfer files to a computer.

So before you try to access a file in external storage in your app, you should check if the availability of the external storage directories is as well as the files you are trying to access.

Most often, you should use external storage for user data that should be available to other apps and saved even if the user uninstalls your app, such as photographed images or downloaded files. The system provides common public directories for these types of files, so the user has a place for all their photos, ringtones, music and the like.

You can also save files to external storage in an application-specific directory that the system deletes when the user uninstalls your app. This can be a useful alternative to internal storage if you need more space, but the files here are not guaranteed to be available as the user can remove the SD card for storage. And the files are still readable in the world; they are only stored in a location that is not shared with other apps.

Shared preferences

If you do not need to store much data and it does not require structure, you should use SharedPreferences. With SharedPreferences APIs, you can read and write persistent key-value pairs of primitive data types: booleans, floats, ints, links, and strings.

Key-value pairs are written to XML files that remain over user sessions, even if your app is killed. You can manually enter a name for the file or use files per activity to save your data.

The API name “shared preferences” is a bit misleading as the API is not strictly for saving “user preferences”, for example, which ringtone a user has chosen. You can use SharedPreferences to store all types of simple data, such as the user’s high score. However, if you want to save user preferences for your app, you should read how to create a setting user interface, which uses AndroidX Preference Library to build a settings screen and automatically resume user preferences.


Android provides full support for SQLite databases. Any database you create is only available through your app. Instead of using SQLite APIs directly, we recommend that you create and interact with your databases with the Room persistence library.

The room library provides an abstraction layer with object mapping that enables fluid database access while utilizing the full power of SQLite.

Although you can still save data directly with SQLite, SQLite APIs are fairly low-level and require a lot of time and effort to use. For example:

  • There is no verification of compile-time for raw SQL queries.
  • When your schema changes, you must manually update the affected SQL queries. This process can be time-consuming and error-prone.
  • You need to write lots of boiler code to convert between SQL queries and Java data objects.

The room persistence library addresses these concerns while providing an abstraction layer over SQLite.

Troubleshooting databases

The Android SDK includes a sqlite3 database tool that lets you browse table contents, run SQL commands, and perform other useful functions on SQLite databases. 

Shared by Android training in Chandigarh

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Create a free website or blog at WordPress.com.

Up ↑

Create your website with WordPress.com
Get started
%d bloggers like this: