So i have written a simple script to ease the process of editing apks. Got a lot of downloads so thought its in demand
Whether you're doing basic image editing or editing the smali or xml files, on average u have to use (Brut.all or JF's smali/baksmali) awesome tool to extract the apk, edit it, then sign the apk and then adb push/install it. This process is quite tiresome if you are testing a method that needs fine tweaking.
This script should make the process a LOT smoother.
Theres an option of compiling/signing/installing all in one step
Thanks:
Goes to Brut.all for his awesome tool.
Goes to JF for ofcourse, smali/baksmali
Goes to farmatito for porting this script to linux
Features:
- Extract, Zip apk's.
- Optimize pngs (ignores .9.pngs)
- Zipalign apks
- Sign apks
- Push to specific location on phone
- Incorporates brut.all's apktool
- Pull apk from phone into modding environment.
- Batch optimize apk (Zipalign,optipng,or both)
- Quick sign an apk (Batch mode supported)
- Batch Ogg optimization
- Compression level selector (monitor status above menu)
- Batch install apk from script (option 16)
- Logging on/off has been removed. Instead a log.txt is created which logs the activities of the script organized using time/date headers
- User can change the max java heap size (only use if certain large apks get stuck when decompiling/compiling apks) (Option 19)
- Improved syntax of questions/answers
- Error detection. Checks if error occured anytime u perform a task, and reports it
- Read log (Option 20)
- U can now set this script as ur default application for apks. When u do, if u double click any apk it will install it for u.
- Supports batch installation, so if u drag multiple apks into the script (not while its running) it will install them all for u. U can ofcourse drag a single apk as well
- Added framework dependent decompiling (For non propietary rom apks). (Option 10). Checks whether the dependee apk u selected is correct.
- Allows multiple projects to be modified, switch to and from.
- Allows to modify system apk's using apktool but ensures maximum compatibility in terms of signature / manifest.xml
- Stuff i forgot i guess
Instructions (Windows):
- Place apk in appropriate folder (Any filename will work, if running for first time folders will not be there, you must run and then the folders will be created)
- Run script
- Minimize the script
- Edit files inside the project folder
- Maximize the script
Instructions (Linux):
- Place apk in appropriate folder (Any filename will work, if running for first time folders will not be there, you must run and then the folders will be created)
- Open terminal and change-directory to apkmanager (Easiest way is to type "cd ")
- Chmod 755 Script.sh
- Chmod 755 all files apps inside other folder (thanks for the tip bkmo )
- Run script by typing ./Script.sh
- Minimize the script
- Edit files inside the out folder
- Maximize the script
Requirements:
Java
Adb
Future Improvements:
- Manage multiple simultaneous apk edits (choose which apk to extract/build)
- Option to optimize the apks
- Option to adb push to user defined location
- Other stuff i dont know yet
Got problems ?
1. Make sure your path has no spaces
2. Your filename has no wierd characters
3. Java/adb are in your path
4. It's not a proprietary rom's apk (aka Sense,Motorola,Samsung) (If u are, then use option 11 and drag the required framework, eg com.htc.resources, twframework-res...etc)
5. It's not a themed apk (if it is, expect .9 png errors, use as close to stock as possible)
6. Look at the log to know whats happening
7. If all else fails, post as much info as possible and we will try to assist you.
MOD EDIT:
New DL link from this post
http://apkmultitool.com
Nice
As you probably know, I want to add signing and installing functionality to apktool. But I don't plan to make any kind of GUI for it, so such wrapper is a very good thing for many users, thanks
What is "Option to optimize the apks"?
I was thinking of incorporating the script "apkopt" it was basically using optipng to optimize the png's and then used zip align on the apks. Thanks btw, this tool wudnt exist without ur awesome script
I just did this so ppl would stop asking questions like "How do i change this/that in an app"
Here this is wht im talking about Link
Very nice
Thanks dude...
once again you manage to make modding easier with your scripts!
Does your apkopt avoid .9.png files? Because those have been a pain in the behind.
Re: Apk Manager 1.0 - Makes Modifying Ur Apk A Breeze
my script currently does not optimize apks. it will be in the upcoming updates and yea prolly when ill implement itll avoid .9.pngs lol
I have already incorporated "adb push" into the script.
Aside from adding an option to optimize the apks, is there anything else you guys think would make this script easier to use ?
Im really targetting those ppl who overcomplicate the simple process of editing apks. Any tips would be appreciated.
I posted a video attached to the main post.
New version out, features added are
Zipalign apks
Optimize pngs, ignores .9.pngs
allows to adb push to phone through script.
Great script man, it works flawlessly. You may just wanna edit your post #1 rather than continuously bumping with new posts for every update. I'm sure a mod won't be too pleased with that
I'm getting the
'java' is not recognized as an internal or external command, operable program or batch filemessage when I attempt to sign an apk. I tried switching the PATH in Environment Variables so that it's pointing to my Java bin folder, but then I just end up with
java.io.FileNotFoundException: ..\place-apk-here\repackaged-unsigned.apk <The system cannot find the file specified>
at java.util.zip.ZipFile.open<Native Method>
at java.util.zip.ZipFile.<init><Unknown Source>
at java.util.zip.ZipFile.<init><Unknown Source>
at java.util.zip.ZipFile.<init><Unknown Source>
at com.android.signapk.SignApk.main<SignApk.java:320>
Could Not Find C:\ApkManager2.0\place-apk-here\../place-apk-here/repackaged-unsigned.apkHelp? :]
What app are you trying to edit ? also are you editing pngs only or code editing ?
Hop on Here im helping someone out so ill help u 2
There's a lot of things in /system that benefit from the optimized .pngs. Vending.apk, for instance, shrunk to half the size and runs a bit quicker and smoother now. Even framework-res.apk enjoyed the optimization. Paid apps, on the other hand, don't seem to fare so well; perhaps they check the md5sum of the app or something.
Yea png optimization works for almost all apks, zipalign on the other hand as i recall doesnt work on certain system apks such as settings.apk. Im prolly gonna incorporate apkopt's script into this which would allow to optimize a folder full of apks. As for paid apps not being optimized, a lot of dev already do their part on making the apk as small as possible, so perhaps thats the case.
hmm, after trying a couple of unpaid apps, it seems that perhaps the testkeys aren't compatible with my build. For any signed app, I get an error "Failure [INSTALL_FAILED_UPDATE_INCOMPATIBLE]"
Yes when u modify a non system apk, they need to be resigned, and you cannot resign it with same key as dev cuz u dont know it hence anytime u modify an app, u must uninstall it, install the modded version, and from then on any change u make u dont have to uninstall as the keys will match
ahhh thanks. My mistake was just removing the package rather than uninstalling it.
Getting this on a zipalign. The file is there but it is repackaged-unsigned.apk and throws this error:
Please make your decision: 5
Unable to open 'E:\ApkManager\place-apk-here\repackaged-signed.apk' as zip archi
ve
Could Not Find E:\ApkManager\place-apk-here\repackaged-signed.apk
The system cannot find the file specified.
Nevermind....looks like it is by design that it tries both signed and unsigned and throws the error on the file that does not exist. It's just I did not see any zipalign output
having an issue that when I go to resign an apk the file deletes after running the script.. am I missing something here?
Can i manually deodex the framework and apps by deleting each individual .odex file?
Smonic said:
Can i manually deodex the framework and apps by deleting each individual .odex file?
Click to expand...
Click to collapse
No, u need some soft to do so. Deodexing add the .odex content files into your compressed .apk (correct me if i'm wrong ^^)
Zipalign deodex files make them reading faster by your OS
All of your apps on your device are packaged as .apk files; these files are compiled from google source code and can interchangeably be viewed/thought of as a compressed folder (like a .zip or a .rar); and all of your framework components (well most…) are packaged as .jar files which literally stands for Java Archive (so again this can be compared to a .zip or a .rar).
When the android OS want’s to run your apps or utilize its framework components, it has to parse (read/interpret) the compressed data held within your .apk and/or.jar files. What the odex file structure aims to do, is to expedited this process by utilizing another file (.odex file) to compliment every.apk file (and .jar file); the odex file, includes the most critical data in an uncompressed format so the android os can quickly interpret that important information before parsing through the rest of the data held within the compressed .apk files (and .jar files). So subsequently, in an .odex file structure the .apk & .jar files don’t include all of the applications/framework-components data; Essentially, two files are acting as one; for your apps there are .apk files + their corresponding .odex file and for your framework components there are .jar files + their corresponding .odex file. This works nicely as an optimized file structure, except in the circumstance when the user want’s to theme; theming requires a modification to your .apks; the image files (.pngs) held within the pngs are replaced with different ones. However it is impossible to theme an application if it exists as two files. So that is why it is said you need to be DeOdexed in order to theme; DeOdexing is the process of re-bundling that uncompressed critical data (.odex files) back into your compressed .apk (& .jar) files, so that now all of the data is included in the .apk files necessary to run your applications without the presence of .odex files; in addition all the data is now included within the .jar files necessary to utilize your framework components without .odex files. In a DeOdexed file structure, there are no odex files present.
Click to expand...
Click to collapse
Source : http://www.wugfresh.com/guides/deodex/
I don't think so.... but if yes, then it'll be very hard!
When dealing with custom ROMs the terms ‘odexed’, ‘deodexed’ and ‘zipaligned’ are encountered quite often. In this tutorial we will explain what they mean and how they can affect your device.
In Short:
Odex files:
-Pre-optimized parts of application or library.
Deodexing:
- the process of combining .odex and .apk files in order to have the full code of the application in one place.
Zipalign:
- archive alignment tool used to optimize apk packages.
In Details:
Dex files:
Dalvik EXecutable (DEX) is a home-grown Android format used in Dalvik virtual machine. It does not use the same java bytecode instructions. Dalvik opcodes are designed to support the Java language, however compiling code to Dalvik bytecode written in other languages is possible. Android comes with a disassembler called dexdump.
Jar files:
Java ARchive (JAR) is an archive file format used to aggregate many Java class files and associated metadata and other resources (text, images, settings etc) into one file to distribute application software or libraries on the Java platform. In Android the difference is that JAR files instead of Java class files contain classes.dex file which contains the Dalvik bytecode. In Android you wil find those mostly in /system/framework.
Apk files:
Application package file(APK) is the file format used to distribute and install applications onto Google’s Android operating system. Apk files are ZIP file formatted packages based on the JAR file format, with .apk file extensions. An APK file normally contains
META-INF folder – contains manifest file, certificate and signature
res folder – not compiled resources
assets folder – more raw resources
resources.arsc – pre-compiled resources
AndroidManifest.xml – Android specific manifest file in binary xml
classes.dex – the java classes compiled in a DEX file.
Note that in Odexed ROMs classes.dex can be missing in APK and JAR files.
BOOTCLASSPATH:
BOOTCLASSPATH is a list of the jars/apk from which classes can be loaded, in addition to the main apk/jar that is loaded. Normally Android has 5 JAR files in it’s base BOOTCLASSPATH – core.jar, ext.jar, framework.jar, android.policy.jar and services.jar. However, some APK files have more dependencies on additional jar or apks files. Google maps for example needs com.google.android.maps.jar. To check your BOOTCLASSPATH you can type: ‘adb shell set’;
Odex files:
Odex file is actually the extracted and optimized DEX file(classes.dex) from APK or JAR files. An ODEX file has dependencies on every file in the BOOTCLASSPATH that is loaded when it is generated. The odex file is only valid when used with these exact BOOTCLASSPATH files. dalvik enforces this by storing a checksum of each file that the odex file is dependent on, and ensuring that the checksum for each file matches when the odex file is loaded.
Deodexing:
- the process of reassembling ODEX files in DEX(classes.dex) and place them pack in the respective APK and JAR files.
Android Applications Startup Process :
When an application is started on first use if no ODEX file is found, classes.dex is optimized by the package manager(PM) and saved in /data/dalvik-cache.
Odexed ROMs
In these ROMs you will have ODEX files for most APK and JAR files in /system/framework and /system/app and also the classes.dex in APK and JAR files will be missing.
pros::laugh::laugh::laugh:
Speed up loading as odex is uncompressed and already optimized
saves space as no need to put optimized dex in dalvik-cache (already have the ODEX file in /system/framework or /system/app)
Hard to hack/decompile as data is separated
cons::crying::crying::crying::crying:
cannot do modifications to apks or jars
cannot do theming
cannot change BOOTCLASSPATH if system libraries are affected
DeOdexed ROMs:
In these ROMs you will have classes.dex file in all APK and JAR files.
Pros::laugh:
can do modifications to apks
can do theming
can change/add/remove libraries and thus recompile all the current apks with the new implementation
Cons::crying:
slower loading but just the one time when a modification is done or dalvik-cache cleaned(wiped).
need to put optimized dex in dalvik-cache
easer to decompile an app
Zipalign:
- archive alignment tool used to optimize apk packages. Basically the data in the APK package is being read by many process (app itself , installer, home app, system server, etc.). If every process knows where to look for its data it wont need to unpack the whole APK. Zipaligned APKs are done in such a way so all uncompressed data starts with a particular alignment(on 4 byte boundaries) relative to the start of the file.
THANK ME IF THIS INFO HELPED YOU
.......:laugh::laugh:
Helpful thanks!
Sent from my Desire HD using xda app-developers app
finally i understand , but is there a little more explanation for zipalign just to make sure wt i understood is right
It is good to mention at least the source ESPECIALLY when you copy/paste
http://andwise.net/?p=419
thank you!
cyanidekiller said:
When dealing with custom ROMs the terms ‘odexed’, ‘deodexed’ and ‘zipaligned’ are encountered quite often. In this tutorial we will explain what they mean and how they can affect your device.
In Short:
Odex files:
-Pre-optimized parts of application or library.
Deodexing:
- the process of combining .odex and .apk files in order to have the full code of the application in one place.
Zipalign:
- archive alignment tool used to optimize apk packages.
In Details:
Dex files:
Dalvik EXecutable (DEX) is a home-grown Android format used in Dalvik virtual machine. It does not use the same java bytecode instructions. Dalvik opcodes are designed to support the Java language, however compiling code to Dalvik bytecode written in other languages is possible. Android comes with a disassembler called dexdump.
Jar files:
Java ARchive (JAR) is an archive file format used to aggregate many Java class files and associated metadata and other resources (text, images, settings etc) into one file to distribute application software or libraries on the Java platform. In Android the difference is that JAR files instead of Java class files contain classes.dex file which contains the Dalvik bytecode. In Android you wil find those mostly in /system/framework.
Apk files:
Application package file(APK) is the file format used to distribute and install applications onto Google’s Android operating system. Apk files are ZIP file formatted packages based on the JAR file format, with .apk file extensions. An APK file normally contains
META-INF folder – contains manifest file, certificate and signature
res folder – not compiled resources
assets folder – more raw resources
resources.arsc – pre-compiled resources
AndroidManifest.xml – Android specific manifest file in binary xml
classes.dex – the java classes compiled in a DEX file.
Note that in Odexed ROMs classes.dex can be missing in APK and JAR files.
BOOTCLASSPATH:
BOOTCLASSPATH is a list of the jars/apk from which classes can be loaded, in addition to the main apk/jar that is loaded. Normally Android has 5 JAR files in it’s base BOOTCLASSPATH – core.jar, ext.jar, framework.jar, android.policy.jar and services.jar. However, some APK files have more dependencies on additional jar or apks files. Google maps for example needs com.google.android.maps.jar. To check your BOOTCLASSPATH you can type: ‘adb shell set’;
Odex files:
Odex file is actually the extracted and optimized DEX file(classes.dex) from APK or JAR files. An ODEX file has dependencies on every file in the BOOTCLASSPATH that is loaded when it is generated. The odex file is only valid when used with these exact BOOTCLASSPATH files. dalvik enforces this by storing a checksum of each file that the odex file is dependent on, and ensuring that the checksum for each file matches when the odex file is loaded.
Deodexing:
- the process of reassembling ODEX files in DEX(classes.dex) and place them pack in the respective APK and JAR files.
Android Applications Startup Process :
When an application is started on first use if no ODEX file is found, classes.dex is optimized by the package manager(PM) and saved in /data/dalvik-cache.
Odexed ROMs
In these ROMs you will have ODEX files for most APK and JAR files in /system/framework and /system/app and also the classes.dex in APK and JAR files will be missing.
pros::laugh::laugh::laugh:
Speed up loading as odex is uncompressed and already optimized
saves space as no need to put optimized dex in dalvik-cache (already have the ODEX file in /system/framework or /system/app)
Hard to hack/decompile as data is separated
cons::crying::crying::crying::crying:
cannot do modifications to apks or jars
cannot do theming
cannot change BOOTCLASSPATH if system libraries are affected
DeOdexed ROMs:
In these ROMs you will have classes.dex file in all APK and JAR files.
Pros::laugh:
can do modifications to apks
can do theming
can change/add/remove libraries and thus recompile all the current apks with the new implementation
Cons::crying:
slower loading but just the one time when a modification is done or dalvik-cache cleaned(wiped).
need to put optimized dex in dalvik-cache
easer to decompile an app
Zipalign:
- archive alignment tool used to optimize apk packages. Basically the data in the APK package is being read by many process (app itself , installer, home app, system server, etc.). If every process knows where to look for its data it wont need to unpack the whole APK. Zipaligned APKs are done in such a way so all uncompressed data starts with a particular alignment(on 4 byte boundaries) relative to the start of the file.
THANK ME IF THIS INFO HELPED YOU
.......:laugh::laugh:
Click to expand...
Click to collapse
andwise said:
It is good to mention at least the source ESPECIALLY when you copy/paste
http://andwise.net/?p=419
Click to expand...
Click to collapse
andwise said:
It is good to mention at least the source ESPECIALLY when you copy/paste
http://andwise.net/?p=419
thank you!
Click to expand...
Click to collapse
Well its almost ten years since I posted this. I do not know exactly about my thought process back then and why I posted this, but I am sorry for not mentioning the original source.
Guide - How To Setup Apktool(CP)
• For Phone
Requirments:
Apktool(any version)
Root Explorer.apk
Commonsense
Logic
Instructions:
- Extract apktool.zip and install apktool.apk(For Version 4.4 and below but for 5.0 and above then just install the app)
- Open root explorer and create a FOLDER in your sd card and name it as "apktool"
- inside apktool folder create another FOLDER and name it as "framework"
- After that, Go to system > framework and copy FRAMEWORK-RES.apk and MEDIATEK-RES.apk
- Paste it inside the framework FOLDER you create before
- Open Apktool and go to > apktool folder > framework folder
- Tap FRAMEWORK-RES.apk and import it as FRAMEWORK
- After that, Tap MEDIATEK-RES.apk and import it also as FRAMEWORK
- Now you are ready to mod
• FAQ's
Why create FRAMEWORK folder?
- Because some SYSTEM apps like in PussyFap Rom needs there own FRAMEWORK-RES and MEDIATEK-RES in order to decompile there app
so just replace FRAMEWORK-RES and MEDIATEK-RES of that rom inside the framework folder and decompile the app
- Also you need to remove FRAMEWORK-RES and MEDIATEK-RES when you are decompiling a third party app
Why need to import FRAMEWORK-RES and MEDIATEK-RES?
- Because the resources of there system apps comes from that two apps
What is the difference between Decompile Resources, Decompile Dex, and Decompile all?
- Decompile Resources only decompile resources(res)
- Decompile Dex only decompile dex(smalis)
- Decompile all both decompile dex and resources
Note:
If you have questions just message us
#WeAreTeamPussy
Hi .. i'm new of this forum ...(i'm not a java programmer, but i programmed with other languages)
Env : Windows 7 - Apk editor studio 1.4.0 - apktool 2.5.0
Usually i'm doing this simple steps ..
1) Open the package with apk editor studio
2) Opens the lib directory and delete what do not belongs to my android amreabi-v7
3) Save the apk : Apk editor calls apktool to rebuild, the optimize zip ,and sign ...
This works with all packages except with two very huge apk packages ....
When i rebuid i get errors, each apk issue a different error, so I' immagined programmers inserted a trap or somethig like to forbid reverse engeenering
I do not want to hack, but only to reduce storage usage....
is there a way to "unzip - delete libs - zip to apk - sign" without using apktool ?
Thanks in advance for the support