emtee40 / apk-patcher Goto Github PK

APK-Patcher - Flashable Zip Template for Modifying System APKs On-Device
by osm0sis @ xda-developers

APK modification can be a tedious task. If you want to provide modified APKs you copy it to PC to decompile using Java applets like baksmali and apktool, make changes and recompile using another Java applet, smali (or apktool again). Then there's the pitfall of different recompiled APKs being required for the various different ROMs, etc., not to mention across Android versions. So, considering Android runs a version of Java runtime and the primary tools are Java-based I wondered why we couldn't do all of this on-device and on-the-fly so modifications could be applied via recovery, to whatever ROM APK was present, and take the constant update burden off of the modification creator.

I have taken these commandline Java applets, dexed them to allow them to run on-device, and found/built static ARM compiles of zip, zipalign and aapt to run on the various Android versions and devices. These binaries would need to be recompiled for other architecture support. The zip is smart and automated, using the APK name to run all the various parts involved for complicated patches and is extensible to any number of APKs in a single zip. The modification creator needs to only add the APK name(s) to a list, figure out how to make the changes universally (i.e. sed, awk, etc.) then add the commands to scripts of the same name, and add any whole-file additions/changes in subdirectories of the same name.

A proof-of-concept working script automating the long known Facebook Contacts Sync modifications to ContactsProvider.apk is included for reference.

// Properties / Variables (envvar.sh)

banner="Facebook Contacts Sync Enabler";
apklist="ContactsProvider.apk";
apkbak=/data/media/APK-Backup;
backup=1;
cleanup=1;

banner is the name of your patch zip, usually suggestive of what it does, to be displayed at the beginning of the zip flash. You should include your name/handle here like "by osm0sis @ xda-developers" for credit purposes.

apklist is a string containing the list of APKs to be patched included in the patch zip, separated by spaces between the quotes. Each APK is automatically found recursively in /system, then copied to the working directory to be decompiled and acted on, then copied back to /system.

apkbak is the location to place backups of the untouched APKs in apklist if backup=1 is set.

backup=1 will store backups of the untouched APKs in the location specified in apkbak.

cleanup=0 will keep the zip from removing it's working directory in /tmp/apkpatcher or any of the files resulting from the smali process - this can be useful if trying to debug in adb shell whether the patches worked correctly. cleanup=1 is necessary on multi-APK patching zips to clean the baksmali classout directory for the next APK, so it's recommended each APK to be patched be tested on their own with cleanup=0 before combining into a single zip.

// Instructions

1a- Place any required script to alter the decompiled APK classes.dex smali files in /script as a -smali.sh file with the name of the APK
1b- Place any required/additional updated whole smali files in /patch under the name of the APK with "-smali" and the relative path within the classes.dex file (including com)
2a- Place any required script to alter the decoded APK resources.asrc files in /script as a -res.sh file with the name of the APK
2b- Place any required/additional updated whole resource files in /patch under the name of the APK with "-res" and the relative path within the zip/resources.asrc file (including res)
3- Modify the envvar.sh to add your banner, apklist, backup and cleanup options
4- Modify the extracmd.sh to add any additional commands to be performed at the end of the patching process that aren't patch-related (/data file changes, etc.)
5- zip -r9 UPDATE-APK-Patcher.zip * -x README UPDATE-APK-Patcher.zip

As a general rule, whole-file adding is best used only for including a file that doesn't already exist, and the more surgical script-work should be used to keep things more universal.

If supporting a recovery that forces zip signature verification (like Cyanogen Recovery) then you will need to also sign your zip using the method I describe here:
http://forum.xda-developers.com/android/software-hacking/dev-complete-shell-script-flashable-zip-t2934449


Have fun!