I pulled down `boot.oat` from an API22 Android phone. It's Android 5.1 Lollipop which brought the change from Dalvik to ART and is a bit mistified (at least for me).
To make it exact this is from an old Xperia Z Ultra (factory ROM, nothing is/was customized).
As far as I understand, modifying boot.oat is not easy, and permanent, as this file is regenerated every time whenever a package installation/deinstallation is happened.
I need to modify a class which resides in `framework.dex` which I found in `boot.oat` (/system/framework/arm/boot.oat).
I have several questions I don't really understand:
1.) I have `framework.jar` in /system/framework, but it's size is 309 bytes, contains only manifest.mf. Does this file has any correlation to `framework.dex` in `boot.oat`?
2.) What is `boot.art`? It was not needed to deodex `boot.oat`.
3.) How can I properly put back my modifications to `boot.oat`? (Can I brick the device by providing a wrong `boot.oat`? Or- as it can be regenerated after package changes, it will also be simply regenerated if it's invalid?)
4.) How can I make my change permanent, i.e. survive boots, package installations, etc (in general boot.oat regeneration)?
Thanks for reading folks!
Related
Hello all,
I am working on a custom CyanogenMod ROM (10.2) for my own use. I've managed to accomplish most of my goals. One thing remains: removing packages that I don't want/need from the build. Technically, I am able to do so already by modifying the Android.mk file of the package so that it produces errors during the build procedure, skips building the package, but doesn't stop the entire build process. However, that is just a lousy hack.
Can anyone point me to the correct .mk/.sh/.whatever files in the repository I would need to edit (there are probably several) so that I can skip building the packages I don't want included in my ROM? I want to avoid using a "kitchen" if I can. I won't actually learn anything if I use a kitchen.
Files to look at
After laboriously looking through the repository, I came accross several files/directories you may need to look through/edit to remove packages from the build:
This directory (replace cm102 with your path to your Cyanogen repo):
/cm102/vendor/cm/config
This file:
/cm102/android/cm-10.2-M1.xml (<- This is a long file, dig through it. I edited this to help me remove some prepackaged live wallpapers, but there is a lot more in here.)
Device specific CM makefile that may specify additional packages to include (replace the all caps with whatever seems logical in your directory at each step):
/cm102/device/YOUR_MANUFACTURER/CODENAME-COMMON/CODENAME-COMMON.mk
What is the difference between deodex and odex roms? Sorry for the noob question but ive always been curious
Sent from my SCH-I605 using XDA Free mobile app
WHAT IS EXACTLY 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 The odexed file structure works well as an optimization tool. Since these .odex files contain preliminary load information about each system app, the OS knows what to expect when it’s booting up, and consequently, loads all these apps faster.
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.
For instance, on a non-rooted device you’ll find
system/app/Phone.apk ===> as well as ===> system/app/Phone.odex
AND NOW THE DEODEX FILE ?
It’s the process to take all the packages out from .odex file and reassemble them all together in classes.dex file which is kept inside the APK file. 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.
In summary, 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.
on the same device but rooted now, you’ll find this:
system/app/Phone.apk ===> but no longer the corresponding .odex file. The reassembled files become classes.dex
CONCLUSION: ADVANTAGES & DISADVANTAGES FOR BOTH SYSTEM FILES
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, that’s why developers prefer it and most, if not all, of the custom ROMs come pre-deodexed.
The advantage of .odex file is the faster load time of the app and 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.
And finally rooting need not necessarily mean your device is deodexed, rather that almost all stock ROMs are odexed to some extent, and usually most custom ROMs are deodexed for easy theming.
For a casual user, the main implication is in theming possibilities. Themes for android come in APKs too, and if you want to modify any of those, you should always choose a dedoexed custom ROM.
Hi,
when i download some roms, release after release, i saw that, sometimes, only some files are changed.
if i make a little zip with only the differencies comparing two zip, and if i change updater-script
(deleting "delete system" process , deleting flashing kernel lines, generaly, at end of script and managing other things)
can someone confirm that if my updater-script never delete /system/ , i have no risk to "kill" my device ?
i have an idea about the reply but its good to have a thread about this question, no ?
i have test this following when i run a 2nd rom with dorimanx kernel.
- I search about differencies on two spirit releases rom. (using 7zip , good interface to compare and you have the total size of each folder in zip)
- On a structured folder, i keep only the new files from new release.
(apk, binary,priv-app,framework..., comparing them using size files essentialy because using the date as comparison filter never help in this way)
- i run my 2nd rom
1 - Remember us, with dorimanx kernel, when we are dualbooting roms, no matter the position rom you are run at a moment (1rst or 2nd), you will be able to see /system/ and /data/ partitions from the other rom which generaly sleep
2 - On PC, i generaly use WINSCP soft to acces easily on all structured folders of my device. (just let you know)
So,
- i launch WINSCP on PC, then i can log-in as root on my device, 2nd rom runing.
- in the interface gui of WINSCP, on left side, i see my extracted differencies structured with all files and in right side, i can see all folders from my device.
- with the interface gui from WINSCP, i can copy all that i need in /system_pri_rom/ and /data_pri_rom/ , which are the auto-mounted partitons from 1rst rom
- if DEV have moving some apks from /system/app/ to /system/priv-app/ , i move the files too. If DEV have delete some files, i delete too.
- when i reboot my 1rst rom, it booted without any trouble.
result :
the +
i dont flash anything
i dont change kernel
the -
looking for differencies between 2 zip take time
the +/-
i dont format/delete entire system and maybe with time, this can be corrupted.
If someone can help me this way by making a little script which can make the differencies with an output zip , it will be much appreciated
thanks.
Hey,
The old Xposed used to create an Xposed.Disabled.zip that we could flash to disable Xposed but I can't find an easy way to fix a bootlooping / stuck boot without refreshing the ROM...
I tried entering some terminal commands from a different thread but none worked.
Any advice?
Use my disabler!
http://forum.xda-developers.com/xposed/xposed-framework-disabler-incase-t3100669
in recovery go to file manager,then go to data/data/de.robv.android.xposed.installer/conf/ ,and remove the modules.list file.it works for me
delete /system/framework/XposedBridge.jar
I had to delete all of the files that were replaced in /system/lib, /system/bin, delete the xposed files in /system/framework and rename the originals to their originals (by either removing '.orig' or '_original'). All done in TWRP file manager.
Basically, in any of those directories delete files that have the originals (as hinted either by the name or file extension, of course delete the file with part of it saying '.noorig') and rename the originals so that they look like the ones that xposed added. Also delete any other files that don't mention original but strongly hint by their name that they're part of xposed (this excludes anything in /data).
I had to follow a guide in order to find these files, but that guide didn't mention some extra files that are left by xposed, presumably because the thread is a little old.
Xposed installer is occupying more than 500 mb after installation (almost fills the full phone storage)
So i have to remove app data every time and had to enable modules again....
Does anyone facing same problem?
Model - lenovo s820
Os - kitkat 4.4.2
Sorry to ask question here but i have no idea on where to ask the question
I didn't want to hijack/spam any of the established threads, but I'm hoping some of the people working with roms will be kind enough to respond to me here.
On clean MM installed rom, you'll find the following folders :
- /system/odex.app
- /system/odex.priv-app
- /system/odex.framework
They all contain .odex files for respective folders, and when compared to the ones included in each app's folder, they are the exact same, what are these folders for ?
There are also files named odex.app.sqsh (priv-app and framework too), so are all these files ok to delete ?
One more thing, if you go into /data/app you'll find all your apps odexed there, why ? is this some kind of forced action by MM ? can these files be safely deleted ?
I'm asking these question because I'm getting random reboots on my ROM, and the Z2_fixbootloop zip posted in other threads doesn't work for me (I'm on a 6502 model, so my sim is not detected if I flash this file), I'm going to restore all the files I've removed to debloat the rom and see if the random reboots disappear, and then continue from there, but meanwhile any help from those who know is much appreciated.
Edit 01 : after a bit of googling, I extracted the sqsh files and they contains the exact same odex files from the odex.**** folders or the ones included with the apps themselves, so we have 3 copies of odex files in the rom ????