Home Page » News » Tutorials » How to Extract, Decompile, Modify, and Re‑install an Android APK Without Root

Extract, Decompile, Modify and Re‑install an Android APK Without Root

18 min read Learn a step‑by‑step method to pull an APK from your Android device, decompile it with Apktool, make safe edits, rebuild, sign and reinstall – all without rooting. October 11, 2026 03:00

Sometimes you need to change a tiny detail in an app you already own – perhaps a misleading app name, a low‑resolution launcher icon, or a hard‑coded URL that you want to replace. Doing this without rooting the device is possible, but it requires a careful workflow to avoid breaking the app or losing data. This tutorial walks you through every step: pulling the APK from the device, decompiling it with Apktool, making a safe edit, rebuilding, signing, and finally reinstalling the modified package.

Before you start

Computer requirements: Windows, macOS, or Linux with Java JDK 8+ installed.
Android tools: adb (from Android SDK Platform‑Tools), zipalign and apksigner (both shipped with the Android SDK Build‑Tools).
Decompilation tool: Apktool (latest stable release).
Backup strategy: The original APK and, if the app stores data locally, a backup of its data (via adb backup or the app’s own export feature).
USB debugging enabled on the device (Settings > Developer options > USB debugging).
Charging: Keep the phone plugged in; a power loss during adb operations can corrupt the backup.

All steps use adb over a USB cable. Wi‑Fi adb works as well, but a wired connection is more reliable for large APKs.

Step 1 – Pull the original APK from the device

Connect the phone to the computer and verify the connection:
```
adb devices
```
You should see a device ID followed by device. If not, reinstall the USB driver (Windows) or enable adb over TCP/IP (macOS/Linux).
Find the package name of the app you want to modify. The easiest way is:
```
adb shell pm list packages | grep -i "part‑of‑name"
```
Replace part‑of‑name with a fragment you recognise (e.g., com.whatsapp).
Locate the APK path on the device:
```
adb shell pm path com.example.app
```
The command returns something like package:/data/app/com.example.app-1/base.apk. Note the path after package:.
Copy the APK to your computer:
```
adb pull /data/app/com.example.app-1/base.apk ./original.apk
```
The file original.apk now resides in the current folder.

At this point you have a pristine copy of the app exactly as the device sees it. Keep this file untouched – you will need it later if you want to revert.

Step 2 – Verify the APK’s signature (optional but recommended)

Android enforces that an update must be signed with the same certificate as the installed version. If you plan to replace the app without uninstalling, you must preserve the original signing key. Because you cannot extract the private key, the only practical way is to keep the original APK and use the same key when rebuilding.

Inspect the certificate chain:
```
apksigner verify --print-certs original.apk
```
The output shows the SHA‑256 fingerprint and the signer’s name. Write these down for later comparison.
If the output contains UNKNOWN or the command fails, the APK may be using Google Play App Signing. In that case you cannot sign a replacement with the same key; you must uninstall the app first (see the Uninstall & Re‑install section).

Step 3 – Set up Apktool and decompile the APK

Download the latest apktool.jar and the accompanying wrapper script (apktool for Linux/macOS or apktool.bat for Windows) from the official GitHub releases.
Place both files in a folder that is on your PATH (or keep them side‑by‑side with the APK you are working on).
Decompile:
```
apktool d original.apk -o app_decompiled
```
The command creates a directory app_decompiled containing resources, manifest, and smali code.
If you see an error like Failed to collect resources, make sure you have Java 8 or newer and that the APK is not a split APK (multiple .apk files). For split APKs, repeat the adb pull step for each split_* file and place them together before decompiling.

Decompilation does not recover the original Java source, but the smali files are enough for most resource‑level tweaks.

Step 4 – Make a safe modification

We will demonstrate two common edits: changing the displayed app name and swapping the launcher icon. Both are purely resource changes and do not require touching the code.

4.1 Change the app name

Open app_decompiled/res/values/strings.xml in a text editor.
Locate the entry with name="app_name". It will look like:
```
<string name="app_name">Original Name</string>
```
Replace Original Name with your desired name, e.g., My Custom App. Save the file.

4.2 Replace the launcher icon

Navigate to app_decompiled/res/mipmap-*/ic_launcher.png (there are several density folders: mdpi, hdpi, etc.).
Prepare a replacement PNG of the same dimensions (or larger; Android will scale down). Keep the filename identical (ic_launcher.png).
Overwrite each ic_launcher.png file with your new image. If you only replace the xxxhdpi version, Android will scale it for lower densities, which is acceptable for a quick test.
Optional: If the app uses adaptive icons (ic_launcher_foreground.png and ic_launcher_background.png), replace those as well.

These edits are reversible – you can always restore the original files from the backup created in Step 1.

Step 5 – Rebuild the APK with Apktool

Run the rebuild command:
```
apktool b app_decompiled -o modified_unsigned.apk
```
Apktool will compile resources and produce an unsigned APK named modified_unsigned.apk.
If the build fails with messages about missing files, double‑check that you did not delete any required resource (e.g., AndroidManifest.xml).

The resulting APK is structurally correct but cannot be installed until it is signed.

Step 6 – Sign the rebuilt APK

Android requires every APK to be signed. You have three practical options:

Use the debug keystore (quick, but will not match the original signature – you must uninstall the original app first).
Generate a new keystore and keep it for future updates of the same modified app.
Reuse the original signing key – possible only if you have the original keystore (rare for third‑party apps).

For a typical user the debug keystore is sufficient.

Locate the debug keystore (usually at ~/.android/debug.keystore on macOS/Linux or %USERPROFILE%\.android\debug.keystore on Windows).

Sign the APK:

apksigner sign --ks ~/.android/debug.keystore \
    --ks-key-alias androiddebugkey \
    --ks-pass pass:android \
    --key-pass pass:android \
    --out modified_signed.apk modified_unsigned.apk

Adjust the paths if you are on Windows.

Verify the signature:
```
apksigner verify --verbose modified_signed.apk
```
The output should say Verified using v1 scheme (JAR signing) and/or v2 scheme.

Step 7 – Align the APK (optional but recommended)

Alignment optimises the APK for faster loading on the device. The zipalign tool is part of the Android SDK Build‑Tools.

Run:

zipalign -v -p 4 modified_signed.apk modified_aligned.apk

From now on, use modified_aligned.apk for installation.

Step 8 – Install the modified APK

Whether you can install over the existing app depends on the signing key:

If you used the original signing certificate (rare), you can install as an update.
If you used a different key (debug keystore), you must uninstall the original version first.

8.1 Preserve app data (if you need it)

Back up the app’s private data (requires Android 9+ or the app to allow backup):
```
adb backup -f app_backup.ab -apk com.example.app
```
You will be prompted on the device to confirm the backup.
After reinstalling, restore the data:
```
adb restore app_backup.ab
```
If the app does not allow backup, consider using adb shell pm clear com.example.app to wipe data before reinstall, then use the app’s own export/import feature.

8.2 Install the APK

If you need to uninstall first, run:
```
adb uninstall com.example.app
```
Warning: Uninstalling removes all private data unless you performed the backup step above.
Install the aligned APK:
```
adb install -r modified_aligned.apk
```
The -r flag tells adb to replace an existing app if the signatures match.
Watch the console output. A successful install ends with Success.

Launch the app on the device. You should see the new name in the app drawer and the new launcher icon on the home screen.

Troubleshooting common issues

INSTALL_PARSE_FAILED_INCONSISTENT_CERTIFICATES

This error means the device already has an app signed with a different certificate. Solutions:

Uninstall the existing app (adb uninstall com.example.app) and reinstall.
If you cannot uninstall (e.g., a system app), you must obtain the original keystore – which is usually impossible for third‑party apps.

apktool: Failed to collect resources

Causes:

Missing aapt binary – ensure you have the Android SDK Build‑Tools installed and that aapt is on your PATH.
Corrupted APK – pull the file again.

Signature verification fails after signing

Possible reasons:

Incorrect keystore password – double‑check the password you supplied.
Using an older apksigner version that does not support v2 signing – update the Android SDK Build‑Tools.

App crashes immediately after install

When you modify resources, the app’s code may still reference the original resource IDs. If you renamed a string that is referenced in code (e.g., via R.string.app_name), the compiled code still expects the original ID, but the ID is unchanged – so this usually does not crash. However, if you removed an entire resource file or changed the package name, the app may throw Resources$NotFoundException. Re‑check that you only edited existing entries, not removed them.

Google Play App Signing blocks the install

Apps distributed through the Play Store often use Google’s signing service. The APK you pulled is signed with a Google‑managed certificate that you cannot replicate. In this case you must uninstall the Play‑installed version before installing the modified one, and you will lose automatic updates.

Edge cases and advanced considerations

Split APKs (Android App Bundles): Modern apps may consist of a base APK plus configuration splits (language, density, etc.). Pull each split_*.apk file with adb pull, place them in a single folder, and decompile the base APK. When rebuilding, you can re‑package splits using apktool b with the --use-aapt2 flag, but this quickly becomes complex. For simple visual tweaks, modifying only the base APK is usually sufficient.
ProGuard / R8 obfuscation: The Java code is minified, but resource IDs remain readable. Changing resources does not interfere with obfuscation, but if you plan to edit smali code, you must understand the obfuscation mapping.
App integrity checks: Some apps verify their own signature at runtime (e.g., banking apps). If they detect a mismatched certificate, they will refuse to run. In such cases, the only safe path is to keep the original signature – which is not feasible without the original keystore.

Safety warnings and best practices

Legal aspect: Modifying an app may violate its terms of service. Use this workflow only for apps you own or for personal experimentation.
Backup everything: Keep the original APK, a copy of the decompiled folder, and a data backup before you start.
Test on a secondary device or an emulator before deploying on your primary phone.
Never share modified APKs with others unless you are sure the changes do not introduce security risks.

Wrap‑up

By following the steps above you can safely extract an installed Android app, decompile it with Apktool, make resource‑level customisations, rebuild, sign, align, and reinstall – all without rooting the device. The workflow respects Android’s security model: you never need elevated privileges, and you keep a clean backup path to revert if something goes wrong. With this knowledge you can personalise launcher icons, correct misleading strings, or replace embedded assets, giving you more control over the software you already own.

User Comments (0)

Add Comment

No comments added yet.

Add Comment

Your Name: *

Comment Title: *

Your E-mail: * We'll never share your email with anyone else.

Your Comment: *

Comments will not be approved to be posted if they are SPAM, abusive, off-topic, use profanity, contain a personal attack, or promote hate of any kind.