Related
Hey guys, so this script de-odexe's a rom's apks and jar's.
Many thanks to ofcourse JesusFreke who created this method and the way to do it. Also to coolbho for his apkopt script from which i learnt certain techniques of batch programming. This is crzyruski script updated with jesus freke's latest smali/baksmali update ver 1.2.3
It incorporates detecting the bootclasspath of the odex instead of the user specifying it. For non standard odex however a specific bootclass path must be defined. For example:
According to Jr33 for rosie deodexing u have to add class paths com.htc.framework.jar. Thank him for the new Sense bootclasspaths
For those who dont know, this essentially uses jf's method of baksmali'ing the odex file into smali files, and then recreating the classes.dex file and packaging it into the apk hence disregarding the need for the odex.
*New Menu added
*Ability to specify custom bootclasspath (eg for sense ui)
*Added a java check at the beginning
*Added 1.2.3 smali/baksmali with froyo support(thank jf ofcourse )
*Modified it so if an error is encountered during deodexing, it leaves that file behind so once done you know what files encountered errors
*Added Ignore Mode
*Removed zipalign
*If apk doesnt have corresponding odex, it moves it to deodexed_APK instead of user manually moving it
*Added compression level option
*You can monitor the status of ignore mode / compression level right above the main menu
DISCLAIMER:
Its a batch file so it'll only work on windows.
Convince farmatito to bring this to linux
Thanks
So I checked this out and all ...
It's only apk's, right?
I only glanced but I didn't see anything in there for framework, etc.
If I'm right, then perhaps .. you should just say it de-odex's a ROM's apk's instead of the entire ROM.
~enom~
enomther said:
So I checked this out and all ...
It's only apk's, right?
I only glanced but I didn't see anything in there for framework, etc.
If I'm right, then perhaps .. you should just say it de-odex's a ROM's apk's instead of the entire ROM.
~enom~
Click to expand...
Click to collapse
Oh, yea so it takes the apk and odex and creates the classes.dex and repackages into the apk so u only need the apk. Ok, ill change the post a bit also yes, it doesnt do frameworks cuz i dont think they have odex's and the jar's do but i dunno of a method to do tht
Daneshm90 said:
Oh, yea so it takes the apk and odex and creates the classes.dex and repackages into the apk so u only need the apk. Ok, ill change the post a bit also yes, it doesnt do frameworks cuz i dont think they have odex's and the jar's do but i dunno of a method to do tht
Click to expand...
Click to collapse
Yea ... the jar's have dex's too and can be odex-d and can also be un-odex-d. I personally have never been able to successfully de-odex a fully odex'd framework (but I haven't tried hard enough either ). The main difference is once they are de-odex'd ... you insert the classes.dex into the jar and no re-signing required (as they aren't signed).
Either way, nice script mate. Good Job!
~enom~
enomther said:
Yea ... the jar's have dex's too and can be odex-d and can also be un-odex-d. I personally have never been able to successfully de-odex a fully odex'd framework (but I haven't tried hard enough either ). The main difference is once they are de-odex'd ... you insert the classes.dex into the jar and no re-signing required (as they aren't signed).
Either way, nice script mate. Good Job!
~enom~
Click to expand...
Click to collapse
Ah sweet, something i shall incorporate in the script later on. thanx
so will this script allow you to take an app from say a cliq dump and allow it to run on any android device?
Will this allow you to grab the MyFaves from a TMO rom and de-odex it and install?
Joe333x said:
so will this script allow you to take an app from say a cliq dump and allow it to run on any android device?
Click to expand...
Click to collapse
Emm...no im 99.99% sure it doesnt help tht way. I know that odex's cause customization problems in roms....there are other factors im sure
mrandroid said:
Will this allow you to grab the MyFaves from a TMO rom and de-odex it and install?
Click to expand...
Click to collapse
MyFaves == No Go ... it requires some other form of trickery ... I'm not sure what exactly ... as I did de-odex it and it would not work properly on test-key ROM's like CM, etc.
... So it requires more than a simple de-odex.
~enom~
does your phone need to be connected? I noticed some ADB commands in the script
Daneshm90 said:
Hey guys, so this script de-odexe's a rom's apks.
Many thanks to ofcourse JesusFreke who created this method and the way to do it. Also to coolbho for his apkopt script from which i learnt certain techniques of batch programming
For those who dont know, this essentially uses jf's method of baksmali'ing the odex file into smali files, and then recreating the classes.dex file and packaging it into the apk hence disregarding the need for the odex.
Oh also make sure to place only apk's that have their corresponding odex's. Dont place only apk's !!!!!
Instructions:[WINDOWS ONLY & Phone Must stay connected with adb WORKING]
1. Download http://www.mediafire.com/?mwownkhzm4m
2. Extract to a folder
3. Place all your rom's apk's which have odex's attached to them into that folder
4. Run deoall
5. Copy all the apk's from the deodexed folder into ur corresponding rom app folder
Thanks
Upcoming:
Seperate Framework & apps folder
De-odex framework apk's and jar's (thanx for the tip enomther )
Click to expand...
Click to collapse
So the apk after that has the DEX built in or is dexopt still needed?
wesgarner said:
So the apk after that has the DEX built in or is dexopt still needed?
Click to expand...
Click to collapse
>.<.......................
kingklick said:
>.<.......................
Click to expand...
Click to collapse
Hey I am just double checking
If you're having problems de-odexing the framework is because there's a particular order to it.
If you look at your bootclasspath you'll see the framework files necessary to boot the android system, the rest (whatever's not in there) can be dexopted in any order.
If you're trying to de-odex the framework, you're going to have to backtrace yourself.
Personally, I do:
for i in /system/app/*.apk
unodex
for j in /system/framework/nonCoreJar1.jar /system/framework/nonCoreJar2.jar /system/framework/...nonCoreJarN.jar
unodex
for k in /system/framework/bootClassPathJarN.jar /system/framework/bootClassPathJarN-1.jar /system/framework/...bootClassPathJarN-y.jar
unodex
it requires a couple of reboots along the way to deal with any created dalvik-cache so that it doesn't interfere with the next needed classes.dex
the only turn-off was that it requires a running system to do it (it's not that big of a problem, but porting and then flashing starts getting old after a while).
Has that changed?
Does OP mean you can take the apks, toss them into a folder, and then do it from the computer without the phone?
---edit---
shoot me for not reading.
Daneshm90 said:
Instructions:[WINDOWS ONLY & Phone Must stay connected with adb WORKING]
Click to expand...
Click to collapse
jubeh said:
If you're having problems de-odexing the framework is because there's a particular order to it.
If you look at your bootclasspath you'll see the framework files necessary to boot the android system, the rest (whatever's not in there) can be dexopted in any order.
If you're trying to de-odex the framework, you're going to have to backtrace yourself.
Personally, I do:
for i in /system/app/*.apk
unodex
for j in /system/framework/nonCoreJar1.jar /system/framework/nonCoreJar2.jar /system/framework/...nonCoreJarN.jar
unodex
for k in /system/framework/bootClassPathJarN.jar /system/framework/bootClassPathJarN-1.jar /system/framework/...bootClassPathJarN-y.jar
unodex
it requires a couple of reboots along the way to deal with any created dalvik-cache so that it doesn't interfere with the next needed classes.dex
the only turn-off was that it requires a running system to do it (it's not that big of a problem, but porting and then flashing starts getting old after a while).
Has that changed?
Does OP mean you can take the apks, toss them into a folder, and then do it from the computer without the phone?
Click to expand...
Click to collapse
Yea I would figure as much ... simply b/c one must follow the BOOTCLASSPATH order when odex'ing ...
So Jubeh .. you're saying you've personally de-odex'd an fully odex'd framework b4?
Just looking for confirmation from someone who has personally ... since I'm too lazy to go through that hectik crappy process
~enom~
enomther said:
Yea I would figure as much ... simply b/c one must follow the BOOTCLASSPATH order when odex'ing ...
So Jubeh .. you're saying you've personally de-odex'd an fully odex'd framework b4?
Just looking for confirmation from someone who has personally ... since I'm too lazy to go through that hectik crappy process
~enom~
Click to expand...
Click to collapse
I did it with the tattoo build, but upon boot I would get all sorts of fc's, but I think that was due more to a bad, hasty port than the deodexing. It was also a long time ago when the tool first came out, dont know if there's been newer revisions, so I'll try it again on that funky tattoo rom.
K guys one problem i found after doing multiple apk's is that i need to give the listening dex command a bit delay so its ready for baksmali. I was doing it right after which it misses for some conversions. I'll upload with delay between the two commands. Hmm framework i gotta give a shot :/ Sounds interesting ...
Solid script! Should make deodexing A LOT easier
Ok so i uploaded with delay between, seems to work fine, tested a LOT of times
thanks for this! can't wait for frameworks to be de-odexed.
jubeh: Thanks for the info. I had no idea and have informed JF previously here: http://jf.andblogs.net/2009/11/08/smalibaksmali-v1-0/ (see comments)
Building Your Own ROM
This took forever. Please hit the thanks button if this helped you lol
I'm the Developer who's currently working on Delta ROM, and I developed Vengeance ROM all the way through Version 3.2. I've had MANY people message me asking how they can develop their own ROM, so, instead of helping everyone individually, I've decided to make a guide for the whole community to use. The preliminary part of this guide will take you through getting a base using two methods, giving your ROM it's own name, debloating your ROM, adding the kernel of your choice, and editing build.prop and adding init.d tweaks.
Future posts will include everything from adding Aroma Installer to adding mods.
So with that, let's begin.
Building A Base
Building from a stock, rooted, de-odexed base WITHOUT the kitchen (recommended):
Downloading and moving the Base
This is how I create my ROMs. Other developers along with myself have found that Dsixda's android kitchen can create issues with your ROM (namely the updater-script), so building from an already existing base is always the safest in my opinion.
First, we will need to get a base. There are many different versions out there, however, they almost are all the exact same. I use Scrosler's base for my ROMs. You can find his base, along with the stock Modem, RPM, and kernel with custom boot animation support here.
Download Scott's base, and extract the files within the ZIP archive somewhere on your computer. I recommend creating a development directory somewhere on your computer.
I work on Mac OS X, so my development directory is in my home folder under /dev.
In Windows, this sample directory would be in C:\\Users\YourName\Dev
Linux is similar to OS X. I recommend placing your Development directory in ~/Dev (~/ is your home folder's directory)
Of course, you can place these files wherever you want this is just how I have my computer set up.
_________________________________________________________________________________________________________________________
Building a base WITH the kitchen (not recommended due to incompatibilities and time consumption):
Downloading and Installing the Kitchen
This will teach you how to create a base of your own using Samsung's ODIN file and Dsixda's Kitchen.
First of all, you must download Dsixda's Kitchen. Luckily, the Verizon S3 is supported by the kitchen, so BUILDING your base using the kitchen is practically painless. Getting the kitchen running is difficult at times, and you may run into issues later. If you want to evade these issues, I suggest building your ROM from an already existing base. If you don't want to do that, keep reading . The kitchen can be downloaded from here. Just click on the latest version, and press the button with the cloud and the word "ZIP" to download the repo as a zip file. Keep that somewhere on your computer...
Setting up the kitchen is a different story. It's relatively easy on Mac and Linux, but because the kitchen is designed to run in UNIX environments, it's a little bit tougher on Windows. You can find a guide for setting up the kitchen here.
Adding The Odin Files for the Kitchen To Compile
The next step to compiling a base using the kitchen is to take Samsung's files, and add them to the kitchen folder. This is pretty simple. Download the VRBLK3 Stock ODIN from here (thanks open1your1eyes0).
Extract the files to the original_update folder in your kitchen folder.
Building Using the Kitchen
Finally, we're ready to build your base using the kitchen. Start the kitchen by navigating to your kitchen folder in terminal (or command prompt through Cygwin on Windows), and typing "./menu" on mac and linux, or just typing "menu" on Windows.
Option 1 within the kitchen should compile a base ROM for you. You can then root, deodex, zipalign, and change the name of your ROM, and much more, from within the kitchen.
When you're done, option 99 will compile your ROM and move a ZIP file to your OUTPUT_ZIP folder within your kitchen folder.
_________________________________________________________________________________________________________________________
Renaming your ROM
Renaming your ROM is very simple. After building your base, unzip the files and navigate to /system/build.prop. In the build prop, find the line that says "ro.build.display.id=". Replace the rest of the text on this line with your desired name. Save your build.prop. Thats it
Debloating Your ROM
Debloating your ROM is fairly simple as well. The list of removable Apps on the S3 can be found here (thanks to whoever made this, you are a god lol). This is a list for the international version of the S3, but most of the files are the same and MOST Verizon Apps can be removed as well.
Just delete the apks that you want to remove from your /system/app folder within your ROM files.
Init.d Tweaks
Init.d tweaks are scripts that allow your ROM to execute certain actions upon boot. For example, in my Delta ROM, I have an init.d tweak that zipaligns all apks upon boot.
While this guide won't cover creating your own init.d tweaks, adding them is simple. Take the init.d script that you find somewhere online, and simply drop it into your /system/etc/init.d folder. That's all.
Be aware that a lot of people make claims for their tweaks like "best RAM management tweaks" whn posing the tweaks in another device forum. For example, if you found a thread with the "best RAM management tweaks" in the Galaxy S forums, those tweaks are probably not good for our device since we have more available RAM than they do. Overall, it's best to DO YOUR RESEARCH and design your own scripts.
Build.prop Tweaks
Build.prop tweaks are lines added to your build.prop file within /system. They can do many things, and many of them improve performance and battery life on your ROM. A simple list of build.prop tweaks can be found here (Thanks for the new link, upndwn4par). Please note that not all build.prop tweaks out there will work for your device. Just add the lines that you want to add to the BOTTOM of your build.prop file, and save it.
Adding a Custom Kernel
When I first started building ROMs, one of the things that I couldn't figure out was how to add a custom kernel to my ROM. It's actually very simple. Find the kernel you want, download it, extract the zip file, and copy it's files into your ROM in the right locations. For example, you would replace the boot.img in your ROM with the boot.img from your custom kernel, and you would replace the modules in your /system/lib/modules folder with the module files from the kernel. Continue doing this until all of the kernels files are in your ROM. However, NEVER copy over the META-INF folder.
Flashing Your ROM
This is pretty simple. Simply compress your ROM files (boot.img, system folder, Meta-inf folder, and anything else) into a regular ZIP file, move the ZIP to your phone, boot into recovery, wipe data, cache, and dalvik cache, and flash your ROM.
If you did everything right, you should now be running your ROM Hopefully my guide helped you. Feel free to message me if you run into any issues or just have any general questions.
There is much more to development than just this. But this is meant to get you guys started
KANGING
Do NOT, I repeat DO NOT, take anything from another developer's ROM without his/her permission. This is called kanging, and it is extremely frowned upon and even rude because another Dev has spent A LOT of time slaving over the work, and then you take it and use it as your own. I can't speak for other Devs, but if you want something from my ROM, just ask. I'm a pretty open-minded guy, and chances are that I'm gonna say yes.
Credit
Always give credit where credit is due. If a developer helped you out in any way with your ROM, it is always courteous to include them in the credits section of your ROM.
Thanks guys
reserved
this is mine too
Re: [GUIDE] Edgehood's All Inclusive ROM Making Guide
First
Thanks I think I'll give it a go.. the best Rom is your own I suppose. .when your adding in some of your init.d when do find weather they will work properly? Is there a program to run your rom on with windows pc or ubuntu before flashing perhaps?
I would like to get Reim's builds props and such(with all do respect)
Nice!!! Thanks for this. You da man!
Sent from my SCH-I535 using xda premium
Edgehood said:
Building Your Own ROM
This took forever. Please hit the thanks button if this helped you lol
I'm the Developer who's currently working on Delta ROM, and I developed Vengeance ROM all the way through Version 3.2. I've had MANY people message me asking how they can develop their own ROM, so, instead of helping everyone individually, I've decided to make a guide for the whole community to use. The preliminary part of this guide will take you through getting a base using two methods, giving your ROM it's own name, debloating your ROM, adding the kernel of your choice, and editing build.prop and adding init.d tweaks.
Future posts will include everything from adding Aroma Installer to adding mods.
So with that, let's begin.
Building A Base
Building from a stock, rooted, de-odexed base WITHOUT the kitchen (recommended):
Downloading and moving the Base
This is how I create my ROMs. Other developers along with myself have found that Dsixda's android kitchen can create issues with your ROM, so building from an already existing base is always the safest in my opinion.
First, we will need to get a base. There are many different versions out there, however, they almost are all the exact same. I use beanstown106's base for my ROMs. You can find his base, along with the stock Modem, RPM, and kernel with custom boot animation support here.
Download Bean's base, and extract the files within the ZIP archive somewhere on your computer. I recommend creating a development directory somewhere on your computer.
I work on Mac OS X, so my development directory is in my home folder under /dev.
In Windows, this sample directory would be in C:\\Users\YourName\Dev
Linux is similar to OS X. I recommend placing your Development directory in ~/Dev (~/ is your home folder's directory)
Of course, you can place these files wherever you want this is just how I have my computer set up.
_________________________________________________________________________________________________________________________
Building a base WITH the kitchen (not recommended due to incompatibilities and time consumption):
Downloading and Installing the Kitchen
This will teach you how to create a base of your own using Samsung's ODIN file and Dsixda's Kitchen.
First of all, you must download Dsixda's Kitchen. Luckily, the Verizon S3 is supported by the kitchen, so BUILDING your base using the kitchen is practically painless. Getting the kitchen running is difficult at times, and you may run into issues later. If you want to evade these issues, I suggest building your ROM from an already existing base. If you don't want to do that, keep reading . The kitchen can be downloaded from here. Just click on the latest version, and press the button with the cloud and the word "ZIP" to download the repo as a zip file. Keep that somewhere on your computer...
Setting up the kitchen is a different story. It's relatively easy on Mac and Linux, but because the kitchen is designed to run in UNIX environments, it's a little bit tougher on Windows. You can find a guide for setting up the kitchen here.
Adding The Odin Files for the Kitchen To Compile
The next step to compiling a base using the kitchen is to take Samsung's files, and add them to the kitchen folder. This is pretty simple. Download the VRBLK3 Stock ODIN from here (thanks open1your1eyes0).
Extract the files to the original_update folder in your kitchen folder.
Building Using the Kitchen
Finally, we're ready to build your base using the kitchen. Start the kitchen by navigating to your kitchen folder in terminal (or command prompt through Cygwin on Windows), and typing "./menu" on mac and linux, or just typing "menu" on Windows.
Option 1 within the kitchen should compile a base ROM for you. You can then root, deodex, zipalign, and change the name of your ROM, and much more, from within the kitchen.
When you're done, option 99 will compile your ROM and move a ZIP file to your OUTPUT_ZIP folder within your kitchen folder.
_________________________________________________________________________________________________________________________
Renaming your ROM
Renaming your ROM is very simple. After building your base, unzip the files and navigate to /system/build.prop. In the build prop, find the line that says "ro.build.display.id=". Replace the rest of the text on this line with your desired name. Save your build.prop. Thats it
Debloating Your ROM
Debloating your ROM is fairly simple as well. The list of removable Apps on the S3 can be found here (thanks to whoever made this, you are a god lol). This is a list for the international version of the S3, but most of the files are the same and MOST Verizon Apps can be removed as well.
Just delete the apks that you want to remove from your /system/app folder within your ROM files.
Init.d Tweaks
Init.d tweaks are scripts that allow your ROM to execute certain actions upon boot. For example, in my Delta ROM, I have an init.d tweak that zipaligns all apks upon boot.
While this guide won't cover creating your own init.d tweaks, adding them is simple. Take the init.d script that you find somewhere online, and simply drop it into your /system/etc/init.d folder. That's all.
Be aware that a lot of people make claims for their tweaks like "best RAM management tweaks" whn posing the tweaks in another device forum. For example, if you found a thread with the "best RAM management tweaks" in the Galaxy S forums, those tweaks are probably not good for our device since we have more available RAM than they do. Overall, it's best to DO YOUR RESEARCH and design your own scripts.
Build.prop Tweaks
Build.prop tweaks are lines added to your build.prop file within /system. They can do many things, and many of them improve performance and battery life on your ROM. A simple list of build.prop tweaks can be found here. Just add the lines that you want to add to the BOTTOM of your build.prop file, and save it.
Adding a Custom Kernel
When I first started building ROMs, one of the things that I couldn't figure out was how to add a custom kernel to my ROM. It's actually very simple. Find the kernel you want, download it, extract the zip file, and copy it's files into your ROM in the right locations. For example, you would replace the boot.img in your ROM with the boot.img from your custom kernel, and you would replace the modules in your /system/lib/modules folder with the module files from the kernel. Continue doing this until all of the kernels files are in your ROM.
Flashing Your ROM
This is pretty simple. Simply compress your ROM files (boot.img, system folder, Meta-inf folder, and anything else) into a regular ZIP file, move the ZIP to your phone, boot into recovery, wipe data, cache, and dalvik cache, and flash your ROM.
If you did everything right, you should now be running your ROM Hopefully my guide helped you. Feel free to message me if you run into any issues or just have any general questions.
There is much more to development than just this. But this is meant to get you guys started
KANGING
Do NOT, I repeat DO NOT, take anything from another developer's ROM without his/her permission. This is called kanging, and it is extremely frowned upon and even rude because another Dev has spent A LOT of time slaving over the work, and then you take it and use it as your own. I can't speak for other Devs, but if you want something from my ROM, just ask. I'm a pretty open-minded guy, and chances are that I'm gonna say yes.
Credit
Always give credit where credit is due. If a developer helped you out in any way with your ROM, it is always courteous to include them in the credits section of your ROM.
Thanks guys
Click to expand...
Click to collapse
you make it look easy. lol nice job. someday possibly. someday....
Thanks for this Edge. I'm gonna try and build my own rom now thanks to you. I really appreciate all the guides. Keep them coming when u get a chance.
Sent from my SCH-I535 using xda premium
Fantastic work,thanks
how do you open the build.prop file?
You sure we should use that link for build props as reference? Seems like a lot of bad reviews fir only 2 pages.
Sent from my SCH-I535 using Tapatalk 2
These threads are always great to encourage people to get involved. Nice work!
Sent from my SCH-I535 using Xparent ICS Tapatalk 2
Nice guide. These are always great to get people started.
Though I must disagree with your comments on using the kitchen for a few reasons.
1) There are no compatibility problems that I have experienced.
2) It is not time consuming. It actually saves a lot of time. For example, if you have a decent PC you can:
a) Deodex a ROM in about 5 minutes.
b) Zipalign every apk in about 30 seconds.
c) Add init.d support, root, and buybox in about 2 minutes.
3) The kitchen builds ROMs, it does not compile them.
Also, most of the build.prop tweaks in the reference you linked (and just about every guide you can find) are bogus. Most have been completely debunked. Also, any tweak with a "mot" in it is strictly for Motorola devices.
Jeff Mixon article on build.prop tweaks.
upndwn4par said:
Nice guide. These are always great to get people started.
Though I must disagree with your comments on using the kitchen for a few reasons.
1) There are no compatibility problems that I have experienced.
2) It is not time consuming. It actually saves a lot of time. For example, if you have a decent PC you can:
a) Deodex a ROM in about 5 minutes.
b) Zipalign every apk in about 30 seconds.
c) Add init.d support, root, and buybox in about 2 minutes.
3) The kitchen builds ROMs, it does not compile them.
Also, most of the build.prop tweaks in the reference you linked (and just about every guide you can find) are bogus. Most have been completely debunked. Also, any tweak with a "mot" in it is strictly for Motorola devices.
Jeff Mixon article on build.prop tweaks.
Click to expand...
Click to collapse
I've experienced a few issues when building with the kitchen. For example, the ROM wouldn't flash after cooking it because it said there was no MD5.
The kitchen does save time once you get it set up. However, its much faster to download a 700-800mb base and move it into a folder than download >1GB ODIN file and get the kitchen set up correctly. Especially if you have to set up Cygwin or a VM if you're on windows. I agree with you that with a good PC, the kitchen will build a ROM fast. But not everyone (including myself lol) has a PC that can build them that fast.
It is completely a matter of preference though. I prefer to build my ROMs from a base, but you prefer to use the kitchen. After all, that's why I included both methods in the guide
I'll look at the build.prop thing, I might've posted the wrong link. I was exhausted lol
Thanks,
Edge
EDIT: I changed the build.prop link to the article you posted. Thanks man
awesome.. will give it a shot when I have some time
thank you
I assume this is for building when one doesn't want to change any other files than the ones you mention. But if I want to alter something, say, on the notification bar, I would need instructions on what files to alter and, if relevant, how to compile my changes into a binary that can then be included in the ROM. This is a good start so thank you.
thornev said:
I assume this is for building when one doesn't want to change any other files than the ones you mention. But if I want to alter something, say, on the notification bar, I would need instructions on what files to alter and, if relevant, how to compile my changes into a binary that can then be included in the ROM. This is a good start so thank you.
Click to expand...
Click to collapse
Correct. It says that there is more to developing and that this should get you started
Nice and quick guide! Good job! It really is simple stuff once you get familiar w/ files and all.
HaVoK C89 said:
Nice and quick guide! Good job! It really is simple stuff once you get familiar w/ files and all.
Click to expand...
Click to collapse
Thanks!
Nice work
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
What is ART?
ART stands for Android runtime which is a new runtime like Dalvik which is introduced experimentally in the 4.4 release. This is a preview of work in progress in KitKat that can be turned on in Settings > developer option.n 4.4 both runtimes are now available, Dalvik runtime (libdvm.so) and the ART (libart.so).The user can choose it from developer options.
Click to expand...
Click to collapse
Difference between Dalvik and ART
Dalvik
Dalvik runtime uses JIT(Just-In-Time) compilation to interpret Bytecode
Now lets understand the technical info and terms in the above sentence.
Click to expand...
Click to collapse
Compiler
A compiler is a program or set of programs that transforms source code written in a programming language (the source language) into another computer language
Click to expand...
Click to collapse
Bytecode
Bytecode also known as p-code (portable code), is a form of instruction set designed for efficient execution by a software interpreter
Click to expand...
Click to collapse
Interpreter
Interpreter is a program which translates the source code into computer/machine language
Click to expand...
Click to collapse
JIT compliation
JIT compliation interprets the bytecode into machine language at it's runtime (at the time when the apps are executed).
Click to expand...
Click to collapse
Now summing up all these Dalvik runtime does everything when the apps are executed. Now this is where we must discuss odexed and deodexed ROM. usually all stock ROMs released by OEMs are only odexed only due to this reason. odex means a part of the app is already compiled and it is written into dalvik VM(VM=Virtual Machine). and it runs at boot so while execution of apps JIT has to compile only the remaining part of the code when the apps is executed, this is why odexed ROM is faster than deodexed ROM.
But the disadvantage of odexed ROM is it cannot be edited/themed easily as a part of code is seperated in a separate file, and deodexing means the odex part of the file is put back into the apk/jar itself which makes editing/theming easy since the full code is packed inside a single file but it decreases speed because JIT has to compile full code when the app is executed
ART
ART uses AOT compilation to interpret bytecode.
I hope you can refer to dalvik paragraph to know about these technical terms.
Click to expand...
Click to collapse
what is AOT compilation
AOT is a method of compilation which compiles the code into machine language when the app is installed itself, means no compilation is done at the time of execution of app. This makes the apps launch speed amazingly fast.
Click to expand...
Click to collapse
Advantages of ART over Dalvik
The apps launch speed is amazingly fast in case of ART since nothing is compiled at execution.
Boot speed is faster than dalvik since nothing is execued from dalvik partition as in case of odexed ROM in dalvik
Increases battery backup by reducing CPU work due to absence of compilation work on apps execution.
And finally it is a great reward to developers because most of developers are worried that odexed ROMs are faster than deodexed ROMs but they will deodex their ROMs since they heavily theme it. In case of ART whether the ROM is odexed or deodexed it doesn't matter, it compiles the full code into machine language on installation of apps. so even deodexed ROMs are as fast as odexed in ART
Click to expand...
Click to collapse
Some disadvantages of ART
Since ART precompiles apps on installation, it takes 10-20% more space upon installation than dalvik. But this can be simply solved by using apps like apps2sd/link2sd/gl2sd when your apps storage partition is full
One more is since it is only experimental feature now some apps are incompatible in ART which will be made compatible soon on their updates.
Click to expand...
Click to collapse
Here is the list of apps which are compatible and incompatible in ART.
http://www.androidruntime.com/list
Finally ART is one of the best feature that google brought up in android 4.4 (kitkat)
so, what if I get a rom like that which is on the nexus 6, and it has apks and odex files, how can you deodex these apks, there oviously odexed, because apks like maps are split compared to the deodexed apk, so are they not able to be odexed, or how can this be done
PradeepMurugan said:
What is ART?
Difference between Dalvik and ART
Now summing up all these Dalvik runtime does everything when the apps are executed. Now this is where we must discuss odexed and deodexed ROM. usually all stock ROMs released by OEMs are only odexed only due to this reason. odex means a part of the app is already compiled and it is written into dalvik VM(VM=Virtual Machine). and it runs at boot so while execution of apps JIT has to compile only the remaining part of the code when the apps is executed, this is why odexed ROM is faster than deodexed ROM.
But the disadvantage of odexed ROM is it cannot be edited/themed easily as a part of code is seperated in a separate file, and deodexing means the odex part of the file is put back into the apk/jar itself which makes editing/theming easy since the full code is packed inside a single file but it decreases speed because JIT has to compile full code when the app is executed
Here is the list of apps which are compatible and incompatible in ART.
http://www.androidruntime.com/list
Finally ART is one of the best feature that google brought up in android 4.4 (kitkat)
Click to expand...
Click to collapse
gigawatt said:
so, what if I get a rom like that which is on the nexus 6, and it has apks and odex files, how can you deodex these apks, there oviously odexed, because apks like maps are split compared to the deodexed apk, so are they not able to be odexed, or how can this be done
Click to expand...
Click to collapse
I would first ask you have you seen any such rom first? Mostly 5.0(Lollipop) ROM doesn't have odex files. I own a Nexus 7 2013 LTE version and I am using 5.0. Still now I have used many Lollipop ROMs but i haven't came across any odex files because In lollipop ART is the only Runtime unlike in 4.4. So There is no need of .odex files in lollipop.
P.S : Some claim that they have .odex files in lollipop rom But i haven't seen it. If i get to know it is true or not then we may get a clear conclusion
well, on the nexus 6 there is a folder for each app and inside is an apk file for the app, in some cases a lib folder with lib files inside and then an arm folder with a .odex file, so, either this is an odexed rom, or the files are there as place holders, but there rather large for place holders
PradeepMurugan said:
I would first ask you have you seen any such rom first? Mostly 5.0(Lollipop) ROM doesn't have odex files. I own a Nexus 7 2013 LTE version and I am using 5.0. Still now I have used many Lollipop ROMs but i haven't came across any odex files because In lollipop ART is the only Runtime unlike in 4.4. So There is no need of .odex files in lollipop.
P.S : Some claim that they have .odex files in lollipop rom But i haven't seen it. If i get to know it is true or not then we may get a clear conclusion
Click to expand...
Click to collapse
gigawatt said:
well, on the nexus 6 there is a folder for each app and inside is an apk file for the app, in some cases a lib folder with lib files inside and then an arm folder with a .odex file, so, either this is an odexed rom, or the files are there as place holders, but there rather large for place holders
Click to expand...
Click to collapse
well even I have lib folder and arm folder but there is no odex file inside them
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