Related
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.
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
Hi,
I decided to try to make a modification of an existing ROM which would suit me better right after flashing. Nothing large, only adding some apps and stuff. But Ive got a couple of questions:
1) Ive read some apps cant run from /system partition. Looks like that (at least) one of mine is one of them - it FCs when in /system/apps or /system/priv-apps. Is there any workaround to make this work? I dont want to lose it when doing factory reset (or to flash the ROM again after every factory reset).
2) I wanted to add langunages (http://forum.xda-developers.com/showthread.php?t=2602704) but according to forums those files are odexed. How could I deodex them to make them run on an deodexed ROM?
3) I want to include the faux kernel but Im not sure if simply copying those files into the ROM would do ... in the other cases it went ok but Im not sure about the kernel - Im afraid I could break something.
4) Can I also use the ROM file to store other files? I mean - if I put files into the ROM in /data/media/0/ would it simply appear in my home directory or could this break anything - by which I mean to destroy my existing files?
Thanks for any leads!
michalurban said:
Hi,
I decided to try to make a modification of an existing ROM which would suit me better right after flashing. Nothing large, only adding some apps and stuff. But Ive got a couple of questions:
1) Ive read some apps cant run from /system partition. Looks like that (at least) one of mine is one of them - it FCs when in /system/apps or /system/priv-apps. Is there any workaround to make this work? I dont want to lose it when doing factory reset (or to flash the ROM again after every factory reset).
2) I wanted to add langunages (http://forum.xda-developers.com/showthread.php?t=2602704) but according to forums those files are odexed. How could I deodex them to make them run on an deodexed ROM?
3) I want to include the faux kernel but Im not sure if simply copying those files into the ROM would do ... in the other cases it went ok but Im not sure about the kernel - Im afraid I could break something.
4) Can I also use the ROM file to store other files? I mean - if I put files into the ROM in /data/media/0/ would it simply appear in my home directory or could this break anything - by which I mean to destroy my existing files?
Thanks for any leads!
Click to expand...
Click to collapse
1) What is the app? on system/app they should work fine since kitkat update, i think
2) To deodex i used a kitchen i got out of foro nexus (cant get the link atm) that only worked on linux. If you want to translate things in your rom, i think it can be done without deodexing, im not sure.
3) Copy paste should work fine but if you take a look at faux's meta inf, see what's there, merge it with your rom's meta inf. But it should work with cp
4) You can use the meta inf to link files to storage like your sdcard, yes. However, if you try to put a wallpaper somewhere inside the rom it wont show up
anerik said:
1) What is the app? on system/app they should work fine since kitkat update, i think
2) To deodex i used a kitchen i got out of foro nexus (cant get the link atm) that only worked on linux. If you want to translate things in your rom, i think it can be done without deodexing, im not sure.
3) Copy paste should work fine but if you take a look at faux's meta inf, see what's there, merge it with your rom's meta inf. But it should work with cp
4) You can use the meta inf to link files to storage like your sdcard, yes. However, if you try to put a wallpaper somewhere inside the rom it wont show up
Click to expand...
Click to collapse
Thanks very much for your reply! Now:
1) The app is a game, Traffic Racer. When I flash a ROM where this app has been put in /data/app it runs fine. In /system/app or /system/priv-app it FCs. As you say it should work Ill try to do it again - but I tried it twice in /system/priv-app and once in /system/app already so I dont believe it would work. BTW I use APKs from update.zip created by TiBa if it could be relevant.
2) Linux is not a problem so Ill try to find the link here.
3) Ill try only to copy the files first before messing with meta files.
4) I only want to store some apps config backup files (for Apex launcher and Agenda widget mainly).
michalurban said:
Thanks very much for your reply! Now:
1) The app is a game, Traffic Racer. When I flash a ROM where this app has been put in /data/app it runs fine. In /system/app or /system/priv-app it FCs. As you say it should work Ill try to do it again - but I tried it twice in /system/priv-app and once in /system/app already so I dont believe it would work. BTW I use APKs from update.zip created by TiBa if it could be relevant.
2) Linux is not a problem so Ill try to find the link here.
3) Ill try only to copy the files first before messing with meta files.
4) I only want to store some apps config backup files (for Apex launcher and Agenda widget mainly).
Click to expand...
Click to collapse
Oh, games could cause issues, yes. Better leave it on data app. Messing with meta inf is totally easier than it sounds anyways and could help fixing any possible bugs, you gotta try it. Backup files i dont think they'll work on the rom but you can store them into storage/emulated/legacy which is the storage, though you could do this any other easier way
anerik said:
Oh, games could cause issues, yes. Better leave it on data app. Messing with meta inf is totally easier than it sounds anyways and could help fixing any possible bugs, you gotta try it. Backup files i dont think they'll work on the rom but you can store them into storage/emulated/legacy which is the storage, though you could do this any other easier way
Click to expand...
Click to collapse
Thanks again! Ive got one more question about including the faux kernel. The updater-script is supposed to run this command during the installation in CWM:
Code:
package_extract_file("boot.img", "/dev/block/platform/msm_sdcc.1/by-name/boot");
... which I dont know how to implement. If I would only copy all files it would overwrite the original boot.img (Kitkat+ 1.1 original anyway) - which im not sure is the same. So Im not sure if it wont screw something up ...
Or is this extraction the same as copying it? Does the "/dev/block/platform/msm_sdcc.1/by-name/boot" just mean - "its a block device on first SD, partition name boot"?
michalurban said:
Thanks again! Ive got one more question about including the faux kernel. The updater-script is supposed to run this command during the installation in CWM:
Code:
package_extract_file("boot.img", "/dev/block/platform/msm_sdcc.1/by-name/boot");
... which I dont know how to implement. If I would only copy all files it would overwrite the original boot.img (Kitkat+ 1.1 original anyway) - which im not sure is the same. So Im not sure if it wont screw something up ...
Or is this extraction the same as copying it? Does the "/dev/block/platform/msm_sdcc.1/by-name/boot" just mean - "its a block device on first SD, partition name boot"?
Click to expand...
Click to collapse
Put faux's boot.img on the rom first, then on updater script go to the line that refers to extracting boot.img (should be like the last one) and replace that with the command on faux's updater script. That means it will extract it in that directory, nothing else. Be sure to copy modules aswell and set the perms
Q&A threads should be created in the Q&A forum... not the Development forum.
Thread moved.
One more question - is there a special way how to pack the ZIP file? Cause I unpacked a ROM, added some apks, packed it but it didnt work (no error, just ended at "opening rom" or what the CWM message is) ... but when I modified existing ZIP it went fine ...
Hi there
I've got a quick question: Right now I'm using Franco's Kernel with the stock 4.4.2 ROM. I also want to test experimentalX (i heard it's a tad snappier). Is it correct that instead of flashing from Franco directly to experimentalX, I install the stock kernel again with TWRP. After that i can flash to experimentalX.
I also use Xposed with a few modules. Is that going to be a problem?
Cheers!
2mnyshp said:
Hi there
I've got a quick question: Right now I'm using Franco's Kernel with the stock 4.4.2 ROM. I also want to test experimentalX (i heard it's a tad snappier). Is it correct that instead of flashing from Franco directly to experimentalX, I install the stock kernel again with TWRP. After that i can flash to experimentalX.
I also use Xposed with a few modules. Is that going to be a problem?
Cheers!
Click to expand...
Click to collapse
Yes You can directly flash experimental X from FRANCO kernel ...
Try yourself and tell us whether it gives a problem or not ?!!! :sly:
Sent from my Nexus 5 using Tapatalk
ok thanks! I'll try it this evening
rahil3108 said:
Yes You can directly flash experimental X from FRANCO kernel ...
Try yourself and tell us whether it gives a problem or not ?!!! :sly:
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
2mnyshp said:
Hi there
I've got a quick question: Right now I'm using Franco's Kernel with the stock 4.4.2 ROM. I also want to test experimentalX (i heard it's a tad snappier). Is it correct that instead of flashing from Franco directly to experimentalX, I install the stock kernel again with TWRP. After that i can flash to experimentalX.
I also use Xposed with a few modules. Is that going to be a problem?
Cheers!
Click to expand...
Click to collapse
You can be sure about flashing the stock boot.img first simply looking at the zip of your already installed kernel.. If the zip includes boot.img file you should flash the stock boot.img first, then your new custom kernel.
if the zip just includes kernel.img then you can flash your custom kernel over it safely.
Xposed isn't related to the kernel flashing, it won't cause any issue
Inviato dal mio Nexus 5 utilizzando Tapatalk
Hi,
Have you read the OP of ElementalX kernel?
NOTE: If you have been using a different custom kernel, please reflash your ROM without wiping data prior to installing this kernel. This will ensure you have all the necessary system files and that customizations from other kernels do not interfere.
Click to expand...
Click to collapse
With Francisco's kernel some system files are modified so better is to dirty flash your rom or at least the stock kernel before...
Just in case for the stock kernel: http://forum.xda-developers.com/showthread.php?t=2518816.
EDIT: too late...
OK, that's the way I would've done it; I put the stock kernal zip on my phone, flash that with TWRP and after that flash ElementalX. I'm not sure about the dirty stock rom flash: Can i just extract the system.img from the official android hammerhead download, put the img on my phone and flash that over my current rom?
Sorry for these trivial questions but the answers to such topics in other threads are sometimes a bit unclear.
Re,
If you have already flashed the stock kernel (so the boot.img) it should be enough... But Francisco's kernel rename some system files like /system/lib/hw/power.msm8974.so or /system/bin/thermal-engine-hh so with a dirty flash of your current rom all the files are replaced (and you won't loose anything, just wipe Dalvik cache and cache partition, just in case then reflash your rom).
Check if the files I mentioned don't have a .bak extension (with a file explorer follow the path above), if not all is fine. If yes, and if you are convenient, delete the .bak extension by yourself.
If you are not convenient with this (I mean delete some extension in system files), dirty flash your rom, reboot (as always just in case, to be sure, etc...), flash your new kernel... And you're good to go!
viking37 said:
Re,
If you have already flashed the stock kernel (so the boot.img) it should be enough... But Francisco's kernel rename some system files like /system/lib/hw/power.msm8974.so or /system/bin/thermal-engine-hh so with a dirty flash of your current rom all the files are replaced (and you won't loose anything, just wipe Dalvik cache and cache partition, just in case then reflash your rom).
Check if the files I mentioned don't have a .bak extension (with a file explorer follow the path above), if not all is fine. If yes, and if you are convenient, delete the .bak extension by yourself.
If you are not convenient with this (I mean delete some extension in system files), dirty flash your rom, reboot (as always just in case, to be sure, etc...), flash your new kernel... And you're good to go!
Click to expand...
Click to collapse
Thanks! And for the dirty flash i can use the System.img which i extracted with TWRP after i cleaned the dalvic cache, right?
2mnyshp said:
Thanks! And for the dirty flash i can use the System.img which i extracted with TWRP after i cleaned the dalvic cache, right?
Click to expand...
Click to collapse
Re
I don't understand what you mean here, you are on full stock rom? You have not flashed a rom from a zip file?
viking37 said:
Re,
If you have already flashed the stock kernel (so the boot.img) it should be enough... But Francisco's kernel rename some system files like /system/lib/hw/power.msm8974.so or /system/bin/thermal-engine-hh so with a dirty flash of your current rom all the files are replaced (and you won't loose anything, just wipe Dalvik cache and cache partition, just in case then reflash your rom).
Check if the files I mentioned don't have a .bak extension (with a file explorer follow the path above), if not all is fine. If yes, and if you are convenient, delete the .bak extension by yourself.
If you are not convenient with this (I mean delete some extension in system files), dirty flash your rom, reboot (as always just in case, to be sure, etc...), flash your new kernel... And you're good to go!
Click to expand...
Click to collapse
viking37 said:
Re
I don't understand what you mean, you are on full stock rom? You have not flashed a rom from a zip file?
Click to expand...
Click to collapse
yes, stock 4.4.2 only with a custom kernel (franco's as of now)
Yes, or at least just take a look at the files I mentioned following the path with a file explorer to see is there is still not the .bak extension. And after flashed ElemantalX kernel, obviously.
As far as I know it should be the only modified system files, I mean renamed since in Francisco's kernel they are not used, that "could" caused issues...