Attend XDA's Second Annual Developer Conference, XDA:DevCon 2014!
5,812,702 Members 45,522 Now Online
XDA Developers Android and Mobile Development Forum

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

Tip us?
 
Boostjunky
Old
#11  
Senior Member - OP
Thanks Meter 66
Posts: 155
Join Date: 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
 
Boostjunky
Old
#12  
Senior Member - OP
Thanks Meter 66
Posts: 155
Join Date: 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
 
Boostjunky
Old
#13  
Senior Member - OP
Thanks Meter 66
Posts: 155
Join Date: 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.
 
Boostjunky
Old
#14  
Senior Member - OP
Thanks Meter 66
Posts: 155
Join Date: 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.
 
Boostjunky
Old
(Last edited by Boostjunky; 31st July 2014 at 03:15 PM.)
#15  
Senior Member - OP
Thanks Meter 66
Posts: 155
Join Date: 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.
Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Sony PS4 Remote Play Ported to All Android Devices

Im pretty sure that every informed gamer out there perked their ears up when Sony came out … more

Change Your Samsung Galaxy S2’s Dialer Background in Real Time

As with anything, if youve looked at something long enough, things can … more

Increase Your Multitasking Workflow with C-Floating Windows

Technology has put life on the fast track. Lazy, relaxed days have turned into … more

Compile Your Own Kernel From Source with Comprehensive Tutorial

One glance at any developer section of any device forum on XDA and youll find … more