sign files with a right click (Ubuntu) (Thanks Amon_RA)
-----------------------------------------------------------------------------------------------------------------
This little novice, 2-line script will help you sign update.zip files directly from any terminal window if you have the Android SDK set up on your machine. It might be pointless to some, but I thought it would be a nice idea to share.
Navigate to your Android SDK directory.
Create a folder and name it "sign".This is where you will put the update.zip that you want to sign.
Download the attached testsign.jar file [extract from zip] and move it to the new /sign directory in your Android SDK.
Navigate to your /tools directory and Right-Click > Create Document > Empty File.
Give it a name without extension.example: sign
Right-Click > Open with "Text Editor" and add the following:Change the directories according to your setup.
#!/bin/sh
java -classpath /AndroidSDK/sign/testsign.jar testsign /AndroidSDK/sign/update.zip /AndroidSDK/sign/update-signed.zip
Click to expand...
Click to collapse
Give it executable permissions with the terminal -
Code:
cd /YOUR-SDK-DIRECTORY/tools/
chmod a+x sign
Now you can simply drop the update.zip to your /sign directory and from the terminal type:
Code:
sign
and it will sign it without having to add the long command yourself.
Of course you can edit the script to fit your needs.
---- Optional ----
By making a link (right-click > Make Link) of your /sign directory and adding it to your Desktop, you can drag and drop update.zip directly to this link and sign. This save you some time in the signing process and you have access to it from your Desktop.
---- Optional ----
Thank you Cyanogen for this reply.
mods, please sticky this as i'm sure many will find this very informative
Perfect howto, just works like a charm Thanks to the author!
Thank you so much! Just started using ubuntu in a VM. Think you could write up a guide on setting up eclipse? That'd be absolutely super. Thanks again lol. Helped me sign files + set up the sdk. Great work.
alritewhadeva said:
Thank you so much! Just started using ubuntu in a VM. Think you could write up a guide on setting up eclipse? That'd be absolutely super. Thanks again lol. Helped me sign files + set up the sdk. Great work.
Click to expand...
Click to collapse
Well, setting up eclipse is fairly simple!
download Eclipse
unzip it any directory/AndroidSDK/Eclipse | /home/wddglr/Apps/Eclipse
set up the ADT following the information in this page: [http://developer.android.com/sdk/1.5_r3/installing.html]
wddglr said:
Well, setting up eclipse is fairly simple!
download Eclipse
unzip it any directory/AndroidSDK/Eclipse | /home/wddglr/Apps/Eclipse
set up the ADT following the information in this page: [http://developer.android.com/sdk/1.5_r3/installing.html]
Click to expand...
Click to collapse
Ah thank-you. I'll PM you if i run into any problems if thats okay. I'm a noob with ubuntu just set it up yesterday.
i love you man j/k
THANK UUUUUUUUUU so much man
if you use lots of different named update zips.
This is step 6
#!/bin/sh
echo -n "Source Zip Filename : "
read input
echo -n "Output Zip Filename : "
read output
java -classpath /androidsdk/sign/testsign.jar testsign /androidsdk/sign/"$input" /androidsdk/sign/"$output"
echo "Finished signing $input as $output"
Click to expand...
Click to collapse
Just input the source file and the output and it does the rest.
Was useful for me as I sign different zips.
Use as you wish, thanks to wddglr.
I don't know why I can never get this to work.
This is exactly what I see when I ls /AndroidSDK/sign:
[email protected]:~$ ls /AndroidSDK/sign
testsign.jar update.zip
[email protected]:~$ sign
Exception in thread "main" java.lang.NoClassDefFoundError: testsign
at gnu.java.lang.MainThread.run(libgcj.so.90)
Caused by: java.lang.ClassNotFoundException: testsign not found in gnu.gcj.runtime.SystemClassLoader{urls=[], parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(libgcj.so.90)
at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.90)
at java.lang.ClassLoader.loadClass(libgcj.so.90)
at java.lang.ClassLoader.loadClass(libgcj.so.90)
at gnu.java.lang.MainThread.run(libgcj.so.90)
Click to expand...
Click to collapse
Binary100100 said:
I don't know why I can never get this to work.
This is exactly what I see when I ls /AndroidSDK/sign:
[email protected]:~$ ls /AndroidSDK/sign
testsign.jar update.zip
Click to expand...
Click to collapse
I was wondering if you were you able to solve this? Becouse I'm getting the same.. I'm thinking it has something to do with jave. But not sure what I need to do to fix it.. thanks for any info ....
yea me toooo
edit i figured it out
Code:
# Right-Click > Open with "Text Editor" and add the following:
Change the directories according to your setup.
Quote:
#!/bin/sh
java -classpath [B]/AndroidSDK[/B]/sign/testsign.jar testsign /[B]AndroidSDK[/B]/sign/update.zip /AndroidSDK/sign/update-signed.zip
yeah that is not where my tools are lol
wddglr said:
sign files with a right click (Ubuntu) (Thanks Amon_RA)
-----------------------------------------------------------------------------------------------------------------
This little novice, 2-line script will help you sign update.zip files directly from any terminal window if you have the Android SDK set up on your machine. It might be pointless to some, but I thought it would be a nice idea to share.
Navigate to your Android SDK directory.
Create a folder and name it "sign".This is where you will put the update.zip that you want to sign.
Download the attached testsign.jar file [extract from zip] and move it to the new /sign directory in your Android SDK.
Navigate to your /tools directory and Right-Click > Create Document > Empty File.
Give it a name without extension.example: sign
Right-Click > Open with "Text Editor" and add the following:Change the directories according to your setup.
Give it executable permissions with the terminal -
Code:
cd /YOUR-SDK-DIRECTORY/tools/
chmod a+x sign
Now you can simply drop the update.zip to your /sign directory and from the terminal type:
Code:
sign
and it will sign it without having to add the long command yourself.
Of course you can edit the script to fit your needs.
---- Optional ----
By making a link (right-click > Make Link) of your /sign directory and adding it to your Desktop, you can drag and drop update.zip directly to this link and sign. This save you some time in the signing process and you have access to it from your Desktop.
---- Optional ----
Thank you Cyanogen for this reply.
Click to expand...
Click to collapse
I tried every way I could, and as stupid as I am, I could not get it to work!!!
[email protected]:~$ sign
bash: sign: command not found
[email protected]:~$ cd /home/ccriffman/android/tools
[email protected]:~/android/tools$ sign
bash: sign: command not found
[email protected]:~/android/tools$ cd /home/ccriffman/android
[email protected]:~/android$ sign
bash: sign: command not found
[email protected]:~/android$ cd /sign
bash: cd: /sign: No such file or directory
[email protected]:~/android$ cd /home/ccriffman/android/sign
bash: cd: /home/ccriffman/android/sign: No such file or directory
[email protected]:~/android$ cd /tools
bash: cd: /tools: No such file or directory
[email protected]:~/android$ cd tools
[email protected]:~/android/tools$ sign
bash: sign: command not found
[email protected]:~/android/tools$ cd sign
bash: cd: sign: Not a directory
[email protected]:~/android/tools$ sign
bash: sign: command not found
[email protected]:~/android/tools$
joe v said:
I was wondering if you were you able to solve this? Becouse I'm getting the same.. I'm thinking it has something to do with jave. But not sure what I need to do to fix it.. thanks for any info ....
Click to expand...
Click to collapse
Yeah, I got it to work. The problem was with my Java.
testsign.jar in wrong spot
I got mine fixed. I had testsign.jar inside of the testsign folder inside the sign folder.
testsign.jar needs to be in the 'root' of the sign folder, or you need to modify the sign script to point to the correct location.
pconwell said:
I got mine fixed. I had testsign.jar inside of the testsign folder inside the sign folder.
testsign.jar needs to be in the 'root' of the sign folder, or you need to modify the sign script to point to the correct location.
Click to expand...
Click to collapse
..... damnit.
I did the same thing
======EDIT=======
Now I am getting this error:
sign
No command 'sign' found, did you mean:
Command 'bsign' from package 'bsign' (universe)
Command 'psign' from package 'radiance' (universe)
sign: command not found
Click to expand...
Click to collapse
Help?
I guess it means I've failed???
This script worked great, I really appreciate it. I did modify it a bit so that I don't have to necessarily sign update.zip every time. It is similar to the script posted on the first page, but rather than it asking for the input and output, you simply add parameters to the sign command. For example:
Code:
sign <input> <output>
See the code below, make sure you change the directory to where you have the sign folder located.
Code:
#!/bin/sh
java -classpath /opt/android/sign/testsign.jar testsign /opt/android/sign/$1 /opt/android/sign/$2
echo "Finished signing $1 as $2"
Hope this helps anyone.
An even better modification is to make it only take ONE parameter:
#!/bin/bash
mv $1 /tmp/$$-$1
java -classpath /opt/android/sign/testsign.jar testsign /tmp/$$-$1 $1
rm /tmp/$$-$1
Note that this form is also independent of the location of the archive to sign -- it is nicer to enter that particular directory and just run "sign file.zip".
You should really mention that the tools directory has to be added to $PATH..
Not everyone has this, if you don't then simply typing sign will not work
wedsxcrfv said:
You should really mention that the tools directory has to be added to $PATH..
Not everyone has this, if you don't then simply typing sign will not work
Click to expand...
Click to collapse
Well it should be correctly assumed that $PATH was correctly set when they installed the Android SDK, because if they followed the instructions provided by the SDK's documentation then it says to set the $PATH var in "~/.bashrc" or "~/.bash_profile".
From: http://developer.android.com/sdk/installing.html
On Linux, edit your ~/.bash_profile or ~/.bashrc file. Look for a line that sets the PATH environment variable and add the full path to the tools/ directory to it. If you don't see a line setting the path, you can add one:
export PATH=${PATH}:<your_sdk_dir>/tools
Click to expand...
Click to collapse
I did this for myself, and thought I would share. I got tired of the "Raise volume above safe level?" warning, and I removed it. I like to learn, so rather than use the existing xposed framework mod, I built a flashable zip to make the change via framework-res.apk.
WARNING: I AM NOT RESPONSIBLE IF YOU MESS UP YOUR PHONE
Prerequisite:
ATT Moto X running stock official 4.4 kitkat (140.44.5)
TWRP or CWM (safestrap for those who don't have an unlocked bootloader, thanks Hashcode)
backup all of your data in case something goes horribly wrong
Instructions:
using your choice of file manager, backup /system/framework/framework-res.apk
Download or copy flashable zip (below) to sdcard
Reboot to [safestrap] TWRP recovery
flash zip file
Below are the 'broad strokes' of how I did this in linux: (Each of these steps below require various skills, and my intent is not to do too much 'hand holding.')
DUMP AND DECOMPILE framework-res.apk
make sure java 7 is installed
download/extract apktool_2.0.0b7.jar (thanks brut.all)
move /system/framework/framework-res.apk to apktool directory
install framework: java -jar apktool_2.0.0b7.jar if framework-res.apk
dump framework-res.apk: java -jar apktool_2.0.0b7.jar d framework-res.apk
--
CHANGE SETTING IN TWO FILES:
edit this file: framework-res/res/values/bools.xml
search for the line with this info: config_safe_media_volume_enabled
change the value to: false
repeat with framework-res/res/values-mcc310/bools.xml
--
DELETE DIRECTORY STRUCTURE (not sure why framework wouldn't compile with this, but it is unused on AT&T phones)
delete this directory: framework-res/values-mcc310-1
--
RECOMPILE AND COPY EXISTING SIGNATURE:
recompile: java -jar apktool_2.0.0b7.jar b framework-res -o framework-res-new.apk
move META-INF structure from inside the original framework-res.apk to the new framework-res-new.apk (I used 7z)
--
ZIPALIGN NEW FILE:
zipalign -f -v 4 framework-res-new.apk framework-res.apk
--
CREATE FLASHABLE ZIP WITH NEW framework-res.apk
you can use mine as a template and just replace my framework-res.apk under /system/framework
TWRP/CWM flashable zip: http://www.androidfilehost.com/?fid=23252070760973197
(Replaces /system/framework/framework-res.apk with my modified version.)
Trying this now on my Rogers ATT KK based Moto X. Ill update soon.
Updated script brakes at device check.
Sent from my XT1058 using XDA Premium 4 mobile app
slimdizzy said:
Updated script brakes at device check.
Sent from my XT1058 using XDA Premium 4 mobile app
Click to expand...
Click to collapse
Do you mean the updater-script in the flashable zip? If so, you can modify those checks for your phone if you can see the error. I used twrp->advanced->copy logs to /sdcard to see the error messages.
Ctrl-Freak said:
Do you mean the updater-script in the flashable zip? If so, you can modify those checks for your phone if you can see the error. I used twrp->advanced->copy logs to /sdcard to see the error messages.
Click to expand...
Click to collapse
Will do. Ill post shortly.
Update:
Installing '/sdcard/motox-att-140.44.5-framework-res-1.zip'...
Checking for MD5 file...
I:Cannot find file /sdcard/motox-att-140.44.5-framework-res-1.zip.md5
Skipping MD5 check: no MD5 file found.
I:Zip does not contain SELinux file_contexts file in its root.
script aborted: This package is for "ghost" devices; this is a "xt1060".
This package is for "ghost" devices; this is a "xt1060".
E:Error executing updater binary in zip '/sdcard/motox-att-140.44.5-framework-res-1.zip'
My build.prop shows 1058 for the record.
slimdizzy said:
Will do. Ill post shortly.
Update:
Installing '/sdcard/motox-att-140.44.5-framework-res-1.zip'...
Checking for MD5 file...
I:Cannot find file /sdcard/motox-att-140.44.5-framework-res-1.zip.md5
Skipping MD5 check: no MD5 file found.
I:Zip does not contain SELinux file_contexts file in its root.
script aborted: This package is for "ghost" devices; this is a "xt1060".
This package is for "ghost" devices; this is a "xt1060".
E:Error executing updater binary in zip '/sdcard/motox-att-140.44.5-framework-res-1.zip'
My build.prop shows 1058 for the record.
Click to expand...
Click to collapse
Did you build this from your Rogers framework? (If not, keep in mind my framework-res if from an AT&T phone. I have no idea if there are any differences.)
To continue, you can edit the updater-script and make the change from "ghost to "xt1060".
I have a rogers phone but ATT firmware. This is just what happens when I flash your zip. Your updated script asks for a 1058, which is my model but breaks and says my device is a 1060. That is nowhere in my prop. This should flash no problem and it doesn't. I even tried to manually overwrite using root explorer and my phone wouldn't boot after. I replaced original file and all is well.
Sent from my XT1058 using XDA Premium 4 mobile app
Thanks, this worked like a charm for my Moto G.
I used Advanced ApkTool v2.0.0 to decompile 'framework-res.apk',
I used Notepad++ to set all 'config_safe_media_volume_enabled' entries to false,
After the recompilation, I extracted the content of the original 'framework-res.apk' with 7-zip, and just replaced 'resources.arsc' with the modified one. (can be found in the '\build\apk' directory)
Recompressed again with 7-zip (compression level: store) and used adb to replace the file:
adb push framework-res.apk /sdcard/Download/framework-res.apk
adb shell
Code:
su
mount -o remount,rw -t ext4 /dev/block/platform/msm_sdcc.1/by-name/system /system
mv /system/framework/framework-res.apk /system/framework/framework-res.apk.bak
cat /sdcard/Download/framework-res.apk > /system/framework/framework-res.apk
chmod 644 /system/framework/framework-res.apk
sync
reboot
Hi XDA.
I have created automatic version of this One Click Signer:
(Click to thanx here FIRST! ->) http://forum.xda-developers.com/showthread.php?t=822388 (<- Click to thanx here FIRST!)
This version Works for Quantum of files at same time.
There are two DIRs:
Input - move here all APK and ZIP files to sign.
Output - here comes Signed APKs and ZIPs.
How to use?
1. Download auto-sign.zip from this thread.
2. Unzip it.
3. Run once autosign.bat.
4. Now, Input and Output folders was created.
5. Move all your Unsigned APK and ZIP files into Input folder.
6. Run autosign.bat again.
7. Wait until CMD windows closes.
8. Now you have Signed Your APKs and ZIPs in Output folder.
Click to expand...
Click to collapse
If you think, that is virus, or any harmful file,
you can right click on any .bat or .cmd file, and use EDIT option.
Here you can see all code, that files do.
Thanx to ASimmons, and dont forget to hit "Thanks!" button on his thread too! (link above)
Sorry for my BAD English.
//ANY PROBLEMS?
1. Output DIR is empty.
- move your auto-sign folder to root of C: drive, maybe run it as administrator.
2. Files are in output folder, but not signed
- check if you have Java Runtime SE Library, try to reinstall it.
if you have 64 bit system, and 64 bit Java, try to install 32 bit java too.
Thanks, gouster3.
Very easy to use Signer. However, using it to create an 'update.zip' package for my tablet was unsuccessful due to the 'zipalign' step at the end. So I reversed the steps as follows in "do2.cmd", then it was accepted (although this way the ZIP isn't fully aligned) :
Code:
setlocal EnableDelayedExpansion
@ECHO off
SET rom=%1
copy !rom! x!rom!
cd lib
rem zip align
zipalign -f 4 ..\x!rom! ..\signed-!rom!
rem sign the rom
java -Xmx512m -jar signapk.jar -w testkey.x509.pem testkey.pk8 ..\signed-!rom! ..\signed-!rom!
cd ..\
del x!rom!
Joe.
APK-Patcher -- Flashable Zip Template for Modifying System APKs On-Device from Recovery
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.
My development work on my many projects comes out of my free time, so if you enjoy this project or anything else I've done on xda, please consider sponsoring my ongoing work using my GitHub Sponsors profile. For a one-time donation you can hit the donate link from my profile. Thank you for your support!
Source: https://github.com/osm0sis/APK-Patcher/
Status: No Longer Updated
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
-b) 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
-b) 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:
[DEV][TEMPLATE] Complete Shell Script Flashable Zip Replacement + Signing [SCRIPT]
Enjoy!
Questions, comments and feedback welcome.
Credits & Thanks: JesusFreke for bak/smali, iBotPeaches for apktool, Surge1223 for help working out how to build zipalign and aapt, and all authors of the included binaries and those who ported them over for their amazing work.
Disclaimer: Naturally, you take all the responsibility for what happens to your device when you start messing around with things.
Script/Patch Reference
Properties / Variables (envvar.sh)
Code:
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.
osm0sis said:
Properties / Variables (envvar.sh)
Code:
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.
Click to expand...
Click to collapse
Did you happen to figure out how to cross compile jdk for arm? (different from the arm sources available from oracle etc)
..and nice work!
Surge1223 said:
Did you happen to figure out how to cross compile jdk for arm? (different from the arm sources available from oracle etc)
..and nice work!
Click to expand...
Click to collapse
Nah, just forced bak/smali and apktool to run by building/adding classes.dex for each of them and figuring out how to call a functional dalvikvm from recovery.
The first part was mentioned in passing (and quite awesomely) by JesusFreke back in 2011.
That got it running in booted Android. Then running from recovery was a whole other issue, but I stumbled upon Jim Huang's work on executing dalvikvm on Linux, and that lead me to figuring out a solution.
As it stands, apktool should technically be able to do both the classes and resources parts of things (since it incorporates baksmali and smali), but for some reason it bails in recovery on decompiling the classes.dex where baksmali standalone doesn't. So perhaps in future revisions apktool could be the only jar required.
Similarly, apktool also bails when rebuilding resources.asrc because it can't call its internal(?) aapt, so I've included aapt compiled as PIE since that's the only working one I could find; in the future this could go too if apktool resolves it, or at the very least it would be more universal if we had a static compile of aapt to go with the other static binaries included.
Other possible items on the to-do list would include adding zip re-signing (currently it uses the apktool /system APK trick of keeping META-INF the same), reflashing to revert to the backup APKs, and adding busybox to always have an expected execution environment like I recently did on AnyKernel2 to work around Cyanogen Recovery and toybox missing basic stuff like awk at the moment. These aren't something I'm going to be actively working on since it works and APK modding isn't really a focus for me, but since I figured out how to automate the process I wanted to provide the WIP template for the modding community. :good:
osm0sis said:
Nah, just forced bak/smali and apktool to run by building/adding classes.dex for each of them and figuring out how to call a functional dalvikvm from recovery.
The first part was mentioned in passing (and quite awesomely) by JesusFreke back in 2011:
http://forum.xda-developers.com/showpost.php?p=10424700&postcount=2
That got it running in booted Android. Then running from recovery was a whole other issue, but I stumbled upon Jim Huang's work on executing dalvikvm on Linux, and that lead me to figuring out a solution.
As it stands, apktool should technically be able to do both the classes and resources parts of things (since it incorporates baksmali and smali), but for some reason it bails in recovery on decompiling the classes.dex where baksmali standalone doesn't. So perhaps in future revisions apktool could be the only jar required.
Similarly, apktool bails when rebuilding resources.asrc because it can't call its internal(?) aapt, so I've included aapt compiled as PIE since that's the only working one I could find; in the future this could go too if apktool resolves it or at the very least it would be more universal if we had a static compile of aapt to go with the other static binaries included.
Other possible items on the to-do list would include adding zip re-signing (currently it uses the apktool /system APK trick of keeping META-INF the same), and adding busybox to always have an expected execution environment like I recently did on AnyKernel2 to work around Cyanogen Recovery and toybox missing basic stuff like awk. These aren't something I'm going to be actively working on since it works and APK modding isn't really a focus for me, but since I figured out how to automate the process I wanted to provide the WIP template for the modding community. :good:
Click to expand...
Click to collapse
Nice! I tried to compile aapt from my device a few mins ago just for s&g's got pretty far actually before it couldn't compile some external android libs because I didn't have them downloaded.
Have you ever seen the Android apktool apk by pqy330? It's not on git anymore for some reason, but the guy figured out how to get java, javac, aapt, aidl, and everything working on arm, only required a LD_LIBRARY_PATH export. I wish I could get a hold of the guy to ask him about getting some of those tougher arm static binaries compiled.
And yeah I wouldn't actively spend hours working on this if it's already in a working state like you said, it's just interesting compared to the other mundane things I read of xda lol. Especially new developments. Great job man.
APK-Patcher: minor fixes, binary updates:
- allow for recoveries without busybox
- update tool compiles to my newer zipalign and static(!) aapt builds
- strip zip binary to compensate for larger aapt and zipalign binaries
- simplify aapt usage now that we have a static arm binary
- configure zipalign for Marshmallow system APK handling
https://github.com/osm0sis/APK-Patcher/commit/af24805f06e2e2b92f2bfeeb1490d6022073c4b5
Thanks @Surge1223 for the help with figuring out compiling zipalign and aapt statically for arm. :highfive:
Wow, i wish that i know this patcher before
so im trying to add two lines after line #24 in "res/xml/tuner_prefs.xml"
i tried
Code:
sed -i '24 i\> <Preference android:title="@string/nav_bar" android:key="nav_bar" android:fragment="com.android.systemui.tuner.NavBarTuner" />' res/xml/tuner_prefs.xml;
sed -i '25 i\> <Preference android:title="@string/color_and_appearance" android:key="color_transform" android:fragment="com.android.systemui.tuner.ColorAndAppearanceFragment" />' res/xml/tuner_prefs.xml;
and this also
Code:
sed -i '24 i\> <Preference android:title="@string/nav_bar" android:key="nav_bar" android:fragment="com.android.systemui.tuner.NavBarTuner" />' res/xml/tuner_prefs.xml;
sed -i '25 i\> <Preference android:title="@string/color_and_appearance" android:key="color_transform" android:fragment="com.android.systemui.tuner.ColorAndAppearanceFragment" />' res/xml/tuner_prefs.xml;
and it doesn't work, im really sorry i never used sed commands before
do i have to add original file in "patch/SystemUI/res/xml" and then the script should change it ?
AL_IRAQI said:
Wow, i wish that i know this patcher before
so im trying to add two lines after line #24 in "res/xml/tuner_prefs.xml"
i tried
Code:
sed -i '24 i\> <Preference android:title="@string/nav_bar" android:key="nav_bar" android:fragment="com.android.systemui.tuner.NavBarTuner" />' res/xml/tuner_prefs.xml;
sed -i '25 i\> <Preference android:title="@string/color_and_appearance" android:key="color_transform" android:fragment="com.android.systemui.tuner.ColorAndAppearanceFragment" />' res/xml/tuner_prefs.xml;
and this also
Code:
sed -i '24 i\> <Preference android:title="@string/nav_bar" android:key="nav_bar" android:fragment="com.android.systemui.tuner.NavBarTuner" />' res/xml/tuner_prefs.xml;
sed -i '25 i\> <Preference android:title="@string/color_and_appearance" android:key="color_transform" android:fragment="com.android.systemui.tuner.ColorAndAppearanceFragment" />' res/xml/tuner_prefs.xml;
and it doesn't work, im really sorry i never used sed commands before
do i have to add original file in "patch/SystemUI/res/xml" and then the script should change it ?
Click to expand...
Click to collapse
Nah, per the OP, the "patch" directory is only for replacing files whole, which you shouldn't do to keep it universal.
You just need a working sed command in the script directory.
You can borrow this script function from my AnyKernel2 to make the insertion easier for you as a sed beginner:
Code:
# insert_line <file> <if search string> <before|after> <line match string> <inserted line>
insert_line() {
if [ -z "$(grep "$2" $1)" ]; then
case $3 in
before) offset=0;;
after) offset=1;;
esac;
line=$((`grep -n "$4" $1 | head -n1 | cut -d: -f1` + offset));
sed -i "${line}s;^;${5}\n;" $1;
fi;
}
Then follow that with an insert_line command using the syntax provided. "if search string" tests whether the mod has been completed already, then "line match string" is the line you want to put the inserted lines before/after.
You can insert both lines at once with a \n between as well.
osm0sis said:
Nah, per the OP, the "patch" directory is only for replacing files whole, which you shouldn't do to keep it universal.
You just need a working sed command in the script directory.
You can borrow this script function from my AnyKernel2 to make the insertion easier for you as a sed beginner:
Code:
# insert_line <file> <if search string> <before|after> <line match string> <inserted line>
insert_line() {
if [ -z "$(grep "$2" $1)" ]; then
case $3 in
before) offset=0;;
after) offset=1;;
esac;
line=$((`grep -n "$4" $1 | head -n1 | cut -d: -f1` + offset));
sed -i "${line}s;^;${5}\n;" $1;
fi;
}
Then follow that with an insert_line command using the syntax provided. "if search string" tests whether the mod has been completed already, then "line match string" is the line you want to put the inserted lines before/after.
You can insert both lines at once with a \n between as well.
Click to expand...
Click to collapse
im such a noob, even this basic code is hard for me to understand :crying:
do i have to keep grep commands ?, because i dont need to replace or find something in the file, only inserting after line #24
$1 is the file here right ?, and your trying to find $2 and add someting, and in case of 3$ there is another case, and edits will probably be before/after $4 ?
AL_IRAQI said:
im such a noob, even this basic code is hard for me to understand :crying:
do i have to keep grep commands ?, because i dont need to replace or find something in the file, only inserting after line #24
$1 is the file here right ?, and your trying to find $2 and add someting, and in case of 3$ there is another case, and edits will probably be before/after $4 ?
Click to expand...
Click to collapse
What is on line 24? Wouldn't it be more universal to match against some part of the contents of the current line 24 to ensure its always in the right place, even if the number changes?
The $1 $2 $3 $4 $5 correspond to each argument supplied as per the <syntax> in the #commented line.
osm0sis said:
What is on line 24? Wouldn't it be more universal to match against some part of the contents of the current line 24 to ensure its always in the right place, even if the number changes?
The $1 $2 $3 $4 $5 correspond to each argument supplied as per the <syntax> in the #commented line.
Click to expand...
Click to collapse
i modded systemui for N5X,N6/6P,N9 and android one device, all of them has the same layout
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
or i can search for "<Preference android:title="@string/other"" and add it before it
oh, now its easier to understand ;P
Okay, so.. Probably:
Code:
insert_line res/xml/tuner_prefs.xml "com.android.systemui.tuner.NavBarTuner" before "com.android.systemui.tuner.OtherPrefs" "<Preference android:title=\"@string/nav_bar\" android:key=\"nav_bar\" android:fragment=\"com.android.systemui.tuner.NavBarTuner\" />\n<Preference android:title=\"@string/color_and_appearance\" android:key=\"color_transform\" android:fragment=\"com.android.systemui.tuner.ColorAndAppearanceFragment\" />";
osm0sis said:
Okay, so.. Probably:
Code:
insert_line res/xml/tuner_prefs.xml "com.android.systemui.tuner.NavBarTuner" before "com.android.systemui.tuner.OtherPrefs" "<Preference android:title=\"@string/nav_bar\" android:key=\"nav_bar\" android:fragment=\"com.android.systemui.tuner.NavBarTuner\" />\n<Preference android:title=\"@string/color_and_appearance\" android:key=\"color_transform\" android:fragment=\"com.android.systemui.tuner.ColorAndAppearanceFragment\" />";
Click to expand...
Click to collapse
i removed /patch and added the script to SystemUI-res.sh, but it doesn't seems to work
screenshot:
AL_IRAQI said:
i removed /patch and added the script to SystemUI-res.sh, but it doesn't seems to work
screenshot:
Click to expand...
Click to collapse
You shouldn't see that message for what you're doing unless you've got things set up weird. Can you just attach your WIP zip and I'll take a look?
osm0sis said:
You shouldn't see that message for what you're doing unless you've got things set up weird. Can you just attach your WIP zip and I'll take a look?
Click to expand...
Click to collapse
here you are, link
Thanks
osm0sis said:
You shouldn't see that message for what you're doing unless you've got things set up weird. Can you just attach your WIP zip and I'll take a look?
Click to expand...
Click to collapse
AL_IRAQI said:
here you are, link
Thanks
Click to expand...
Click to collapse
Okay, try this. I've got you about 90% of the way there; fixed all the weirdness with the unnecessary patch folder, extra files and extracmd. The sed insertion is still untested, so you'll have to check that out, and from what you and others have told me you'll need to update the included tools for Nougat support.
Download the newer bak/smali and apktool, then that's done with
Code:
dx --dex --output=classes.dex <file>.jar
from within the latest SDK. Add the classes.dex to the jar (it's a zip). Name them like the current ones (version numbers, etc.) and put them in tools and remove the old ones. :good:
[ Attachment removed. ]
osm0sis said:
Okay, try this. I've got you about 90% of the way there; fixed all the weirdness with the unnecessary patch folder, extra files and extracmd. The sed insertion is still untested, so you'll have to check that out, and from what you've told me you'll need to update the included tools for Nougat support.
Download the newer bak/smali and apktool, then that's done with
Code:
dx --dex --output=classes.dex <file>.jar
from within the latest NDK. Add the classes.dex to the jar (it's a zip). Name them like the current ones (version numbers, etc.) and put them in tools and remove the old ones. :good:
Click to expand...
Click to collapse
Awesome, ill try it today :fingers-crossed:
Edit:
i already downloaded newer tools, and now i have to run this code ?
Code:
dx --dex --output=classes.dex apktool_2.0.3.jar
dx --dex --output=classes.dex baksmali-2.1.1.jar
dx --dex --output=classes.dex smali-2.1.1.jar
AL_IRAQI said:
Awesome, ill try it today :fingers-crossed:
Edit:
i already downloaded newer tools, and now i have to run this code ?
Code:
dx --dex --output=classes.dex apktool_2.0.3.jar
dx --dex --output=classes.dex baksmali-2.1.1.jar
dx --dex --output=classes.dex smali-2.1.1.jar
Click to expand...
Click to collapse
@AL_IRAQI, sorry, just saw your edit. The latest bak/smali is 2.1.3, and latest apktool is 2.2.0, but otherwise yes, you run that command on each jar separately from the build-tools directory of the latest Android SDK, and put the resulting classes.dex inside the jar (which is a zip file). Then it's able to be run on Android as in my zip.
New commit!
tools: binary updates:
https://github.com/osm0sis/APK-Patcher/commit/e4f6e3e90e13c862652183460a86e49cb0514fd9
Since I felt bad @AL_IRAQI didn't appear to be able to figure it out for his mods. :angel:
From an incorrect thread:
aj20010319 said:
Can I combine APK Patcher with aroma? Like use the standard updater-binary and adding all these functions from updater-binary into a different shell script and executing it later?
Click to expand...
Click to collapse
aj20010319 said:
Okay so I somehow managed to get aroma and apk patcher together, made separate zips and then made one zip flash the other.
I am trying to decompile framework-res.apk, but it's failing, logs show this error,
Code:
framework-res.apk
I: Using Apktool 2.2.0 on framework-res.apk
I: Loading resource table...
I: Decoding AndroidManifest.xml with resources...
I: Regular manifest package...
I: Decoding file-resources...
java.lang.NoClassDefFoundError: Failed resolution of: Ljavax/imageio/ImageIO;
at brut.androlib.res.decoder.Res9patchStreamDecoder.decode(Res9patchStreamDecoder.java:39)
at brut.androlib.res.decoder.ResStreamDecoderContainer.decode(ResStreamDecoderContainer.java:33)
at brut.androlib.res.decoder.ResFileDecoder.decode(ResFileDecoder.java:120)
at brut.androlib.res.decoder.ResFileDecoder.decode(ResFileDecoder.java:87)
at brut.androlib.res.AndrolibResources.decode(AndrolibResources.java:262)
at brut.androlib.Androlib.decodeResourcesFull(Androlib.java:131)
at brut.androlib.ApkDecoder.decode(ApkDecoder.java:108)
at brut.apktool.Main.cmdDecode(Main.java:163)
at brut.apktool.Main.main(Main.java:81)
Caused by: java.lang.ClassNotFoundException: Didn't find class "javax.imageio.ImageIO" on path: DexPathList[[zip file "/tmp/apkpatcher/tools/apktool_2.2.0-dexed.jar"],nativeLibraryDirectories=[/system/lib]]
at dalvik.system.BaseDexClassLoader.findClass(BaseDexClassLoader.java)
at java.lang.ClassLoader.loadClass(ClassLoader.java)
at java.lang.ClassLoader.loadClass(ClassLoader.java)
... 9 more
Suppressed: java.lang.ClassNotFoundException: javax.imageio.ImageIO
at java.lang.Class.classForName(Native Method)
at java.lang.BootClassLoader.findClass(ClassLoader.java)
at java.lang.BootClassLoader.loadClass(ClassLoader.java)
... 11 more
Caused by: java.lang.NoClassDefFoundError: Class not found using the boot class loader; no stack trace available
Decoding APK resources failed. Aborting...
Click to expand...
Click to collapse
Seems like you're in the wrong thread? I'm not sure. You can try reverting to the previous builds of tools, but beyond that I'm not sure at the moment. It's on my to-do to test everything out again in the near future and resolve any issues I can come up with. Please reply in the APK-Patcher thread.