Export, Edit, and Re‑Import Android App Data Using ADB (No Root)

15 min read Learn step‑by‑step how to back up an Android app’s data with ADB, modify files like SQLite databases or XML preferences, and restore the edited data without rooting your device. October 11, 2026 16:30 How to Export, Edit, and Re‑Import Android App Data with ADB (No Root)

Sometimes you need to tweak an app’s internal files – for example, change a hidden setting, fix a corrupted SQLite database, or replace a configuration XML. Doing this without rooting the device is possible, but it requires a careful workflow that preserves data integrity and respects Android’s security model. This tutorial walks you through the entire process: creating a backup with adb, converting the backup to a manipulable archive, editing the files you need, repackaging the data, and finally restoring it to the device.

Before you start

  • PC with ADB installed – Windows, macOS, or Linux. The official platform‑tools package from Google works for all platforms.
  • USB cable – Use a good quality cable; a flaky connection will abort the backup.
  • Battery level – Keep the phone above 50 % or connect it to a charger.
  • App package name – You’ll need the exact com.example.app identifier. You can find it in Settings > Apps or by running adb shell pm list packages | grep part‑of‑name.
  • OpenSSL (optional but recommended) – Used to unpack and repack the .ab backup. Most Linux/macOS systems have it; Windows users can install the binary from https://slproweb.com/products/Win32OpenSSL.html.
  • File‑editing tools – A SQLite browser (e.g., DB Browser for SQLite) for database files, and a plain‑text editor for XML or JSON files.
All steps below assume you have enabled USB debugging on the device. If you haven’t, see the first section.

1. Enable Developer Options and USB Debugging

  1. Open Settings → About phone.
  2. Tap Build number seven times. You’ll see a toast that says “You are now a developer!”.
  3. Return to the main Settings screen; a new entry Developer options appears.
  4. Enter Developer options and toggle USB debugging on.
  5. If your device runs Android 12 or newer, you may also need to enable USB debugging (Security settings) to allow ADB to access app data.

When you connect the phone to the PC for the first time after enabling debugging, a dialog will ask you to Allow USB debugging? Confirm and optionally tick “Always allow from this computer”.

2. Verify the ADB connection

Open a terminal (Command Prompt, PowerShell, or a Linux shell) and run:

adb devices

You should see a line with your device’s serial number followed by device. If you see unauthorized, check the phone screen for the confirmation dialog.

3. Create an ADB backup of the target app

The adb backup command creates a single .ab file that contains the app’s private data. The command syntax is:

adb backup -f <output_file.ab> -noapk -nosystem <package_name>

Explanation of the flags:

  • -f – Destination file on the PC.
  • -noapk – Skip the APK itself; we only need the data.
  • -nosystem – Exclude system apps (saves space).

Example – backing up the app com.example.notes to notes_backup.ab:

adb backup -f notes_backup.ab -noapk -nosystem com.example.notes

After you run the command, the phone will display a “Full backup” screen. You can set a password (recommended) or leave it blank for an unencrypted backup. Remember the password if you set one – you’ll need it later.

The backup process can take a few seconds to a few minutes depending on the size of the app’s data.

4. Convert the .ab file to a standard .tar archive

The .ab format is a simple wrapper around a tar archive, optionally encrypted with OpenSSL’s aes‑256‑cbc. To unpack it, follow these steps:

  1. Open a terminal in the folder containing notes_backup.ab.
  2. If you used a password, run:
    openssl aes-256-cbc -d -in notes_backup.ab -out notes_backup.tar -pass pass:YOUR_PASSWORD
    Replace YOUR_PASSWORD with the actual password. If you left the backup unencrypted, skip the OpenSSL step and extract directly (see below).
  3. Strip the 24‑byte ADB header that precedes the tar data:
    dd if=notes_backup.ab bs=24 skip=1 of=notes_backup.tar
    This command works on Linux/macOS. Windows users can use certutil -decodehex or install a Unix‑like environment such as Cygwin.

Now you have notes_backup.tar, a regular tar archive that can be opened with any archive manager.

5. Extract the archive and locate the app’s data files

Run:

tar -xf notes_backup.tar -C notes_backup

This creates a folder notes_backup containing the app’s data hierarchy. The structure mirrors the device’s internal storage layout, typically:

apps/com.example.notes/

Inside you’ll find subfolders such as files/, shared_prefs/, databases/, and possibly cache/. These are the locations you can edit.

6. Edit the data you need

What you edit depends on the problem you’re solving. Below are three common scenarios.

6.1 Modifying a SharedPreferences XML file

SharedPreferences are stored as XML under shared_prefs/. Open the file with any text editor.

<?xml version="1.0" encoding="utf-8"?>
<map>
    <string name="username">old_user</string>
    <int name="launch_count" value="42" />
</map>

Change the values you need – for example, set username to new_user. Save the file and keep the same filename.

6.2 Editing an SQLite database

Databases reside in databases/ and usually have a .db extension. Use a desktop SQLite browser:

  1. Open the .db file.
  2. Navigate to the table you need to modify.
  3. Right‑click a cell and edit its value, or run an UPDATE SQL statement.
  4. Save the changes (most browsers have a “Write Changes” button).

Be careful not to change the schema (add/drop columns) unless you know the app expects it.

6.3 Replacing a media file

If the app stores user‑generated images or audio under files/, simply replace the file with another of the same name and format. Preserve the exact filename and extension; otherwise the app may fail to locate it.

When editing any file, keep a copy of the original (e.g., shared_prefs_original.xml) so you can revert if the app crashes.

7. Re‑package the edited data into a .tar archive

After you finish editing, recreate the tar archive preserving the original directory structure.

tar -cf notes_modified.tar -C notes_backup .

The trailing dot (.) tells tar to archive everything inside notes_backup.

8. Convert the .tar back to an .ab backup

If you used a password for the original backup, you’ll need to re‑encrypt the tar file. The steps are the reverse of section 4.

  1. Add the 24‑byte ADB header back. The header is constant for unencrypted backups, but for encrypted ones you can simply prepend the string ANDROID BACKUP followed by version and flag bytes. An easier method is to let OpenSSL create the final .ab for you:
  2. openssl aes-256-cbc -e -in notes_modified.tar -out notes_modified.ab -pass pass:YOUR_PASSWORD
  3. If you prefer an unencrypted backup, just prepend the header using cat (Linux/macOS):
  4. printf "ANDROID BACKUP\n1\n0\n" | cat - notes_modified.tar > notes_modified.ab

Now notes_modified.ab is ready for restoration.

9. Restore the edited backup to the device

Run the restore command:

adb restore notes_modified.ab

The phone will display a “Restore data” screen. If you set a password during encryption, enter the same password.

Wait for the process to finish – you’ll see a confirmation toast once the restore completes.

After the device reboots (some apps request a restart), launch the app. The changes you made should be visible: the new username, updated database rows, or swapped media file.

10. Verify the result and clean up

  • Open the app and navigate to the area you modified. Confirm the new values appear.
  • Check the app’s stability – if it crashes, revert to the original backup (see step 5) and restore it.
  • Delete the intermediate .tar and extracted folders if you no longer need them, or keep them for future edits.

Alternative method: Direct adb pull/push with run-as

Some debug builds expose the run-as command, allowing you to pull files from an app’s private directory without creating a full backup. This method is faster but works only if the app is debuggable.

# Switch to the app’s UID
adb shell "run-as com.example.notes ls /data/data/com.example.notes/files"
# Pull a file
adb pull /data/data/com.example.notes/files/config.xml .
# Edit locally, then push back
adb push config.xml /data/data/com.example.notes/files/config.xml
# Ensure correct permissions
adb shell "run-as com.example.notes chmod 600 /data/data/com.example.notes/files/config.xml"

If run-as returns “run-as: Package ‘com.example.notes’ is not debuggable”, you’ll need to fall back to the full backup method described above.

Troubleshooting common issues

Backup fails with “adb: error: device unauthorized”

Re‑connect the USB cable, unlock the phone, and confirm the debugging dialog. On some devices you must also enable “USB debugging (Security settings)” under Developer options.

Restore reports “Backup password incorrect”

Make sure you typed the exact password used during backup. Passwords are case‑sensitive and spaces count. If you forgot it, the only safe option is to create a new backup without a password.

App crashes after restore

  • Check that you didn’t alter the database schema or delete essential files.
  • Inspect logcat for stack traces:
    adb logcat -d | grep com.example.notes
  • If the crash points to corrupted XML, replace the edited file with the original copy.

“openssl: error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt”

This indicates a wrong password or a corrupted .ab file. Verify the password and, if possible, re‑create the backup.

Edge cases and limitations

  • Apps that store data in the Android Keystore – Private keys are hardware‑backed and cannot be exported or edited. Editing related files will break the app.
  • Device‑protected storage (DPFS) – Introduced in Android 7.0, data stored under device_protected may not be included in a regular backup. Use adb backup -all if you need those files, but be aware they are often system‑level.
  • Scoped storage restrictions – From Android 10 onward, apps may keep files on external storage that are not part of the private data backup. Those files must be copied separately (e.g., via adb pull /sdcard/Android/data/com.example.notes/).

Safety warnings

  • Always keep an untouched copy of the original .ab file before you start editing. Restoring from a corrupted backup can leave the app in a broken state.
  • Editing app data may violate the app’s terms of service, especially for games or banking apps. Use this technique only for personal experimentation or legitimate troubleshooting.
  • Never share edited backups that contain personal data. If you need to distribute a modified APK, create a fresh backup without personal information.

When to use this workflow

This method shines in three typical scenarios:

  1. Recovering from a corrupted local database – e.g., a notes app that won’t open because the SQLite file is damaged.
  2. Testing hidden preferences – developers often hide “debug mode” toggles in SharedPreferences that can be enabled manually.
  3. Porting configuration between devices – moving a custom ringtone set stored in app files without reinstalling the app.

For bulk migrations or regular backups, consider using adb backup without editing, or a dedicated backup app that handles encryption automatically.

By following the steps above you can safely peek inside an Android app’s private storage, make the precise changes you need, and restore the data without ever rooting the device. The process respects Android’s security boundaries, keeps your data encrypted if you choose, and gives you a repeatable workflow for future tweaks.

User Comments (0)

Add Comment
We'll never share your email with anyone else.