?
Sent from my X8 using XDA App
It improves performance by increasing phone booting speed and app startup speed.
Hit the THANKS button if I helped!!
Sent from my W8 using Tapatalk
http://www.addictivetips.com/mobile/what-is-odex-and-deodex-in-android-complete-guide/
It improves performance by increasing phone boot-up speed and app start-up speed.
Hit the THANKS button if I helped!!
It also increases the phone memory so that u can install more apps to ur phone memory...
Press THANKS if I tried to help...
It can be use for stock...
Sent from my E16i using xda premium
lucastan96 said:
It improves performance by increasing phone booting speed and app startup speed.
Hit the THANKS button if I helped!!
Sent from my W8 using Tapatalk
Click to expand...
Click to collapse
oh ty
optimusprime1 said:
It improves performance by increasing phone boot-up speed and app start-up speed.
Hit the THANKS button if I helped!!
Click to expand...
Click to collapse
!
Oh God, nobody actual provides a proper explanation these days. Ok kiddies, sit down and listen.
Odex'd ROMs are usually stock, unless a ROM developer makes them that way. Basically, APK files normally have separate associated files with a .odex extension that help increase performance and lower boot time. How? Well a .odex file is part of the dalvik cache and helps the system expect which apps are installed and going to run. It's loaded into the RAM at boot time, and every APK has one. The downside is that because it's loaded into RAM and it's not part of the APK itself, it becomes extremely difficult (near impossible) to modify an APK. Normally the APKs we mod have to do with system themeing but there are other types of APKs we modify.
It's kind of like knowing the bouncer at a nightclub ahead of time, and being able to skip the line and get in quicker. Problem is, if you tell your friend to go to that nightclub, the bouncer doesn't know your friend and he can't get in (you modify an APK, but the .odex file is still associated with the original version of the APK).
Deodex'd files solve that issue by putting the .odex files back inside of the APK in the form of a file called classes.dex. Why does this help? Well, it makes modifying APKs a whole lot easier since everything is in one neat little package, and the .dex file will be loaded into the same general area in memory as the rest of the files in the APK. The downside is that at first boot the system may be slow since the cache has to be regenerated all over again.
It's like getting friendly with a bouncer at a night club, but then the nightclub changes bouncers (you wipe the dalvik cache) and you have to get friendly with the new one all over again so you're able to skip the lines (you have to rebuild the dalvik cache the first boot after you wipe so that you can boot quickly after that).
--------------------
If you don't want to modify a ROM or you modify it and that's 100% how you want it from now on, then it's OK to odex it. It's kind of like "finalizing" it. It'll boot and probably perform a little quicker, but you can't mod it anymore until it's deodexed. If you constantly flash mods for ROMs, you'll want to stick with a deodex'd ROM. 99% of the time, ROMs come deodex'd. Stock OEM/Carrier ROMs are usually odexed.
Thanks for explaining...i got it...nice
Sent from my E16i using xda premium
Related
Hello,
I was wondering, what are the advantages of deodexing, aside from theming?
I've done some tests with my everyday stock ROM and found an odex ROM was faster. I understand that odex files are basically classes.dex, but specifically made for my platform, Android version and is not compressed, thus accelerating the start times.
I went as far as pushing the system apps updates in /system directly (by hand, I can tell you it gets old fast). But I still had low memory in /data. Then I remembered, automatic odex files are stored in dalvik-cache, and thus, when Maps, which has a very big odex file or so, first starts, even if it's on /system, you end up still needing space in /data to start.
So I searched how I could hand-do these odex files, and came across dexopt-wrapper. I loaded it up on my phone, and started odexing all these system apps that used to be odexed.
All in all, you lose room in /system (because odex+apk is slightly larger than the apk, but you're not supposed to have /system writable anyway), or you lose valuable space in /data, where you could put all your apps.
Basically:
I backed up my stuff with Titanium (after cleaning the cache). I was on Geo411m's ROM. I had around 25MB left on my phone.
I then reflashed FRG33 from the PASSIMG.zip
then updated with the FRG83D OTA (straight from Google, not through update.zip)
I updated all system apps through the Market
I used rageagainstthecage to shell root, to read the system and data partitions
I used dexopt-wrapper to create odex files for all the updated apks I had
I pushed everything in /system
Finally, I restarted. Before this, I booted Amon-RA's recovery to clear all the user data
I rooted (permanently this time), restored all my apps through Titanium Backup. I had 65 MB left. That's a 40 MB difference, just by odexing.
So now I wonder, knowing I don't plan on theming, is deodexing useful outside of this, and should I give up some space for something that eluded me?
Sorry for the lonnnnnng post
Thanks!
I'm not aware of any benefit of deodexeding, other than theming.
i've heard people say there is definitely a performance difference between the two, but i really dont know from personal experience. it probably doesnt matter for general usage...
I believe you're right, deodex takes up more of your internal space, which to me is a problem
Sent from my Nexus One using XDA App
When I first flash a new rom from recovery the odex rom will start faster,but I cant feel any difference between odex and deodex rom on speed when my defy is on.
Aside from the first load, deodexed system runs at the same speed as odexed, or with negligible differences (not 100% sure if system-odexed files that are created in Dalvik-cache are the same as .odex that are in the apks).
The disadvantage of deodexed system is extra size of Dalvik-cache. While it can be quite a difference for those using N1's tiny internal space w/o any sort of A2SD solution, it's negligible for those running A2SD or on phones with proper internal memory size.
The advantage of deodexed system is being able to modify the apps themselves, and the framework. In addition to theming, it allows for different kinds of modifications - like trackball wake, or RTL (Hebrew/Arabic) framework patching.
Quite an old thread you managed to dig...
kingdragonfly said:
When I first flash a new rom from recovery the odex rom will start faster,but I cant feel any difference between odex and deodex rom on speed when my defy is on.
Click to expand...
Click to collapse
Way to bump a 1.5 years old thread, lol.
Theshawty said:
Way to bump a 1.5 years old thread, lol.
Click to expand...
Click to collapse
maybe because you all people tell noobs to serch and don't ask. and when i find 4 years old thread is still very usefull
Sent from my Nexus 5 using Tapatalk
magik300 said:
maybe because you all people tell noobs to serch and don't ask. and when i find 4 years old thread is still very usefull
Sent from my Nexus 5 using Tapatalk
Click to expand...
Click to collapse
You felt it was worth a two year bump just to convey that? Oh, ok.
Sent from my HTC One using Tapatalk
I don't know about a 2 year bump, but a 1 year bump to agree that this is a nice simple thread that is exactly what it says on the tin.
Lol
Lol
Is there any good resource I can be pointed to learn about the difference between Odex/Deodex?
nice info from this thread, thanks!
Hi
I would like to start automatically my Htc n1 when i put in the charger.
There are some methods on the internet,for some other phones.
Can someone tell me wich and how the folder i must modify?
My phone doesn't start when it's plugged in and take the battery out and put it back(i dont know why).
Sorry to write to you here, but I see you are very good at what you do.
I thought you could help me.
Thanks
This is not only my first Android app, but this is also my first dive in Java. Please be gentle as I expect there are several uncaught / improperly handled exceptions.
This app will backup selected files to a zip file that can be restored via cwm. For now, that is all it does. It can be handy for the oc/uv crowd since it will allow you to keep a backup of a good S_volt_scheduler init file to flash in case your new setting are too aggressive. It does not currently restore permissions, nor does it assume root permissions.
todo:
Obtain root to copy any file
Integrate a file selector so read permissions will not be an issue.
Detect/Restore permissions
Possible feature additions:
Create a restore.zip from current files based on an update.zip you want to apply. Could save you from boot loops when messing with system files.
Create a restore.zip given a file, a target directory, and permissions.
I will probably add this to the market once I get through the todos and initial bugs.
Changelog:
20110303
Multi-file capable. OIFileManager does not yet support multi-select, so each file must be selected seperately
Exception caught for mission OIFileManager
_delete.zip file seems to work correctly in recovery
Since I am not yet using root and OIFileManager will not assume root, there are some directories that cannot be viewed, /data/app for example. There are also some files that can be selected but cannot be copied due to their permissions.
Requires OIFileManager
Nice, will be useful
This looks like it could be a useful/powerful app. It could definitely benefit from some features (more than one file/location would be great) but I can see myself using this.
Thanks!
gibson3659 said:
This is not only my first Android app, but this is also my first dive in Java. Please be gentle as I expect there are several uncaught / improperly handled exceptions.
This app will backup 1 file to a zip file that can be restored via cwm. For now, that is all it does. It can be handy for the oc/uv crowd since it will allow you to keep a backup of a good S_volt_scheduler init file to flash in case your new setting are too aggressive. It does not currently restore permissions, so the uses are currently limited.
todo:
Figure out why the _delete.zip does not delete the target file when run via cwm.
Detect/Restore permissions
Possible feature additions:
Enable backup/restore of multiple files
Create a restore.zip from current files based on an update.zip you want to apply. Could save you from boot loops when messing with system files.
Create a restore.zip given a file, a target directory, and permissions.
I will probably add this to the market once I get through the todos and initial bugs.
Requires oifilemanager.
Click to expand...
Click to collapse
Can u load the java app here? I can try to look into that and see if I can improve on the exception handling part.
fantastic idea
good job
Thanks for taking a look. Have anyone of you actually tried it?
It fc. On me... :'(
Sent from my SGH-I897 using XDA App
Do you have oifilemanager?
Sent from my SGH-I897 using XDA App
gibson3659 said:
Do you have oifilemanager?
Sent from my SGH-I897 using XDA App
Click to expand...
Click to collapse
Forgot that
Sent from my SGH-I897 using XDA App
Works like a charm! thank you so much! Perfect cause I love the stock music player and not all rims have it so this is great for installing it!
Sent from my SGH-I897 using XDA App
I am working on multiple file support, so look for a new version in a day or two.
Sent from my SGH-I897 using XDA App
just installed it, however it force closes as soon as I try to choose a source or destination file (happens as soon as I press the buttons.
Herp derp Captivate XDA app.
Make sure you install OIFilemanager from the market. I need to catch this exception and provide a link to OIFileManager.
Great App
Want to say thank you for making this. I've had all sorts of trouble getting apps from different roms to install to the system folder on my current rom. Now I can mix and match different apps easily without much pain. Thanks!
bpurkapi said:
Want to say thank you for making this. I've had all sorts of trouble getting apps from different roms to install to the system folder on my current rom. Now I can mix and match different apps easily without much pain. Thanks!
Click to expand...
Click to collapse
You are welcome. I actually have another app in mind to fully address that need, but I want to get further along with this one first. Since I am working on these on stolen time (I don't have any free time), it will take a while.
Since the apps seem to restore without permission issues, I may put that on the back burner. After I complete multi-file support, which of the future features from the op would you like to see first.
gibson3659 said:
Make sure you install OIFilemanager from the market. I need to catch this exception and provide a link to OIFileManager.
Click to expand...
Click to collapse
And I need to learn how to read through a thread for answers to my problems before I post about them.
New Version
Changelog:
20110303
Multi-file capable. OIFileManager does not yet support multi-select, so each file must be selected seperately
Exception caught for mission OIFileManager
_delete.zip file seems to work correctly in recovery
Since I am not yet using root and OIFileManager will not assume root, there are some directories that cannot be viewed, /data/app for example. There are also some files that can be selected but cannot be copied due to their permissions.
Can I get a gauge on the interest level for this app? Should I move this to the I9000 forum?
I think it's really useful when working whit OC/UV.
gibson3659 said:
Can I get a gauge on the interest level for this app? Should I move this to the I9000 forum?
Click to expand...
Click to collapse
I think you should get with rom devs, this should become an integrated feature for all rom upgrades, regardless of phone
at least get with the AIO dev, if you arent already
First thanks to kamma and his thread HERE. This fixed was 100% inspired by his attempt, i only had the benefit of having access to some files he didnt. This thread is based off his, but with the files from 2.3.3 which did not have the jumping issue.
I have NOT tested extensively, but in my limited experience(and that of a few others) this does fix the problem.
Code:
[color=#FF0000]USE THIS SCRIPT AT YOUR OWN RISK[/color]
This is just a proof-of-concept fix. I dont guarantee any improvement, because i have not much time to test it.
I simply replace battery libs and apps extracted from [color=#FF0000]ATT 2.2.3*[/color].
How to:
1. Download [color=#FF0000]CMW_Jug6_batfix.zip*[/color] (bellow in Attached Files)
2. Copy it to sdcard or sdcard-ext
3. Reboot into CWM recovery
5. Click "install zip from sdcard"
6. Choose zip from sdcard
7. Pick the [color=#FF0000]CMW_Jug6_batfix.zip*[/color]
8. Install
9. Reboot
V2 - Removed BatteryManager.apk & BatteryReport.apk as they are not needed
Gonna flash this now and reboot frenzy!
Brilliant, will try immediately! Does it matter if you switch between roms, do you have to re-apply then?
Will test, thanks Jug.
Guess I would need to deodex it for a deodexrom?
Vangelis13 said:
Brilliant, will try immediately! Does it matter if you switch between roms, do you have to re-apply then?
Click to expand...
Click to collapse
Yes as you go between roms you would need to reapply, that is until(if its working 100%) its added to the roms themeselves.
Ronaldo_9 said:
Will test, thanks Jug.
Guess I would need to deodex it for a deodexrom?
Click to expand...
Click to collapse
it has both, but if you want u can remove the 2 .odex files from the zip.
Its not as easy as just removing the odex files.... lol... it has to be actually "deodexed" there is a difference. I will do this if you don't know how...
jug6ernaut said:
Yes as you go between roms you would need to reapply, that is until(if its working 100%) its added to the roms themeselves.
it has both, but if you want u can remove the 2 .odex files from the zip.
Click to expand...
Click to collapse
Sent from my Cyanbreaded Gingered Atrix!
installing now....will report tomorow
sublimejosh2000 said:
Its not as easy as just removing the odex files.... lol... it has to be actually "deodexed" there is a difference. I will do this if you don't know how...
Sent from my Cyanbreaded Gingered Atrix!
Click to expand...
Click to collapse
I recommend this.
Sent from my MB860 using XDA App
Installed at 85% battery life, was thinking it was actually closer to 95% at the time I ran this as I hadn't done much since it was fully charged. Didn't wipe battery stats or anything, it started back up at 84%. Did a few things to see how quickly it would drop, when it came down to 81%, I rebooted and wiped battery stats and davlk cache. Took a while on reboot after those wipes, started up at 80%. Still think it should have been higher than the 85% it started at, so I'm charging up to 100% and running Battery Calibration app. Will edit this post when I get the results, but it's not bouncing around like it was before. Awesome work Jug6!
Edit: Charged it to full charge, wouldn't charge past 98%, so I ran the battery calibration app, restarted, and on restart is said 99% and full charged. It was recommended in the app to fully discharge battery and then fully recharge without interruption. Will try to drain it quickly -> Pandora!
sublimejosh2000 said:
Its not as easy as just removing the odex files.... lol... it has to be actually "deodexed" there is a difference. I will do this if you don't know how...
Sent from my Cyanbreaded Gingered Atrix!
Click to expand...
Click to collapse
I would appreciate it, I won't b able to until around 4cst. Granted I'm running this on an deobexed rom.
/me admits his knowledge of compatibility between deobexed/obexed is very lacking lol
Sent from my MB860 using Tapatalk
Will try it out if enough people give good feedback, lol.
Deodexing... From what I understand so far
jug6ernaut said:
I would appreciate it, I won't b able to until around 4cst. Granted I'm running this on an deobexed rom.
/me admits his knowledge of compatibility between deobexed/obexed is very lacking lol
Sent from my MB860 using Tapatalk
Click to expand...
Click to collapse
I think I would need some of the 2.3.3 framework to do it though..
Basically,
Each .apk has a "classes.dex" file in it.. when a .apk or .jar for that matter has an .odex file associated with it. whish is the case with the Atrix and other phones too... what has happened is that the "Classes.dex" file has been taken out of the .apk/.jar file and placed in a .odex form. this way it is device spacific and cannot be moddified or replaced using generic .apk/.jar files .. i.e. customized ...
he reason it is "working" for you, is because your phone is the spacific device these files were made for... so it isn't crapping out. At least, i think this is the reason...
In order to run a deodex on these file though, I would need some of the reference files that they are dependant on in order to run the script to do so. hat is the "Boot class file paths" that you see below...
I am glad to see these are seeming to fix the problem though. I will see what I can do, but I am getting errors running the script:
Code:
D:\Atrix\Baksmali>java -jar baksmali-1.2.6.jar -x Ba
Error occured while loading boot class path files. A
org.jf.dexlib.Util.ExceptionWithContext: Cannot loca
.odex
at org.jf.dexlib.Code.Analysis.ClassPath.loa
a:237)
at org.jf.dexlib.Code.Analysis.ClassPath.ini
5)
at org.jf.dexlib.Code.Analysis.ClassPath.Ini
ssPath.java:110)
at org.jf.baksmali.baksmali.disassembleDexFi
at org.jf.baksmali.main.main(main.java:278)
ok tried this out on kens gb rom, started at 96, played a game got it down to 93, rebooted into cwm, wiped dav and batt stats, rebooted, was still at 93. so im letting it get down to 85 or so and see if it keeps. this may be the fix for this. i thank you so much for it working this good jug, and hope it is implemented soon.
i just have one thing to say to jug::
: " ooooh ITS THE JUGGANAUT *****"
i have cherry 0.5b, i go in recovery with 83%, i flash this zip, no wipecache no wipe stats no wipe and when i reboot i have 83%, it's work well, and it work with deodex
I just did the following
- Phone was at 70%, restarted
- Phone then read 90%
- Installed this
- Phone still reads 90%, I will restart at lunch time in a few hours to see if it jumps at all
I am running Kenneth's stock 2.3.4 ROM
Thanks!
ok phone at 87, rebooting.....
edit: phone still at 87, YAY!!!!!!!!
Was at 73 before and after reboot, seems to be fixed so far...
Did the following:
-phone was showing 96% (about 3 hours ago)
-installed this (didn't wipe dalvik cache or battery stats)
-restarted and was showing 96%
-been using the phone for the last Hour
-phone showed 76%
-restarted
-phone is still showing 76%
Great finally with have a working solution
PS:why should I wipe dalvik cache?
Enviado desde mi MB860 usando XDA Premium App
Thanks just flashed this. Battery reads the same after reboot. Hopefully it will keep on working.
Sent from my Motorola Atrix 4g
This seems to be working for me. Battery level persisted through multiple reboots. Flashed over Ken's 4.5 beta.
So I've tried flashing a couple of the kernels around that everyone else seems to have no problem with. I just flash the regular way using TWRP bu then after it boots, about 15 seconds after sense loads, it reboots. And it'll just loop like this. Any ideas how I could fix this?
Wipe cache/dalvik
Sent from my HTCONE using xda app-developers app
Thanks for the response. I've tried that a few times to no avail unfortunately.
How about a full wipe>flash rom>wipe dalvik/cache>flash kernel
Sent from my HTCONE using xda app-developers app
TheLeapist said:
Thanks for the response. I've tried that a few times to no avail unfortunately.
Click to expand...
Click to collapse
Most kernels nowadays have mpdecision/thermal support in them. If the kernel that you're flashing has this support, you need to delete/rename these files from your system/bin directory BEFORE flashing. I use ES File Explorer, but any root file manager should do the trick. Leaving these files in the system AND flashing a kernel that has them can cause unusual behavior/reboots. You can also check if your rom has init.d support.......this is a folder in your system/etc directory. It contains scripts that run after boot and sets various parameters for controlling different aspects of your phone. The cpu min/max clock speed and sd card read ahead are two of the most common ones. If that folder is there, check for any scripts that set values for your cpu and rename them with a .bak extension. Also, make sure you don't have any cpu tweaking apps installed that could conflict with each other........such as Kernel Tuner and SetCpu. Make sure you check for ALL of these possible issues prior to flashing. Of course there could be other things causing reboots, but the above mentioned steps will most likely solve them for you. (especially if other user's are not reporting any reboots) Hope you get to the bottom of this and can start enjoying your new toy.
>>If you're unsure about any scripts in the init.d folder, just make a copy of it and upload here. I would be happy to help you out.
I recently bought a Galaxy Mini 2, and the first thing I wanted to do was modding it!
But I couldn't do it on an odexed ROM, currently available ROMs are only the 4.x builds by TheWhisp and some tweaked ones I don't like, and xUltimate throws errors.
Also, the stock ROM contains 100+ packages to deodex, so I couldn't do it by hand quickly.
I wrote this script to do it for me. I'm not really experienced, and I don't know how far this can be from being optimized, clean and readable, but it works, and it should work for any device and ROM if used correctly.
This script deodexes all the apk and jar packages for system apps and framework, then zipaligns them for better memory optimization (memory consumption is a half of what's normally used on stock ROM). After that, it writes an updater-script and packages everything in a shiny flashable zip to use in recovery.
WARNING: Might cause boot-loops or force-closes. It's recommended to check that the cwm_deodex.zip file contains the .apk and .jar files and pick some random APKs and JARs to check that they contain the classes.dex file in their root. The APKs from framework should not contain the classes.dex, while the JARs should. It's also recommended to do a backup before flashing the deodex package, in case the cwm_restore.zip fails.
HOW TO USE:
Extract the attached zip wherever you want.
Pull all the files from /system/app and /system/framework from your phone and put them respectively in the directories"app_odexed", and "framework_odexed" (they're located under the extracted directory).
Check the API level for your device's Android version (if you don't know, check this). In deodex_app.sh and deodex_framework.sh there are four lines (two in deodex_app.sh and two in deodex_framework.sh) which begin in "java -jar baksmali.jar" and "java -jar smali.jar". Those lines contain an option "-a", followed by a number (by default "10"): you should change that number to your API level. If you are on ICS or later, you can just delete the "-a" option and the consecutive number.
Open a terminal in the directory where the deodex.sh file is and type "./deodex.sh", then you can have a coffee (or more, depending on how many files to deodex are there).
When you come back, you should find the cwm_deodex.zip waiting to be pushed to your device and flashed, and a cwm_restore.zip to flash if you need to restore the previous odexed files.
Notes:
The script doesn't stop on errors.
The cwm_restore.zip package doesn't really odex your ROM: it restores the odexed files you pulled from your device before deodexing. So yes, your ROM will get back to it's previous odexed state, but that package won't odex any ROM.
Changes:
-v1.1: Scripts and binaries moved to a "tools" subdirectory; now also creates a flashable zip to restore the old odexed files; reduced the amount of screen output.
-v1: Initial.
If you can suggest any correction to the script, please do it.
Also, since English is not my language, feel more-than-free to point out if there's something wrong or unclear in the post .
Great work
Could you write such a script for odexing too ?
Sent from my BL-S5570 using xda app-developers app
May be... But I don't see any benefits in an odexed ROM. It's just quicker when booting the first time.
Gspin96 said:
May be... But I don't see any benefits in an odexed ROM. It's just quicker when booting the first time.
Click to expand...
Click to collapse
The .odex file is kept in memory ...so higher ram usage but apps open a lot faster as they are already in memory ....also your internal memory is almost completely empty so you don't need to use sd-ext....
Sent from my GT-S5570 using Tapatalk 2
hsay said:
The .odex file is kept in memory ...so higher ram usage but apps open a lot faster as they are already in memory ....also your internal memory is almost completely empty so you don't need to use sd-ext....
Click to expand...
Click to collapse
Here is a quote from http://forum.xda-developers.com/showthread.php?p=39393263
R_a_z_v_a_n said:
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.
Click to expand...
Click to collapse
Also, keeping things in memory is an Android feature: if an app ran once, it is then kept in memory until you use a task killer (which is not recommended, as Android then would have to reload the app in RAM, slowing down and draining battery) or the system gets out-of-memory.
It's more correct to say that odex files are, ready to be loaded in RAM, because the Dalvik Machine doesn't need to optimize them. However, after the DM optimizes them on the first boot, they're kept in the dalvik cache, as ready to be loaded as an odexed app would be.
Anyway, for who wants to re-odex, there's an easy solution: you can use Titanium backup (menu->Integrate sys Dalvik into ROM).
Gspin96 said:
Anyway, for who wants to re-odex, there's an easy solution: you can use Titanium backup (menu->Integrate sys Dalvik into ROM).
Click to expand...
Click to collapse
That is not odexing ...its just an alternative.
Sent from my GT-S5570 using Tapatalk 2
Did you try? I did. It does indeed create the .odex files you want in /system/app.
Gspin96 said:
Did you try? I did. It does indeed create the .odex files you want in /system/app.
Click to expand...
Click to collapse
I stand corrected ...
But does it odex the framework files and other things?
Sent from my GT-S5570 using Tapatalk 2
I was editing that post because i saw that framework was not odexed.
Hell, I had found a link to a to a re-odexing script/tutorial here on xda in the galaxy 3 (not galaxy s3) forum, but I had to go leaving that post unedited.
I'll add a link to that tutorial on first post as soon as I'm on my PC again.
Thanks.
EDIT: this is the tut: http://forum.xda-developers.com/showthread.php?t=1402233
Gspin96 said:
I was editing that post because i saw that framework was not odexed.
Hell, I had found a link to a to a re-odexing script/tutorial here on xda in the galaxy 3 (not galaxy s3) forum, but I had to go leaving that post unedited.
I'll add a link to that tutorial on first post as soon as I'm on my PC again.
Thanks.
EDIT: this is the tut: http://forum.xda-developers.com/showthread.php?t=1402233
Click to expand...
Click to collapse
Btw even universal odex script by matrixdj96 works good and its here in the mini Dev section and bro hope no hard feelings.
Sent from my GT-S5570 using Tapatalk 2
I didn't see that script, it looks good (I won't try it, I'm going to mod framework).
bro hope no hard feelings
Click to expand...
Click to collapse
No, man. I've been feeling attacked somehow, but I know I shouldn't have.
New update: now it's a bit (really, just a very little bit) cleaner and also creates a .zip flashable which restores your ROM to its previous state (usually odexed, if it wasn't odexed, then you wouldn't have used the script).