Where the SQLite database is stored on Android

Mobile application developers and system administrators are often faced with the need for direct access to data generated by apps. In the ecosystem, the de facto standard for local storage of structured information is the engine. Understanding where these files are physically located is critical for debugging, data migration, or disaster recovery. Android the de facto standard for local storage of structured information is the engine SQLite. Understanding where these files are physically located is critical for debugging, data migration, or disaster recovery.

By default, the operating system isolates the space of each application, creating a so-called "sandbox". This means that the database files are not publicly accessible on a drive visible to the user, but are hidden in protected system directories. Accessing them without special privileges (root access) or using debugging tools like adb is impossible.

In this article we will analyze the Android file structure in detail, indicate the exact paths to the files .db and .sqlite, and also consider the nuances of working with them in modern versions operating system. You will learn how to find the database of a specific application and what restrictions Google's security policy imposes.

Standard path to database files

Each application installed on the device receives a unique user identifier (UID) and its own directory in the internal memory. It is here, deep in the system partition /data, that all the app’s private information is located, including settings, cache and databases.

The absolute path to the SQLite store looks like this:

/data/data/<package_name>/databases/

Here <package_name> is replaced with the actual application package name, for example com.example.myapp. Inside this folder you will find files with extensions .db, .sqlite or without any extension at all, if the developer has not explicitly specified one. Next to the main database file there are often satellite files: -shm and -wal, which are responsible for the logging mechanism and performance.

⚠️ Attention: The directory /data/data is not available for viewing through standard file managers on devices without root access. An attempt to open it without elevated privileges will result in an access error.

The storage structure is the same for all versions of Android, starting with the earliest releases. However, access to this data is strictly regulated by the system kernel. If you are developing an application in Android Studioenvironment, you can easily (browse) these files through the tool Device File Explorer, which automatically bypasses debugging restrictions.

Access features on devices with and without Root

The situation with access to files changes dramatically depending on the status of superuser rights on your smartphone. On regular (“stock”) devices, the system blocks reading the directory /data for all processes except system ones and the owner application itself.

If you have root access, the situation is simplified. You can use advanced file managers, such as Root Explorer or Solid Explorerto navigate to the system path, copy the database file to internal storage (/sdcard) and open it with any SQLite editor.

• 🔒 Without root: Access is only possible through the ADB debugging bridge with debuggable rights or through an application backup.
• 🔓 With root: Direct access to the file system, the ability to edit and copy files to any folder.
• 🛠 Emulators: In Android Studio emulators, access to /data/data is open by default for all installed applications.

For devices without root, there is a workaround through the command run-as in the ADB console. This command allows you to temporarily switch the execution context to the user of a specific application if it is built in debuggable mode.

adb shell
run-as com.example.myapp
cd databases
ls

After executing these commands, you will find yourself inside a protected directory and can upload the database file to your computer with the command pull. This is a legal and safe way to obtain data for analysis without hacking the system.

Using Android Debug Bridge (ADB) for extraction

Toolkit ADB is the most professional method of working with databases on real devices. It does not require root access, but requires that the "USB Debugging" mode be enabled in the developer settings.

The process of extracting the database consists of several stages. First you need to make sure that the device is connected and visible in the system. Then we use the command adb pull to copy the file from the protected area to the developer's local computer.

Command	Description of action	Required rights
adb devices	Checking device connection	USB debugging
adb shell run-as <pkg>	Changing user to application owner	Debuggable application
adb pull /path/to/db	Copying a file to PC	Access via run-as or root
adb backup	Creating a full application backup	Backup permission

It is important to note that the command run-as works only with applications that have the flag android:debuggable="true" in the manifest. Most applications downloaded from Google Play are compiled in release mode and do not allow you to use this method directly.

⚠️ Attention: The interface and availability of ADB functions may depend on the firmware version and device manufacturer. Some vendors (for example, Xiaomi or Huawei) may require additional permissions in the developer menu.

In such cases, an alternative may be to create a full backup of the application using the command adb backup -f backup.ab com.package.name, then convert the file .ab to .tar and extract the database from the archive.

How to convert .ab to .tar?

Use the abe (Android Backup Extractor) utility. Command: java -jar abe.jar unpack backup.ab backup.tar. After that, unpack the tar archive using standard OS tools.

Security Policy and Scoped Storage

Starting with Android 10 and especially in Android 11+, Google has implemented a policy Scoped Storage (Cloud Storage). This initiative further limited application access to the file system, although the system directory /data/data was less affected than shared memory.

The main goal of these changes is to prevent third-party apps from accessing the private data of other applications. Even if you install a file manager that requests all permissions, it will not be able to see the contents of the folder databases of another application without explicit intervention by the system or root access.

• 📂 Isolation: Applications no longer see each other's files in the shared storage.
• 🛡 Data protection: User data protected from leaks through vulnerabilities in third-party software.
• ⚙️ System access: Only the application itself and system services have full control over their files in /data/data.

For developers, this means that data exchange mechanisms must be rebuilt to use Storage Access Framework or ContentProvider. Direct transfer of database file paths between applications is now blocked by security.

SQLite file structure and logs

When examining the contents folders databases you can find not one file, but several. This is normal and is due to the peculiarities of the SQLite engine operating in WAL (Write-Ahead Logging) mode, which is enabled by default in modern versions of Android.

The main file contains the table structure and data. However, additional files are used to ensure the integrity and speed of recording. Understanding their purpose is necessary for correct copying of the database - if you copy only the main file, the data may be out of date or the database will not open.

A typical set of files looks like this:

mydb.db — the main database file.

mydb.db-wal — the Write-Ahead Log file. Changes that have not yet been checkedpointed to the main file are stored here.

mydb.db-shm —a Shared Memory file used to coordinate access to the WAL file between processes.

⚠️ Attention: When copying a database to transfer to another device, be sure to copy all three files (.db,.wal,.shm). The absence of a WAL file can lead to the loss of recent records.

If you need to get a “clean” database file without logs, you can run the command VACUUM inside the DBMS before copying. This will force all data from the WAL into the main file and remove the supporting files.

sqlite3 mydb.db"VACUUM;"

Common errors and recovery methods

Working with system files always involves the risk of data corruption. The most common mistake is trying to open a database while an application is actively using it. This can lead to the file being locked or a copy being received with uncommitted transactions.

Another problem arises when transferring the database between devices with different architectures or versions of Android. If the database schema (schema version in SQLiteOpenHelper) does not match, the application may try to automatically update the database when launched or, in the worst case, crash with an error.

To avoid problems, follow these recommendations:

• ✅ Always make a backup copy of the original file before any manipulations.
• ✅ Check the integrity of the database with the command PRAGMA integrity_check; after copying.
• ✅ Make sure that the access rights to the copied file (chmod) correspond to the application's expectations.

If the database is damaged, sometimes deleting files helps -wal i -shm, but this is an extreme measure that is fraught with data loss. In case of critical errors, it is better to restore data from a cloud backup or repeat the export procedure.

Is it possible to open a SQLite database on the phone itself without a computer?

Yes, it is possible. You will need an SQLite editor application (for example SQLite Editor) and root access. Without root access, third-party applications will not be able to read files in the folder /data/data due to limitations of the Android system.

Where are the databases stored if the application is installed on an SD card?

Even if the application is moved to an external card (which is rare in modern Android), its private data, including SQLite databases, is still stored in the internal memory in the section /data/data. Only the cache and files explicitly saved by the developer to public storage are transferred to the SD card.

Why is the database file size 0 bytes?

A file size 0 bytes usually means that the database has been created, but no data has yet been written to it, or the table creation transaction has not been completed (commit has not been called). This can also happen if the application crashed during the initialization of the database.

How to find the name of the application package in order to find its base?

The package name can be found in the phone settings in the "Applications" section by clicking on the desired app. You can also use ADB commands: adb shell pm list packages will list all installed packages. To search for a specific application, use filtering, for example: adb shell pm list packages | grep telegram.