Micromax Yureka: Indian Handset with CyanogenMod

Thesoap opera involving Cyanogen Inc., OnePlus, and Micromax is one of the most talked about … more

Chainfire Turns Your Bootanimation into a Logging Center

Having a nice boot animation certainly adds a little bit of aesthetic polish to your … more

Android TV Launcher Pushed to Google Play

Over the past decade, the tech universe has seen two drastic and widely contrasting changes with … more

Cyngn, OnePlus, Micromax – The Legal Battle

Recently, a battle has been waging in India over the rights to distribute the commercial … more

Welcome to XDA

Search to go directly to your device's forum

Register an account

Unlock full posting privileges

Ask a question

No registration required
Post Reply

Can't find BOOTCLASSPATH in "init.rc" file

OP Boostjunky

31st July 2014, 01:28 AM   |  #11  
OP Senior Member
Thanks Meter: 78
 
181 posts
Join Date:Joined: Jun 2010
I quickly threw together an odexing script that takes care of all the core files from the BOOTCLASSPATH first, then it odexes the remaining files in the framework folder.

Perhaps I'll have to sift through the script again and check that I didn't make any spelling errors.

Sent from my LG-D851 using Tapatalk
31st July 2014, 01:31 AM   |  #12  
OP Senior Member
Thanks Meter: 78
 
181 posts
Join Date:Joined: Jun 2010
Most color scheme theming is done via .png and .xml edits, which are not found in the classes.dex files, but rather, in the "res" archive of the apk.

Sent from my LG-D851 using Tapatalk
31st July 2014, 02:28 AM   |  #13  
OP Senior Member
Thanks Meter: 78
 
181 posts
Join Date:Joined: Jun 2010
The savings in space on the filesystem varies depending on the number of apps and whether the ROM is "Properly" odexed or not. If it's not properly odexed, the filesystem will end up even larger than a DeOdexed filesystem.

In a DeOdexed ROM, for every APK or JAR file, there is a classes.dex file within that APK/JAR archive. From this classes.dex file, the Dalvik Virtual Machine decompiles and stores an extracted/optimized classes.dex file known as the "dalvik-cache". So, in short, you end up with 2 dex files for every apk and jar package. 1 that is zipped into the apk/jar, and 1 that is extracted into the dalvik-cache directory.

In an Odexed ROM, for every APK or JAR file, there is a .odex file within the same folder that the APK/JAR is located. However the "classes.dex" file we spoke of earlier is no longer found inside a "properly" odexed apk or jar package. Where did it go? Well, it is the .odex file. It has simply just been pre-extracted, decompiled, and optimized for the system to use. And all without having to store it in the dalvik-cache directory. So, in short, you only end up with a single dex file (in this case, .odex) for each apk/jar package.

So, that's where you see the filesystem space savings.

The initial ROM size of an Odexed ROM is larger than a DeOdexed ROM (because the classes.dex files are zipped/compressed within the apk/jar package, whereas .odex files are not zipped/compressed).

But, after a DeOdexed ROM has initially booted up (I'm sure you've seen the message upon boot-up after clearing dalvik-cache that says "Android is upgrading x of xxx files), the resulting filesystem size is quite a bit larger since it now essentially has 2 copies of each classes.dex file from each apk/jar package (one compressed, the other decompressed).

Now, I said something about a "properly" odexed ROM. There are instances where a person will Odex their ROM, but won't pull the classes.dex file out of the apk/jar package after it's been odexed. This results in each apk/jar file potentially having 3 copies of the classes.dex file. 1 located within the apk/jar package (compressed), 1 located in the same folder as the apk/jar package (decompressed .odex file), and 1 in the dalvik-cache directory (again, decompressed as a classes.dex file).

Whew. That was a long explanation, but hopefully it gets the point across.

One thing I'm curious about is if ART will work with a "properly" Odexed filesystem. The reason I question it is because LG's filesystem would NOT be considered "properly" odexed since each apk/jar package has not only a .odex file, but also has a classes.dex file located within the package. So I have to wonder if ART uses the classes.dex file much like the Dalvik Virtual Machine, and that it won't convert a .odex file to an .oat file.
31st July 2014, 05:52 AM   |  #14  
OP Senior Member
Thanks Meter: 78
 
181 posts
Join Date:Joined: Jun 2010
Just to update:

I found the issue via pulling a logcat during boot-up (or bootloop, rather). The issue was that I had attempted to Odex the framework file "com.qcom.bluetooth.jar" which just happens to NOT have a classes.dex file inside of it. Even though it didn't have a classes.dex file, the script still generated a false .odex file for that package, and thus during boot-up, the phone was not digging the file that made no sense.

Got her all Odexed in the framework, and am just about finished with odexing the /system/app/ and /system/priv-app/ apks. So far, so good.

I'll see if I can't get a filesystem size comparison after I'm finished with everything.
31st July 2014, 03:04 PM   |  #15  
OP Senior Member
Thanks Meter: 78
 
181 posts
Join Date:Joined: Jun 2010
Results are in. The amount of space saved by Odexing the ROM I'm using ended up being 103.53 MB. Not as much as I imagined it would cut down (keep in mind, all the space savings is in the /data partition. The /system partition ends up using more space than the deodexed version of the ROM).

The sizes look like this.

Deodexed system size: 1.34 GB
Deodexed data size: 1.83 GB

Odexed system size: 1.53 GB
Odexed data size: 1.55 GB

Edit: I also tried enabling ART, and, as I expected, it doesn't work.
Last edited by Boostjunky; 31st July 2014 at 04:15 PM.
Post Reply Subscribe to Thread
Previous Thread Next Thread
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes