Related
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?
I made a tutorial for other devices here http://forum.xda-developers.com/showthread.php?t=1500475
Why this tutorial?
I wanted a good odexed rom, but there isn't any here. So I tried to make my own odexed rom, but it wasn't so good. So I read something about re-odexing and tried it out. I modified it a little bit and I don't know all about re-odexing, so if someone know something better, pls post it here in the thread for everyone. Im working also on this thread, so I'll try to make few things like a flashable update.zip who executes the script. English is also not my mother language, but I hope you'll understand me
What is a odexed and a deodexed rom?
When you look at a stock rom in the folder /system/app, you will see files with the ending .odex and the apks doesn't contains classes.dex files. When you look at a deodexed rom, you'll see that there are no .odex files and the apks contains classes.dex files. Basically every apk contains a classes.dex files. Then the dalvik virtual machine generates a dalvik cache based of the classes.dex file. When you load a app, it will be loaded from the the dalvik cache, not from the apk. Samsung built the odexed rom using a tool called dexopt-wrapper. This tool generates .odex files based from the classes.dex, that means it does the same job like the dalvik vm. The .odex files were pushed in the /system. The files are the replacement for the dalvik cache. Like I wrote above, apps are loading from the dalvik cache, not from apk or classes.dex file, so classes.dex are not needed anymore, so they are deleted in odexed roms. Deodexing using xUltimate means regenerating a classes.dex based from the .odex file, merging it into the apk and deleting .odex.
What are the advantages and disadvantages from a deodexed rom?
Advantages:
-All needed things are in one apk, so modding/theming is (better) possible
-Needs less space on /system
Disavantages:
-Needs more space on /data, you have on some roms only 110/170 mb free(because a deodexed rom needs a dalvik cache for system apps and frameworks
-Is not so stable than a odexed rom(because some moves dalvik cache to a low end sdext)
-Slower on first boot(because a odexed rom has already execute ready .odex files, a deodexed rom needs to generate dalvik cache)
Why should I re-odex?
I wanted this, because I use ~100 apps and I have a slow sd card, so moving /data/app and /data/dalvik cache to sdext made my system unstables, which was needed to run ~100 apps on a deodexed rom. But when I tried it on a odexed rom, I had only to move /data/app to sdext. So I used long time Stock rooted JPU. But the system was not so fast than on any other custom rom and I hated the stock theme. So If you want more space on /data and you don't want to try out new themes, you should probably try re-odexing.
What do I need to re-odex?
-A full NANDroid Backup
-More than 30 mb free space on /system
-ADB drivers for Option 1
-Titanium Backup Pro for Option 2
How can I re-odex a Rom?
There are 2 Options to do it, but only the first does a full re-odex.
Before doing anything make sure that you have a full NANDroid Backup because you'll propably get into a bootloop.
Option 1 using dexopt-wrapper:
I used first the script from puppet13th, but I got into a bootloop. So I corrected the $BOOTCLASSPATH and corrected permissions, but I got also into a bootloop. I compared the re-odexed Kyrillos Rom v9.3 framework with the framework from JPU. The difference was that Kyrillos Rom v9.3 Framework files android.policy.jar and services.jar doesnt contained the Meta-Inf.
Step 1: Check jars
Pull all your framework .jars using this adb command to your computer
Code:
adb pull /system/framework
and open them in WinRar or sth and check that they contains the Meta-Inf folder. If some file doesnt contain a Meta-Inf folder, I attached all jars from Stock JPU, so you can add the Meta-Inf folder from them. When you are done with adding Meta-Inf Folder to one file, you can push it to the system using this adb command(services.jar is only for example, use your filename):
Code:
adb push services.jar /system/framework
Some users told me that you can re-odex the rom without being in CWM, so you can may skip Step 2, but you could get into a bootloop without Step 2, but you can try it out, there is no risk with a NANDroid backup
Step 2(optional): Reboot your phone into cwm recovery and get adb access there
I never got adb access in windows, but i got always access with linux. If you also don't get access on Linux, you should try to reboot your phone and to select then recovery in the extended power menu, this gaves me always adb access.
Step 3: run reodex script
I attached a script, which push a script and needed binaries over adb to the phone. Then it executes the pushed script, which creates odex files and removes classes.dex from apks or jars and rezipaligns apks and deletes the dalvik cache.
For windows users: double click on odex.cmd
For linux users: open a terminal and navigate to the folder which contains the unzipped attachment and run
Code:
chmod +x reodex.sh
./reodex.sh
After its finished, simply reboot and enjoy your fully re-odexed rom.
Step 4 (optional) convert /data:
I dont know if there is a better option, but after a re-odex with Option 1, my phone didnt showed the right free space on /data. So I converted /data to a other filesystem and back and then it showed the right free space.
Option 2 using Titanium Backup Pro:
You need to have Titanium Backup pro for re-odexing.
Step 1:
Select Menu -> More -> integrate sys dalvik into rom and wait until its finished. Then you should have more space on /data. I had when I tried it before 105 and after 135 mb free space on /data and 0kb free space after it on /system, so its not all.
You can also undo it. Its good when you want to try out a new theme, so you can undo and redo it using TB Pro.
Simply select Menu -> More -> Undo sys dalvik integration
and you're done.
Option 1 vs. Option 2
-Option 1 does a full re-odex, you have full free space on /data(Option 2 does only re-odex the apps, not the framework)
-Option 1 deletes classes.dex from apks and jars(against Option 2), so you have more space free on /system
-You can undo Option 2 fast, so theming/modding is also possible by undo, theme and redo it(against Option 1)
For other Phones:
If someone has a other phone, theres a chance for getting re-odex working, but I think that you should not hope that it works. You can try to put in the right $BOOTCLASSPATH. You can find the valid $BOOTCLASSPATH in /init.rc. Then replace the following characters with the $BOOTCLASSPATH in the script in the folder odex(beginning from Line 8):
Code:
BOOTCLASSPATH=replace_this_with_your_bootclasspath
cd /system/framework
for filename replace_this_with_your_bootclasspath
In the line
Code:
for filename replace_this_with_your_bootclasspath
you must replace the ":" character between framework files with a space.
For theme developers:
I dont know if it works that you use the re-odexed theme on a stock odexed theme. If it is so, you dont have to re-odex and deodex your phone, you can simply push the dexopt-wrapper binary to a folder, chmod 755 it and use it to make odex files from the needed apks and jars(all apks inside /system/framework has no odex files, so dont odex them) like this:
Code:
dexopt-wrapper /system/app/Phone.apk /mnt/sdcard/Phone.odex /system/framework/core.jar:/system/framework/ext.jar:/system/framework/framework.jar:/system/framework/android.policy.jar:/system/framework/services.jar
You can change argument 1-2, but not argument 3(its the BOOTCLASSPATH)Then you could copy all needed main apks or jars to sdcard and remove classes.dex. Then only do Step 1 from Option 1 and you should have a theme for odexed rom.
Download Links
XDA gaves me only 500 Errors when uploading was done, so I uploaded it to min.us
Framework jars from JPU
Re-Odex Script for Windows
Re-Odex Script for Linux
Credits
puppet13th for making orginal script
If I helped you, dont be shy, just press the Thanks Button under this post.
www.kingsrom.com/f8-how-to-theme-guideslinkstutorials
Oh year I didnt see any tutorial before, but his is only for Froyo sense or Gingerbread aosp, so it wont work on galaxy 3 and I also wrote my tutorial so that noobs can understand it(I hope so).
I could also post a system.img of a re-odexed Kyrillos Rom v9.3 and other Roms, but I dont know if Im allowed to do that.
TearsDontFalls said:
Oh year I didnt see any tutorial before, but his is only for Froyo sense or Gingerbread aosp, so it wont work on galaxy 3 and I also wrote my tutorial so that noobs can understand it(I hope so).
I could also post a system.img of a re-odexed Kyrillos Rom v9.3 and other Roms, but I dont know if Im allowed to do that.
Click to expand...
Click to collapse
So the re-odexed kyrillos rom v9.3 is working faster than the original kyrillos rom v9.3??
Its not generally faster, but much faster for me because I have ~100 apps and when I run these apps on kyrillos v9.3 deodexed, i must move app and dalvik-cache to sdext which made my phone laggy. With a odexed kyrillos v9.3, i have much more space free on /data, so i only must move app to sdext which is much.
I wrote also the advantages and disadvantages from a deodexed and odexed rom in my tutorial.
TearsDontFalls said:
Its not generally faster, but much faster for me because I have ~100 apps and when I run these apps on kyrillos v9.3 deodexed, i must move app and dalvik-cache to sdext which made my phone laggy. With a odexed kyrillos v9.3, i have much more space free on /data, so i only must move app to sdext which is much.
I wrote also the advantages and disadvantages from a deodexed and odexed rom in my tutorial.
Click to expand...
Click to collapse
So, in a re-odexed rom the HD2SD is not working ?
You use again froyo data2SD ?
dante_100 said:
So, in a re-odexed rom the HD2SD is not working ?
You use again froyo data2SD ?
Click to expand...
Click to collapse
As far as I understand, it works but only for data/app.
correct me if I'm wrong
Sorry, my english is not the yellow from the egg(you must not understand this).
Im using on my re-odexed rom also Hybrid Data 2 SD, I can move also move /data/dalvik-cache and any other folder to sdext, its only not needed, because I had after the re-odexing much more free space on /data, so I did moved dalvik cache back to the NAND from the sdext, before re-odexing I moved dalvik cache to sdext, becaue it was needed for running ~100 apps.
short form:Only Theming is impossible with a re-odexed rom
Hope you'll understand this now.
Edit: Can someone help me for creating a update.zip for re-odexing. It must only copy the dir odex to /data/local/tmp/odex , chmod 755 them all and execute the shell script /data/local/tmp/odex/odex
Sooo
if i get ADB access using windows i can skip step 2 in option1 right?
chandradithya said:
Sooo
if i get ADB access using windows i can skip step 2 in option1 right?
Click to expand...
Click to collapse
No. You need to reboot in cwm and try to get adb access from there. Windows adb in recovery never worked for me, you need linux to get adb access from cwm mode
Sent from my i9003 powered by Poseidon's Rom + UC kernel
Right, I tried to make a update.zip which execute the script, but i had no success, it would be great if somebody can help me.
bscraze said:
No. You need to reboot in cwm and try to get adb access from there. Windows adb in recovery never worked for me, you need linux to get adb access from cwm mode
Sent from my i9003 powered by Poseidon's Rom + UC kernel
Click to expand...
Click to collapse
ADB actually works for me, just ran cmd.exe using admin privileges and i ran the odex script it worked, odexed ALL my system files, cleared my /data/dalvik-cache/
But like TearsDontFalls said it doesn't show the free memory correctly,
Im running g3mod and im yet to try the option4 that asks you to switch file systems
And the /g3mod.log says,
st17: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY
While the other partitions are all clean,
How did you got adb access in windows? Sure you was in cwm recovery while re-odexing?
Finally, someone post a guide on this. And it works! Though titanium backup never worked for me. And is it necessary to run the script on cmw? Cause I didn't done it on cmw.
Sent from my GT-I5800 using XDA App
I didn't expect that it works on a running system, but it can be so, so I'll update the guide after Christmas.
TearsDontFalls said:
How did you got adb access in windows? Sure you was in cwm recovery while re-odexing?
Click to expand...
Click to collapse
It worked perfectly for me,
I tried going to the G3 kernels recovery, ADB just wouldnt connect,
so i turned it on, Ran the script when it was in standby mode , then it gave an error at first,
Which i rectified by making the /system read or write using root explorer,
I think i ran the script using admin privileges.
Dont remember..
And g3mod.log showed me this
Code:
Checking mmcblk0p2
/dev/block/mmcblk0p2: clean, 11/125488 files, 15840/500173 blocks
Checking stl6
/dev/block/stl6: clean, 1302/13600 files, 46914/54400 blocks
Checking stl7
/dev/block/stl7 contains a file system with errors, check forced.
/dev/block/stl7: Inodes that were part of a corrupted orphan linked list found.
/dev/block/stl7: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p options)
Checking stl8
/dev/block/stl8: clean, 12/2176 files, 143/8704 blocks
Data2SD Disabled
Multi-OS Data Disabled
System detected: FROYO
System booted with Samsung Froyo kernel mode
Compcache disabled
No problems right now, But cant stop wondering why it says it is inconsistent.
I don't know why it is so, but it also doesn't show the right free space, so convert it to a other file system and then convert it back.
UNBELIEVABLE!
Finally, the first method worked for me.
Working great on HTC Amaze 4G
Thanks
heyjoe66 said:
UNBELIEVABLE!
Finally, the first method worked for me.
Working great on HTC Amaze 4G
Thanks
Click to expand...
Click to collapse
Thanks for your report. So it seems to be working on other devices, so I'll create a thread in android development.
Thanks works on sense 3.5, but I had to change Bootclasspath from the boot.img and add missing files below in odex script.
great guide
edit: now searching on how to re odex a single file.
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!
What is an ODEX file?
In Android file system, applications come in packages with the extension .apk. These application packages, or APKs contain certain .odex files whose supposed function is to save space. These ‘odex’ files are actually collections of parts of an application that are optimized before booting. Doing so speeds up the boot process, as it preloads part of an application. On the other hand, it also makes hacking those applications difficult because a part of the coding has already been extracted to another location before execution.
What is an DEODEX file?
Deodexing is basically repackaging of these APKs in a certain way, such that they are reassembled into classes.dex files. By doing that, all pieces of an application package are put together back in one place, thus eliminating the worry of a modified APK conflicting with some separate odexed parts.
So, Deodexed ROMs (or APKs) have all their application packages put back together in one place, allowing for easy modification such as theming. Since no pieces of code are coming from any external location, custom ROMs or APKs are always deodexed to ensure integrity.
How this works?
For the majority noobs amongst us, Android OS uses a Java-based virtual machine called the Dalvik Virtual Machine. A deodexed or .dex file contains the cache used by this virtual machine (referred to as Dalvik-cache) for a program, and it is stored inside the APK. An .odex file, on the other hand, is an optimized version of this same .dex file that is stored next to the APK as opposed to inside it. Android applies this technique by default to all the system applications.
When an Android-based system is booting, the davlik cache for the Davlik VM is built using these .odex files, allowing the OS to learn in advance what applications will be loaded, and thus speeds up the booting process.
By deodexing these APKs, a developer actually puts the .odex files back inside their respective APK packages. Since all code is now contained within the APK itself, it becomes possible to modify any application package without conflicting with the operating system’s execution environment.
Advanteges & Disadvantages
The advantage of deodexing is in modification possibilities. This is most widely used in custom ROMs and themes. A developer building a custom ROM would almost always choose to deodex the ROM package first, since that would not only allow him to modify various APKs, but also leave room for post-install theming.
On the other hand, since the .odex files were supposed to quickly build the dalvik cache, removing them would mean longer initial boot times. However, this is true only for the first ever boot after deodexing, since the cache would still get built over time as applications are used. Longer boot times may only be seen again if the dalvik cache is wiped for some reason.
Note:Themes for android come in APKs too, and if you want to modify any of those, you should always choose a dedoexed custom ROM.
[Guide] What is Zipalign and how to make Apps zipaligned
What is Zipalign?
Zipalign is an archive alignment tool introduced first time with 1.6 Android SDK (Software Development Kit). It optimizes the way an Android application package (APK) is packaged. Doing so enables the Android operating system to interact with the application more efficiently, and hence has the potential to make the application and overall the whole system much faster. Execution time is minimized for zipaligned applications, resulting is lesser amount of RAM consumption when running the APK.
How does it exact work?
In an Android operating environment, data files stored in each application package are accessed by multiple processes, for example, the installer will read the data manifest to determine the associated permissions; the system server can read these resources for multiple reasons, like displaying notifications; the Home application, for example, will read resources to get the application’s name and icon. Since Android is based on a a true multi-tasking operating infrastructure, these files are continually and repeatedly accessed. Finally, but not least, the application itself reads the manifest data.
As Android is Linux-based, memory-mapping plays a key role in efficient handling of processes. Essentially, the optimal alignment for the Android OS’ resource-handling code is 4-byte boundaries. What this means is that, if APKs are memory-mapped to 4-byte boundaries, and aligned accordingly, the OS will not need to ‘read through’ the whole application package to get to the desired data manifest. Every system process will know in advance where to look for it’s desired resources, and hence will execute much smoother and faster.
Summing it up, zipaligning an APK results in all uncompressed data within the package to be aligned on 4-byte boundaries, allowing all portions to be accessed directly with the memory-map. RAM consumption is lowered while execution because the querying code doesn’t have to read through the entire application package.
Disavantages of unaligned APKs
Quite understandably, situation would be reserved for unaligned application packages. Resource reading would be slow and memory usage would be on the higher end of the spectrum. It would also depend on how many unaligned applications are present. For example, if less number of applications with an unaligned home application, you’d see slower application launch times. This is the best case scenario. For a worst case scenario, having a number of unaligned applications will result in the system repeatedly starting and killing processes, struggling with lags and huge battery drain.
How to make APKs zipaligned?
As mentioned earlier, the zipalign tool became a part of Android SDK from 1.6 onwards. It can be found under the ‘tools’ folder of the SDK. To use it, simply run the command:
zipalign [-f] [-v] <alignment> infile.apk outfile.apk
Click to expand...
Click to collapse
...where infile.apk is the source file, and outfile.apk is the output file.
You can also verify the alignment of an APK file using the following command:
zipalign -c -v <alignment> existing.apk
Click to expand...
Click to collapse
...where existing.apk can be any application package that you need to get verified. Also, the <alignment> tag in both the commands needs to be an integral value (otherwise the command will return invalid). This value, although can be any integer, MUST always be 4, which would provide 32-bit alignment. Any other value and it will effectively do nothing.
Finally, for the flags used in these commands,
-f - overwrites existing outfile.zip
-v - will give verbose output
-c - will confirm the alignment of a given file
Click to expand...
Click to collapse
CAUTION: Zipalign operation must only be performed after you have signed the APK file with your private key. If zipaligned before signing, the signing procedure will disturb the alignment. Same holds true for any other alteration, addition or removal to the APK file. Any change after running zipalign will undo the alignment.
Source: addictivetips
[GUIDE] How to Deodex Jelly Bean firmware (I9070) - credits must go to anantttt
[How-To] Re-Odex a Rom - credits must go to TearsDontFalls -this guide is for S3, but you have Google to find what you need ... if you really need.
[ODEX][SCRIPT/TOOL] Odexer Tool 1.2 (03-28-2014)(MM-dd-yyyy)
Update 08.10.2014
Click to expand...
Click to collapse
[SCRIPT TO ODEX] Universal Odex Script Version 6.3.1 (11-03-2013)
Credits & Thanks for this tool:
MatrixDJ96
Click to expand...
Click to collapse
I think you just must create 1 thread titled "About Android" or someting like that
BTW it is good to know that:thumbup::thumbup:
Sent from my GT-I9070 using xda app-developers app
This materials are not created by me, I just searched and read carefully over the WWW in an attempt to bring as much informations to our forum S. Advance.
Only this was my job, along with the desire to know the phone held.
In my opinion, one thread with all the information is difficult to manage, because of that i'm so reluctant in what concerns for easy finding by members.
Make a Guide on how to (Re)Odex a Deodexed ROM if possible...
Sent from my GT-I9070 using xda app-developers app
Flash stock ROM?
R_a_z_v_a_n said:
Flash stock ROM?
Click to expand...
Click to collapse
Hahahaha.. but I wasn't Joking.. people say that its always better Re-Odex a Deoxed app after editing it
Understand now. Let me do some research and read what to do in that sense ...
Sami Kabir said:
Make a Guide on how to (Re)Odex a Deodexed ROM if possible...
Click to expand...
Click to collapse
Make it very short then.
Odex Me
(Post useful? Hit the Thanks button etc.)
Odex and Deodex
Hi,
I am a beginner in the android world and i have been trying to understand the android terms in detail. but i am still confused over the ODEX and DEODEX terms. I read you post but it still needs some more explanation of few things mentioned below.
Where is the .ODEX file stored in case of an ODEXED Rom?
Does the Dalvik Cache builds up in case the ROM in Deodexed. If yes then from where it fetches the required information?
Your post says that boot speed is increased in case of both the ODEX & DEODEX ROM after the first Boot. Then what is the exact difference between the two ROMS?
Does Dalvik Cache & DalviK VM independent whether the ROM is ODEX or DEODEX?
Presently my phone is ODEX (Stock ROM), once i DEODEX the ROM can i still install .APK files from Google Play or any other source?
Is tools which makes an APK ODEX or DEODEX part of the android operating system or should we make an APK Odexed or Deodexed using a laptop?
Please help me with the above questions.
R_a_z_v_a_n said:
What is an ODEX file?
In Android file system, applications come in packages with the extension .apk. These application packages, or APKs contain certain .odex files whose supposed function is to save space. These ‘odex’ files are actually collections of parts of an application that are optimized before booting. Doing so speeds up the boot process, as it preloads part of an application. On the other hand, it also makes hacking those applications difficult because a part of the coding has already been extracted to another location before execution.
What is an DEODEX file?
Deodexing is basically repackaging of these APKs in a certain way, such that they are reassembled into classes.dex files. By doing that, all pieces of an application package are put together back in one place, thus eliminating the worry of a modified APK conflicting with some separate odexed parts.
So, Deodexed ROMs (or APKs) have all their application packages put back together in one place, allowing for easy modification such as theming. Since no pieces of code are coming from any external location, custom ROMs or APKs are always deodexed to ensure integrity.
How this works?
For the majority noobs amongst us, Android OS uses a Java-based virtual machine called the Dalvik Virtual Machine. A deodexed or .dex file contains the cache used by this virtual machine (referred to as Dalvik-cache) for a program, and it is stored inside the APK. An .odex file, on the other hand, is an optimized version of this same .dex file that is stored next to the APK as opposed to inside it. Android applies this technique by default to all the system applications.
When an Android-based system is booting, the davlik cache for the Davlik VM is built using these .odex files, allowing the OS to learn in advance what applications will be loaded, and thus speeds up the booting process.
By deodexing these APKs, a developer actually puts the .odex files back inside their respective APK packages. Since all code is now contained within the APK itself, it becomes possible to modify any application package without conflicting with the operating system’s execution environment.
Advanteges & Disadvantages
The advantage of deodexing is in modification possibilities. This is most widely used in custom ROMs and themes. A developer building a custom ROM would almost always choose to deodex the ROM package first, since that would not only allow him to modify various APKs, but also leave room for post-install theming.
On the other hand, since the .odex files were supposed to quickly build the dalvik cache, removing them would mean longer initial boot times. However, this is true only for the first ever boot after deodexing, since the cache would still get built over time as applications are used. Longer boot times may only be seen again if the dalvik cache is wiped for some reason.
Note:Themes for android come in APKs too, and if you want to modify any of those, you should always choose a dedoexed custom ROM.
Click to expand...
Click to collapse
fredrickaein said:
1.Where is the .ODEX file stored in case of an ODEXED Rom?
2.Does the Dalvik Cache builds up in case the ROM in Deodexed. If yes then from where it fetches the required information?
3.Your post says that boot speed is increased in case of both the ODEX & DEODEX ROM after the first Boot. Then what is the exact difference between the two ROMS?
4.Does Dalvik Cache & DalviK VM independent whether the ROM is ODEX or DEODEX?
5.Presently my phone is ODEX (Stock ROM), once i DEODEX the ROM can i still install .APK files from Google Play or any other source?
6.Is tools which makes an APK ODEX or DEODEX part of the android operating system or should we make an APK Odexed or Deodexed using a laptop?
Click to expand...
Click to collapse
Some answers, I numbered your questions to be more easily tracked
1. In your /system
2. Android's Dalvik goes through every apk's and extracts the dex file from it. It places the dex files in the cache folder - located at /data/dalvik-cache. This is the directory that gets cleared when you clear the dalvik cache in your custom recovery like CWM or TWRP.
3. The difference is that deodexed ROMs are lighter and allow modifications but odexed ROMs load faster. ROMs come with Zipalign at boot that make a deodexed ROM load as fast as an odexed ROM.
4. I dont know the answer of this ... sorry.
5. Of course you can, is no reason to worry about.
6. You need android-sdk installed in your computer/laptop, busybox on the phone, xUltimate and some knowledge about whole process.
Thanks a few more on odexed and deodexed ROM
Hi,
Many thanks for your prompt reply. But please bare with me as i am going to ask more questions
Firstly let me ask you some more queries related to the earlier questions
1 Which folder in my ROM. I have root access, so i would like to view the files.
2 got it. saw the directory where the delvik cache is stored, but in case of a deodexed rom does this happen? i mean does the system store the dalvik cache by going through the apk if the ROM is deodexed. in other words does dalvik cache exist for deodexed ROM?
3 why is the deodexed ROM lighter? is it because it stores the app info at one place?
4. actually the question is same as no 2 above, Will i see the delvik-cache folder anymore if i deodex my ROM? if no then does the zipalign provides necessary data for the dalvik VM?
5.Ok i understood this
6. the process you are talking about is how to deodex my ROM. So i guess once i try to deodex my ROM the process will convert all the odexed app in my phone to deodexed. and henceforth all the appliccation that i install will be installed as a deodexed app. am i right in my guess?
Now some more questions please
7. is the only difference between them is the fact that odexed rom stores the app in two places and deodexed rom stores as a single apk?
8. what exactly is the .ODEX dex file. Is it a full copy of the apk or only a part of the apk. i guess it is this .ODEX file that makes the odexed rom heavy while the deodexed rom doesnt contain a .ODEX file which makes it lighter
R_a_z_v_a_n said:
Some answers, I numbered your questions to be more easily tracked
1. In your /system
2. Android's Dalvik goes through every apk's and extracts the dex file from it. It places the dex files in the cache folder - located at /data/dalvik-cache. This is the directory that gets cleared when you clear the dalvik cache in your custom recovery like CWM or TWRP.
3. The difference is that deodexed ROMs are lighter and allow modifications but odexed ROMs load faster. ROMs come with Zipalign at boot that make a deodexed ROM load as fast as an odexed ROM.
4. I dont know the answer of this ... sorry.
5. Of course you can, is no reason to worry about.
6. You need android-sdk installed in your computer/laptop, busybox on the phone, xUltimate and some knowledge about whole process.
Click to expand...
Click to collapse
My friend,
You ask too many questions and I do not think going somewhere after you have the answers.
So, lets start with ...
1.There is two place: I tell you in system/root ... search for directors -> data/app or system/app
2 Of course. Because of this the first start of a deodexed ROM is slower.
3 ... is it because it stores the app info at one place? I dont know for sure, but is one of the explanation. Lighter can also mean that the apk can be modified by Themers much easier without any risk.
4. Yes will see the folder, i just tell where is located from my phone when i answered before. And i have my ROM deodexed and zipalign
5....
6. You are right.
7. Yes, and much easier to theme without risks
8. I guess is correct, dont know much about that
present hipirch
Dear Razvan,
Thanks for the help. I am very curious in nature, that why i bothered you so much.
Now please a last suggestion from you.
Shall i Deodex my Samsung Stock ROM? or go for already deodexed Pure Vanila or Jelly Bean LQB / SlimJB - Shaaan (Your Rom). please Suggest.
And also based on your experience, which Custom ROM you prefer for Galaxy S Advance (Just your Opinion )
R_a_z_v_a_n said:
My friend,
You ask too many questions and I do not think going somewhere after you have the answers.
So, lets start with ...
1.There is two place: I tell you in system/root ... search for directors -> data/app or system/app
2 Of course. Because of this the first start of a deodexed ROM is slower.
3 ... is it because it stores the app info at one place? I dont know for sure, but is one of the explanation. Lighter can also mean that the apk can be modified by Themers much easier without any risk.
4. Yes will see the folder, i just tell where is located from my phone when i answered before. And i have my ROM deodexed and zipalign
5....
6. You are right.
7. Yes, and much easier to theme without risks
8. I guess is correct, dont know much about that
Click to expand...
Click to collapse
Do not you worry I did not mind. :highfive:
You can put a deodexed ROM, but only if you want to apply some themes or customization, otherwise there is no reason to do so.
Frankly, in terms of what ROM to install, I can not give any advice, because besides his SlimJB Shaaan, i did not try any custom ROM, but i'm waiting, in silence , Cyanogen ROM stable and then i can make a choice.
Good luck
Yeah, I am also waiting for a stable 10.1 of cynogen. But how is the rom that you are using? How stable is it? I am also planing to try pure vanila till we have a stable release of cynogen. Anyways many thanks for the help.
R_a_z_v_a_n said:
Do not you worry I did not mind. :highfive:
You can put a deodexed ROM, but only if you want to apply some themes or customization, otherwise there is no reason to do so.
Frankly, in terms of what ROM to install, I can not give any advice, because besides his SlimJB Shaaan, i did not try any custom ROM, but i'm waiting, in silence , Cyanogen ROM stable and then i can make a choice.
Good luck
Click to expand...
Click to collapse
For the moment i'm using LQB Serbia, deodexed, zipaligned and debloated with CoCore 6.x kernel and i'm SOOO happy .... but we are OFF TOPIC here, thanks for understanding me.
Just a question. I am now on stock odex DXLSE with speedmod kernel. Can I flash on cwm the deodexed version of the same rom without wiping the data and without losing all of my files? Thanks.
JB? Rooted?
Its necessary...
Sent from my GT-I9070 using xda premium
For those interested in Custom ROMs and the modding scene, you've probably already heard of the terms ''odexed'', a characteristic of Android ROMs and ‘’deodexed'', an element known from custom ROMs. But what exactly hides behind these two terms and which advantages or even disadvantages does each one present? Well, let me explain...
Odexed
With an odexed ROM, you'll find files which end with .odex within the system app folders. This stands for ''Optimized Dalvik Executable File''. Browser.apk and browser.odex will appear in the /system/app folder as well.
But what's an .odex file?
And most importantly, for what is an .odex file used? It serves the purpose of organizing the system structure which contains application information (start up, usage, etc) and allows Android to access this information without having to go search for them and decompress them from .apk files. Odex files are directly loaded into the dalvik cache, which you've probably heard of when talking about wiping before or after flashing a ROM. This allows your system to run a lot quicker.
Advantages of an Odexed ROM
-Applications start a lot faster since the important information has already been loaded by the system beforehand.
-The .apk files are not as big, therefore they take up less room.
Disadvantages
App modding/themes/hacking becomes a lot more difficult because the code is now found in two different locations.
If you delete some of the app data, the .odex file must also be deleted in order to avoid errors.
The usual classes.dexfiles files in an APK: here are the ones from the navigator / © AndroidPIT
Deodexed
When it comes to a deodexed ROM, all of the application information is found in an .apk file. The code found in the .odex files are added to the apk under the name classes.dex.
Advantages
Deodexed is a lot easier for modding/themes/hacking, because the data is found within the APK.
System apps are easier to delete, since only the APK must also be deleted.
Disadvantages
The program library can't be loaded beforehand, therefore slowing down the app start.
Bootloading also slows way down because the APK content first needs to be taken from the system for the reason that a direct access is no longer present.
It's important to note that these two disadvantages quickly go unnoticed since the dalvik cache stores information that has been extracted from the APK and saves it, to then be retrieved later on. Longer loading times would then be a direct consequence of emptying the Dalvik cache in the event of a Custom Recovery.
Bottom Line
Android versions which come directly from manufacturers are in most cases odexed. Custom ROMs on the other hand are deodexed nine times out of ten, which allows them to take up less room and offer more customization possibilities. So there you have it: odexed versions are optimized for speed, while deodoxed is better for hacking, themes and modding. Simple, right?
Right sir?
Enviado desde mi SM-N910S mediante Tapatalk