Database Info

Odex files deodexing and zipalign explained - Android General

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.

Related

Hi there,
I has disassembled an odex file and changed something. As I understand I can't make it an odex again but I must make a dex file and put this with the filename classes.dex in the apk file.
Can I just put it in the apk file and just sign the package again or do I need first to convert the binary xml files from the apk to normal files and then pack the apk file back?
Thanks

So, I've been removing / stripping media and languages from apks for a few different ICS roms. I just have a few questions. Does the framework APK have to be signed, or no [like the 'system' apks]? Also, how can I extract, or view the resources / decompile / resign* in the jar files in the framework folder?
I wasn't sure if Android had an API for this like BBOS does for .cod's, or I'd just make a program to do it.

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!

Is it possible to modify code in a system .odex file without de-odexing?
Here is what I've been trying, without success (Windows computer, Samsung Epic 4G Touch phone, stock ROM with 2.3.6):
On my computer, using Android Commander, I pull a .odex from /system/app to my computer. There is a corresponding .apk, but I leave that alone. I also pull the entire /system/framework folder.
On my computer, from the location containing the framework folder and the .odex file, I run "java -jar baksmali.jar --api-level 10 -d framework -x <FILE_NAME>.odex". This creates an "out" folder, with the com/android/<FILE_NAME> folder structure and the code.
I modify the code (.smali files).
I rename the original .odex file and run "java -jar smali.jar --api-level 10 out/ -o <FILE_NAME>.odex". This creates a new .odex file that, as far as I can tell, should have the updated code in it.
Using Android Commander, I push the new .odex to /system/app on my phone, change the permissions to 644, and reboot the phone.​
The changes aren't having an effect. In fact, the status bar is completely gone (the example I'm working on is a mod to the status bar in SystemUI.odex).
Any idea what I'm doing wrong?

So I'm getting the feeling that it's not possible to edit odexed apks. Is there anyway to de-odex just a single apk rather than the whole rom?

Brent212 said:
So I'm getting the feeling that it's not possible to edit odexed apks. Is there anyway to de-odex just a single apk rather than the whole rom?
Click to expand...
Click to collapse
http://forum.xda-developers.com/showthread.php?t=1208320
Basically, no odex can be edited and put back that easy. Wrapping and Signing ODEX style is required.

Awesome! That thread's perfect. I'm hoping I can deodex, mod the code, create a classes.dex file and put it in with the .apk, zipalign it, and just replace the existing .apk and .odex with the new .apk.

That thread (http://forum.xda-developers.com/showthread.php?t=1208320) had the answers I was looking for.
The trick was to either rename the new .odex to classes.dex and put it into the .apk, and zipalign the .apk (although I have a feeling that wasn't actually necessary), or to copy the signature from the old .odex file to the new one.

Brent212 said:
That thread (http://forum.xda-developers.com/showthread.php?t=1208320) had the answers I was looking for.
The trick was to either rename the new .odex to classes.dex and put it into the .apk, and zipalign the .apk (although I have a feeling that wasn't actually necessary), or to copy the signature from the old .odex file to the new one.
Click to expand...
Click to collapse
Odex is not dex. And vice versa. Remember that. When compiling, the result is always dex. To have odex, you need to wrap it with dexopt-wrapper within your phone.
sent from my white ray using XDA App

Hi,
anyone know how to manully update an installed classes.dex file in /data/dalvik-cache? The original classes.dex of the apk differs from the installed one. Android seems to process/modify it first before placing in dalvik-cache.
Anyone know how to do that manually? It would be a lot faster to just replace the dex file instead of the whole apk if you frequently have to change it.

Decompile the dex file using baksmali/smali scripts if you need to make an edit to classes.dex. then copy then over to where they need to go.
If that makes sense
sent from my T989 full of CM awesomeness and a touch of Venom from the Darkside!!

That doesn't work. Like i said above it differs from the apk one and i cannot just extract and replace it in dalvik-cache.
DexOpt: expected optimized DEX, found unoptimized
Click to expand...
Click to collapse
I tried to use 'dexopt' manually but it looks like its not intended to be run at shell level and 'dexopt-wrapper' wants the apk (to odex). That wouldn't lead to any speed benefits.
Any ideas?