Developing mobile applications on the Android platform inevitably confronts engineers with the need to work with local data storage. Whether you're using a classic library, a modern library, or alternative solutions like Realm, understanding the physical structure of file storage is a critical debugging skill. Many novice developers spend hours searching for an answer to the question of where exactly in the file system of an emulator or a real device the tables and schemas they create are saved. SQLite, a modern library Room or alternative solutions like Realm, understanding the physical structure of file storage is a critical skill for debugging. Many novice developers spend hours searching for an answer to the question of where exactly in the file system of an emulator or a real device the tables and schemas they create are saved.
The default development environment Android Studio provides powerful tools for visualizing these processes, but direct access to system directories is often limited by superuser rights. Database files are not explicitly located on your computer's desktop; they are isolated within the application-specific sandbox. To extract them for content analysis or backup, you need to know the exact path and use specialized utilities built into the IDE or accessible via the command line.
In this article we will analyze in detail the data storage architecture, consider standard file paths .db and .sqlite, and also learn how to safely extract them from a working emulator. You'll learn how to bypass permission restrictions on rooted and non-rooted devices to effectively conduct data integrity testing of your software product.
The standard path to database files in an Android system
Every application in the Android ecosystem runs in an isolated space known as a sandbox. This means that files created by the app are, by default, inaccessible to other applications and to users without special privileges. Databases created using standard context methods are saved in a strictly defined directory inside the application's internal storage.
The absolute path to this storage is as follows: /data/data/your_application_package/databases/. Here your_application_package is replaced with the unique identifier specified in the file AndroidManifest.xml, for example, com.example.myapp. It is in this folder that you will find files with the extension .db, as well as accompanying transaction log files -wal and -shm, which are necessary for the correct operation of the mechanism WAL (Write-Ahead Logging).
It is worth noting that the directory structure may vary slightly if you are using specific storage configurations or contexts. For example, when using a device context or external storage, the path may change to /sdcard/Android/data/..., however, for full-fledged databases, the de facto standard remains a secure internal directory /data/data. It is not accessible to normal read operations without root privileges.
⚠️ Warning: Directly copying database files from a running application without stopping the process or using special flags may result in file corruption due to incomplete log transactions.
Using Device File Explorer in Android Studio
The most convenient and visual way to view the internal file system of the emulator is the built-in tool Device File Explorer. It allows you to (browse) the directory structure of the connected device in real time. To open it, go to the menu View → Tool Windows → Device File Explorer or click the corresponding icon on the right panel of the interface.
After opening the window, you will see a file tree. Follow the path data → data. This is where you'll run into the first problem: most folders with package names will be locked with a padlock icon. This means that you do not have permission to read their content. This protection is a fundamental part of Android security, preventing data leakage between applications.
However, if you are working with an emulator, the situation becomes simpler. Emulators based on x86 images often have root permissions by default or make them easy to obtain. In this case, you can expand your application folder, go to the subdirectory databases and see a list of files. You can drag the desired file .db straight to your computer's desktop to open it in a third-party editor, for example, DB Browser for SQLite.
If the application folder is locked even on the emulator, try restarting the emulator with the launch flag enabling root access, or use the adb root command in the terminal before connecting.
For physical devices, not with root access, direct viewing through this tool will not be possible. In such cases, developers often resort to creating debug versions of the application on rooted firmware or use the backup mechanism via ADB, which we will discuss next.
Accessing the database via the ADB command line
Tool Android Debug Bridge (ADB) provides a more flexible and powerful way to interact with the device’s file system compared to graphical interface. It allows you to execute Linux shell commands directly on the device. To get started, make sure that the platform tools are installed and added to the environment variables of your operating system.
The first step is to gain access to the device shell. Enter command adb shell in the terminal. If you are working with an emulator or a rooted device, the next step is to gain root privileges with the command su. Without this step, attempting to navigate to the directory /data/data will result in an access error. Permission denied.
adb shellsu
cd /data/data/com.example.app/databases
ls -l
After executing the command ls -l you will see a list of all the files in the database directory along with their access rights, owner and size. This allows you to verify that the database file actually exists and is non-zero in size. Next, you can use the command pull to extract the file to your local computer.
☑️ Checking access via ADB
The command for copying the file looks like this: adb pull /data/data/com.example.app/databases/mydb.db C:/Users/Admin/Desktop/. Note that the device path is listed first and the local destination path is listed second. This method is especially useful for automating testing processes when you need to regularly upload fresh data for analysis by scripts.
Features of working with Room and encrypted databases
Library Room, which is part of Android Jetpack, abstracts working with SQLite, but physically the files are stored in the same way. However, if you enable database encryption using the library SQLCipher or similar solutions, the file structure remains the same, but its contents become unreadable without the key.
When you try to open an encrypted file in the standard SQLite viewer, you will receive a file format error or "database disk image is malformed" message. This does not mean data corruption, but only indicates that reading requires entering the password or encryption key that was specified during configuration SupportSQLiteDatabase in your code.
| Storage type | File extension | Available for reading without a key | Viewer tool |
|---|---|---|---|
| Standard SQLite | .db,.sqlite | Yes | DB Browser, SQLiteStudio |
| Room (no encryption) | .db | Yes | Any SQLite editor |
| Room + SQLCipher | .db | No | DB Browser with SQLCipher plugin |
| Realm Database | .realm | No (specific format) | Realm Studio |
It is important to understand that the use of encryption imposes additional requirements on the debugging process. You will need to either implement a key transfer mechanism in the debug build, or disable encryption for test scripts in order to be able to quickly inspect the contents of tables.
What to do if you forgot the password for an encrypted database?
It is almost impossible to recover data without an encryption key due to the strength of the AES algorithms used in SQLCipher. The only option is to reset the application data or search for the key in the source code/debug logs.
Analyzing database contents with third-party utilities
After you have successfully extracted the database file to your computer, the analysis stage begins. The native Android Studio interface provides a basic table viewer that opens when you double-click on a file in a project or in Device File Explorer. It allows you to view data, run simple SQL queries, and even edit cells.
However, for in-depth analysis of complex schemas, relationships between tables, and performing heavy-duty queries, it is better to use specialized software. apps like DB Browser for SQLite or DBeaver offer advanced visualization of ER diagrams, syntax highlighting and convenient tools for exporting data to CSV or JSON formats.
When opening a file, make sure that you copy not only the main file .dbbut also files -wal and -shm, if present. These files contain cached data that has not yet been flushed to the main database file. If you open the main file without accompanying logs, you may see outdated data or receive an integrity error.
For correct analysis, always copy all three files (.db, -wal, -shm) to one folder on your computer before opening them in the editor.
In some cases, especially when working with large amounts of data, direct export through Android Studio may cause freezing interface. In such a situation, using the SQLite command line on the computer (sqlite3 mydb.db"SELECT * FROM users;") will be a much more productive solution.
Solving access problems on physical devices
Working with physical devices that do not have root access is the most difficult for a developer. The Android security system strictly prohibits access to the directory /data/data even through ADB for regular custom builds. This creates a barrier to directly debugging databases on real devices.
There is a workaround that does not require rooting the device. You can use the ADB backup feature, which is allowed for debug applications. The command adb backup -f backup.ab -noapk com.example.app will create an archive of application data. Then this file .ab needs to be converted into format .tar using the utility abe (Android Backup Extractor), and then extract the database file from there.
⚠️ Attention: Starting with Android 10 and higher, the security policy has become stricter, and the ability to create complete backups of application data via ADB may be limited by the device manufacturer or OS version.
An alternative and most reliable method for physical devices is to implement an export function in the application code. You can programmatically copy a database file from internal memory to a public folder Downloads or to an SD card, from where it can be easily retrieved via a USB connection using file transfer mode (MTP).
This approach does not require superuser rights and works on any devices where your debugging application is installed. It is enough to add a method that is executed by pressing a button in the hidden developer menu, and the file will be available for copying.
Frequently asked questions (FAQ)
Why can’t I see my application folder in Device File Explorer?
Most likely, your application is running on a physical device without root access. The system hides the content /data/data for security. Try running the application on an emulator or use the programmatic method of exporting the file to a shared folder.
Is it possible to edit the database directly in Android Studio?
Yes, the built-in database inspector allows you to view tables and run SQL queries. However, editing cells directly is not always possible and depends on the IDE version and connection type. For major changes, it is better to extract the file and use an external editor.
Where are the databases stored when using SharedPreferences?
SharedPreferences do not use the SQLite format. They are stored as XML files in the folder /data/data/your_package/shared_prefs/. The path is different from the standard database location.
What do the -wal and -shm files next to the database mean?
These are the Write-Ahead Log and Shared Memory files. They are used by SQLite to improve performance and data integrity. Do not delete them manually while the application is running.