11 May 2026 Leave a comment Tech-Help
If you need to inspect a database or other app files stored under /data/data/<package-name>, the good news is that you often do not need to root the device. The right approach depends on whether the app is debuggable, whether you are using Android Studio, and whether you only need a one-time copy of the file or a more permanent workflow.
What is and is not possible
- Direct browsing on a regular phone: generally not allowed without root.
- Debug builds: usually accessible through developer tools.
- Production builds: access is much more limited, and in many cases you must use an export or backup strategy instead.
Best options, from easiest to most practical
1) Use Android Studio’s Device File Explorer for debug builds
If your app runs in debug mode, Android Studio can expose the app’s private storage through Device File Explorer. This is the simplest option when you are actively developing and want to inspect files quickly.
How to do it:
- Open Android Studio.
- Go to View > Tool Windows > Device File Explorer.
- Expand
/data/data/<package-name>. - Browse into
databases,files, or other folders as needed.
Important: this works only for apps that are debuggable on a non-rooted device.
2) Use run-as with ADB for debuggable apps
For many developers, this is the most reliable command-line solution. If the app is debuggable, run-as lets ADB act as the app’s user and access its private files.
Example:
adb shell
run-as com.your.packagename
cp /data/data/com.your.packagename/databases/your.db /sdcard/your.dbA more compact and commonly used variant is:
adb exec-out run-as com.your.packagename cat databases/your.db > your.dbThis is especially useful when you want to copy a database from the device to your computer without modifying the app.
3) Use Android’s backup mechanism when ADB access is limited
If you cannot use Device File Explorer or run-as, backup-based extraction can still help. This method is useful when you need app data from a device that allows backups and the app is included in the backup.
Typical flow:
- Run a backup command such as
adb backup -noapk com.your.packagename. - Confirm the backup on the device.
- Convert the resulting backup file into a readable archive format.
This approach is more cumbersome, but it can be a practical fallback when direct file access is blocked.
4) If you control the app, export the database yourself
For apps you are building, a very clean solution is to copy the database to shared storage from inside the app. That way, you can retrieve it without needing privileged access to the private app directory.
This is often the best long-term approach for QA, support, and debugging workflows.
Which method should you choose?
- You have a debug build: use Device File Explorer or
run-as. - You need a quick one-off copy: use
adb exec-out run-as ... cat ... > file. - ADB access is restricted but backups are allowed: use the backup route.
- You own the app and need repeatable access: add an export path inside the app.
- You are on a production device and the app is not debuggable: direct access is usually not possible without root.
Common mistakes to avoid
- Trying to browse
/data/dataon a non-rooted production device and expecting full access. - Forgetting that
run-asonly works for debuggable apps. - Using backup extraction without checking whether the app is actually included in the backup.
- Assuming file permissions can be changed from the phone itself without elevated access.
Recommended workflow for developers
If you are actively testing an app database or internal file, the most efficient workflow is usually:
- Run the app in debug mode.
- Use Device File Explorer or
adb exec-out run-asto pull the file. - Inspect the file on your computer with your preferred tool.
- If you repeat this often, automate the process.
For related ADB tasks, you may also find these guides helpful:
- How to copy a database file from an Android device with ADB pull
- Accessing SQLite database on Android devices without root
- Retrieving application names using ADB shell
When rooting is the only option
If the app is not debuggable, backups are disabled or ineffective, and you need true direct access to private app storage on the device itself, then root is typically required. That is the boundary Android enforces to protect app data.
How Repeato can help
If your goal is not just to inspect one file but to repeatedly verify app behavior around local data, Repeato can fit nicely into that workflow. It is a no-code test automation tool for iOS, Android, and web apps, with fast test recording and execution. Because it supports command-line scripts and JavaScript for more complex steps, you can combine UI checks with automated file-related test flows, while keeping test assets in text and JSON format for easy version control.
In practice, that makes it easier to automate scenarios where you need to validate that data was saved correctly, exported, or restored without manually repeating the same ADB steps every time.
