How to make a Release Android App debuggable (Android R+)

release-android-debuggable.md

How to make a Release Android App debuggable (Android R+)

This is a newer version with a bit more details and workarounds from this gist. Especially for Android R+.

I recommend to read the previous gist to get an idea about what I'm trying to achieve. This note will be straight forward on commands to perform. Some commands use zipalign and apksigner which are located in the build-tools of your Android SDK installation folder. Mine are located in: ~/Library/Android/sdk/build-tools/34.0.0/.

Get a list of packages

$ adb shell pm list packages -f -3

Note that it can look something like: /data/app/~~0G1inQaszOmFyQ6_gL8FXw==/com.mypackage-0bbMNtW7uMoucJFqS710qA==/base.apk=com.mypackage

In this case the portion to take is: /data/app/~~0G1inQaszOmFyQ6_gL8FXw==/com.mypackage-0bbMNtW7uMoucJFqS710qA==/base.apk

Pull the app into your computer

In this case the command would be

$ adb pull /data/app/~~0G1inQaszOmFyQ6_gL8FXw==/com.mypackage-0bbMNtW7uMoucJFqS710qA==/base.apk

And potentially the app file will be base.apk.

Disassemble the app using apktool

$ apktool d -o output-dir base.apk

Patch AndroidManifest file

In output-dir, find AndroidManifest.xml and open it in a text editor of your choice. In the application xml node, add the following xml attribute: android:debuggable="true".

• If allowBackup attribute exists, make sure its value is true.
• If extractNativeLibs attribute exists, make sure its value is true.

Here is a snapshot of the modified version:

<application 
  android:debuggable="true"
  android:allowBackup="true"
  android:extractNativeLibs="true"

Reassemble the app into a new apk file

$ apktool b output-dir -o com.mypackge.patched.apk

• If you get error similar to:

W: invalid resource directory name: ../output-dir/res navigation
brut.androlib.AndrolibException: brut.common.BrutException: could not exec (exit code = 1): [..]

You need to add --use-aapt2 extra flag as following:

$ apktool b output-dir -o com.mypackge.patched.apk --use-aapt2

• If you get errors similar to:

-124: Failed parse during installPackageLI:
 Targeting R+ (version 30 and above) requires the resources.arsc of installed APKs
 to be stored uncompressed and aligned on a 4-byte boundary

You need to zipalign the file:

zipalign -f -p 4 com.mypackge.patched.apk com.mypackge.patched.aligned.apk

Note the modified file name as output com.mypackge.patched.aligned.apk, this is the file to conitnue this guide with. Note that this error is probably happening during installation attempt and won't appear now. If so, you have to zipalign before signing the file.

Create a self signed keystore for signature

$ keytool -genkey -v -keystore resign.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000

And you can fill the intractive prompts with any data. Make sure to remember the password created in this process.

Sign the patched apk file

The old documentation was using jarsigner which is not recommended. Instead, use apksigner:

apksigner sign --ks resign.keystore com.mypackge.patched.apk

When asked, use the password created from the previous step.

Install the file back into device

This step requires that you uninstall the original app from your Android device. Otherwise you will get an error similar to:

Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE:
 Existing package com.mypackage signatures do not match newer version; ignoring!]

I could not find a method (without root) to preserve /data/data/com.mypackage files or re-assign this folder to the modified app. If someone knows a good solution please share in comments below.

Here is to uninstall the previous app:

$ adb uninstall com.mypackage

And then install the patched app:

$ adb install com.mypackage.patched.apk

Now is there any possible way to link the patched app with the original data folder? Please let me know!

I automated this process a couple years ago for classical APKs: https://github.com/julKali/makeDebuggable
The idea is to directly decode the manifest without touching anything else, thereby circumventing many anti-debug techniques where apktool would fail. It worked much better for high-security apps such as online banking which for example encode filenames with UTF-16 characters which, at least at the time, messed with the repackaging logic of apktool.
I have since left the space a bit, so I am unfortunately not up to date on the internal workings of xAPKs and such. If someone is and has some time on their hands, I would kindly ask you if you could share your thoughts, perhaps in an issue or contribution :)