Please comment
Sent from my HTC One XL using xda premium
Devs say yes cuz it splits app in half. I dont notice any difference.
Typically, a rom is supposed to be odexed for smoother and faster loading of apps into memory. Each app(.apk) has a corresponding sister file(.odex). When a app is opened, called to memory, the. Odex has the information needed to start loading the app. A rom that is deodexed has only the.apk file. So when it is opened/called to memory the information to load the app is inside of the .apk and and must be pulled from it to begin loading it into memory. So at this level you would probably ask "then why are most custom roms deodexed?" People really started deodexing roms for themability. It is much much simplier to theme roms that are deodexed. It wasnt for faster speeds but for easier customization. So "themers" could build custom themes instead of have to build a whole themed rom. So now on one side you have odexed for speed, or deodexed for customizations? Well the brilliant devs in the android world came up with pretty good solutions to even out the field. In most any custom deodexed, youll see that they zipalign all the .apks in boot. While boot up time will be slightly longer, zipaligning optimizes every. Apk on every reboot which basically optimizes the information in each. Apk so when it is called to memory, the information is at the ready and quickly loaded witbout the need of a. Odex file. I kinda rambled here but wanted to answer this one as best i could because i kno many people wonder, and not a whole lot always ask. Hope this helps explain a little bit for anyone curious. :beer:
Sent from my SPH-L710 using Tapatalk 2
Thanks very much for the explanation. Often wondered about difference. Good job.
Thanks for explaining mate. Are there any statistical data or experimental data on the performance of two idenrical roms one is deodexed and zipaligned while the other is odexed?
Thanks for the explanation. I have been flashing roms for a while now and haven't really understood the difference.
Thanks for all info
thanks alot for explaint this in detail it help novice like me alot ....
thanks once again.....
18th.abn said:
Typically, a rom is supposed to be odexed for smoother and faster loading of apps into memory. Each app(.apk) has a corresponding sister file(.odex). When a app is opened, called to memory, the. Odex has the information needed to start loading the app. A rom that is deodexed has only the.apk file. So when it is opened/called to memory the information to load the app is inside of the .apk and and must be pulled from it to begin loading it into memory. So at this level you would probably ask "then why are most custom roms deodexed?" People really started deodexing roms for themability. It is much much simplier to theme roms that are deodexed. It wasnt for faster speeds but for easier customization. So "themers" could build custom themes instead of have to build a whole themed rom. So now on one side you have odexed for speed, or deodexed for customizations? Well the brilliant devs in the android world came up with pretty good solutions to even out the field. In most any custom deodexed, youll see that they zipalign all the .apks in boot. While boot up time will be slightly longer, zipaligning optimizes every. Apk on every reboot which basically optimizes the information in each. Apk so when it is called to memory, the information is at the ready and quickly loaded witbout the need of a. Odex file. I kinda rambled here but wanted to answer this one as best i could because i kno many people wonder, and not a whole lot always ask. Hope this helps explain a little bit for anyone curious. :beer:
Sent from my SPH-L710 using Tapatalk 2
Click to expand...
Click to collapse
Best explanation of odexed vs deodexed. Deserves to be a sticky IMO.
18th.abn said:
Typically, a rom is supposed to be odexed for smoother and faster loading of apps into memory.
Click to expand...
Click to collapse
No, well not for the reasons you describe anyway. DexOpt is run to optimize the dex file (ie. the Java/Dalvik byte-code). See the link below for more information.
http://www.netmite.com/android/mydroid/dalvik/docs/dexopt.html
18th.abn said:
Each app(.apk) has a corresponding sister file(.odex). When a app is opened, called to memory, the. Odex has the information needed to start loading the app.
Click to expand...
Click to collapse
Well, it's just an optimized version of the classes.dex file from the APK so sure. The dex file also has the information required, just in a slightly less optimal format.
18th.abn said:
A rom that is deodexed has only the.apk file. So when it is opened/called to memory the information to load the app is inside of the .apk and and must be pulled from it to begin loading it into memory.
Click to expand...
Click to collapse
With zipalign that you mention below, resources in the APK can be loaded directly from the APK without the need to decompress everything. This is because zipalign uses padding in the zip file to make sure each resource starts at an address that aligns with a 4 byte boundry. That allows Android to allocate it directly.
18th.abn said:
So at this level you would probably ask "then why are most custom roms deodexed?" People really started deodexing roms for themability. It is much much simplier to theme roms that are deodexed. It wasnt for faster speeds but for easier customization. So "themers" could build custom themes instead of have to build a whole themed rom.
Click to expand...
Click to collapse
True. The argument that a deodexed rom is slower is still pretty shaky though.
18th.abn said:
So now on one side you have odexed for speed, or deodexed for customizations? Well the brilliant devs in the android world came up with pretty good solutions to even out the field. In most any custom deodexed, youll see that they zipalign all the .apks in boot. While boot up time will be slightly longer, zipaligning optimizes every. Apk on every reboot which basically optimizes the information in each. Apk so when it is called to memory, the information is at the ready and quickly loaded witbout the need of a. Odex file.
Click to expand...
Click to collapse
Zipaligning on boot is mostly pointless for ROMs built from source or ROMs that have not been modified since they will then already have been zipaligned during the build process. It is in no way a replacement for DexOpt.
Also, do note that DexOpt will run at boot and produce odex-files for every classes.dex in every APK and put them in dalvik-cache. That includes all the APK files in /system/app if the ROM is deodexed (or built without being DexOpt:ed) as well as all app that the user has installed from the Play Store etc. If the APKs on the device ever changes dalvik-cache will be updated with the new odex by DexOpt. In other words, you gain the customization benefit of a deodexed APK while at the same time get to enjoy the optimization of odex files by sacrificing a little storage space (due to keeping both the dex and odex files).
Can someone please explain the logic behind the argument that odexed ROMs are faster? I have yet to see a proper explanation that makes sense.
blunden said:
No, well not for the reasons you describe anyway. DexOpt is run to optimize the dex file (ie. the Java/Dalvik byte-code). See the link below for more information.
http://www.netmite.com/android/mydroid/dalvik/docs/dexopt.html
Well, it's just an optimized version of the classes.dex file from the APK so sure. The dex file also has the information required, just in a slightly less optimal format.
With zipalign that you mention below, resources in the APK can be loaded directly from the APK without the need to decompress everything. This is because zipalign uses padding in the zip file to make sure each resource starts at an address that aligns with a 4 byte boundry. That allows Android to allocate it directly.
True. The argument that a deodexed rom is slower is still pretty shaky though.
Zipaligning on boot is mostly pointless for ROMs built from source or ROMs that have not been modified since they will then already have been zipaligned during the build process. It is in no way a replacement for DexOpt.
Also, do note that DexOpt will run at boot and produce odex-files for every classes.dex in every APK and put them in dalvik-cache. That includes all the APK files in /system/app if the ROM is deodexed (or built without being DexOpt:ed) as well as all app that the user has installed from the Play Store etc. If the APKs on the device ever changes dalvik-cache will be updated with the new odex by DexOpt. In other words, you gain the customization benefit of a deodexed APK while at the same time get to enjoy the optimization of odex files by sacrificing a little storage space (due to keeping both the dex and odex files).
Can someone please explain the logic behind the argument that odexed ROMs are faster? I have yet to see a proper explanation that makes sense.
Click to expand...
Click to collapse
De-odex is only slower in first ever boot time or the first boot time after dalvik cache is cleared. You seem to know enough about it to understand why that is. And if not, 18th.abn's post does explain why pretty well. It is not slower in terms of everyday operation.
exad said:
De-odex is only slower in first ever boot time or the first boot time after dalvik cache is cleared. You seem to know enough about it to understand why that is. And if not, 18th.abn's post does explain why pretty well. It is not slower in terms of everyday operation.
Click to expand...
Click to collapse
Exactly my point. I see people and articles stating that there is a performance difference but I just don't see why that would be. To me it seems to be something that has been repeated enough times to become a "fact".
What if RAM is very low on a phone with limited cpu ?
DoctorPINK said:
What if RAM is very low on a phone with limited cpu ?
Click to expand...
Click to collapse
It will be slow but will have nothing to do with odex vs deodex.
18th.abn said:
Typically, a rom is supposed to be odexed for smoother and faster loading of apps into memory. Each app(.apk) has a corresponding sister file(.odex). When a app is opened, called to memory, the. Odex has the information needed to start loading the app. A rom that is deodexed has only the.apk file. So when it is opened/called to memory the information to load the app is inside of the .apk and and must be pulled from it to begin loading it into memory. So at this level you would probably ask "then why are most custom roms deodexed?" People really started deodexing roms for themability. It is much much simplier to theme roms that are deodexed. It wasnt for faster speeds but for easier customization. So "themers" could build custom themes instead of have to build a whole themed rom. So now on one side you have odexed for speed, or deodexed for customizations? Well the brilliant devs in the android world came up with pretty good solutions to even out the field. In most any custom deodexed, youll see that they zipalign all the .apks in boot. While boot up time will be slightly longer, zipaligning optimizes every. Apk on every reboot which basically optimizes the information in each. Apk so when it is called to memory, the information is at the ready and quickly loaded witbout the need of a. Odex file. I kinda rambled here but wanted to answer this one as best i could because i kno many people wonder, and not a whole lot always ask. Hope this helps explain a little bit for anyone curious. :beer:
Sent from my SPH-L710 using Tapatalk 2
Click to expand...
Click to collapse
Cheers mate, I was wondering what the heck is this odexed/deodexed and you just explained it smoothly.
Thanks again
Related
we now seem to believe that odex files speed up the apk. It evidently it seems to be so, and it should as, among other things, it optimizes method lookups to use memory offsets instead, similar to the C linker. I've notice a good performance increase coming from JF 1.5 to JF 1.51 US, and the difference between those two builds is mainly the odex files. Other have also had similar theories about the ION build.
Anyways, I've recreated the odex file for the Browser that JF had us remove becuase it was breaking multi-touch. the recreated odex files as I expected did not break multi-touch as the original one since the one I created was based on the Browser.apk that JF patch rather than the original Browser.apk. Everything seems to work including multi-touch, except that I can't really tell if there is any performance increase just by using the browser. At least nothing obvious, may be it is a little faster but just don't notice it.
I was wondering if I can do the same for all the apps including the ones we download from the market? would the dalvik vm check and use the odex file if it exists in the same location as the apk?
by the way, in case people want to try it you can create odex file using dexopt-wrapper command on the phone. Supposedly you have to create them in the phone itself since it is sensitive to the memory address of the methods that the apps call.
odex allows the dex file to be uncompressed on system, so loading is definitely faster. You now would have more free space on /data, because dalvik-cache is used less.
I would love someone to he lp me work out how to write a script to optimize all my apk's. I'd do it to my build in 1.3 seconds...I just need more time. I'll be able to answer this question once I figure it out.
(Time + Google) effort = win
I don't think the odex files is the cause of the ion performance increases.
The tmobile build all have odex files and its not nearly as fast as the ion build in terms of UI responsiveness.
An ion build running at the default cpu (384mhz) is just about as fast an jf 1.51 us build running at max cpu (528mhz).
The other theory is that the ION builds have 2d hardware acceleration enabled, which seems plausible to me.
Or I guess it could be that they optimized the odex files even more in the ion images.
dwang said:
I don't think the odex files is the cause of the ion performance increases.
The tmobile build all have odex files and its not nearly as fast as the ion build.
An ion build running at the default cpu (384mhz) is just about as fast an jf 1.51 us build running at max cpu (528mhz).
The other theory is that the ION builds have 2d hard acceleration enabled, which seems plausible to me.
Or I guess it could be that they optimized the odex files even more in the ion images.
Click to expand...
Click to collapse
odex helps boot time and load times
the dalvikvm from ion is definitely leaner, faster, better, etc. I put it on my build today and there has been reported a speed increase, some say a big one...some say a minor one. But it is faster.
Just moving the dalvikvm and the libdvm.so over to my build has had reported speed increases, just like in Ion.
As far as the libhgl.so it is exactly the same as most builds. Nothing new is in the update graphicwise.
TheDudeOfLife said:
odex helps boot time and load times
the dalvikvm from ion is definitely leaner, faster, better, etc. I put it on my build today and there has been reported a speed increase, some say a big one...some say a minor one. But it is faster.
Just moving the dalvikvm and the libdvm.so over to my build has had reported speed increases, just like in Ion.
As far as the libhgl.so it is exactly the same as most builds. Nothing new is in the update graphicwise.
Click to expand...
Click to collapse
Ok so ION has an updated dalvik vm. So that could explain it.
Dalvik runs a recursive dexopt on boot anyway, essentially producing the same thing but using space in dalvik-cache.
cyanogen said:
Dalvik runs a recursive dexopt on boot anyway, essentially producing the same thing but using space in dalvik-cache.
Click to expand...
Click to collapse
it does so to create dex files, which is needed to run the apk. but it doesn't use optimized dex (odex). I think that's why ION build and US build package the odex files with image.
knaries2000 said:
it does so to create dex files, which is needed to run the apk. but it doesn't use optimized dex (odex). I think that's why ION build and US build package the odex files with image.
Click to expand...
Click to collapse
The dex file is already inside the APK. What dexopt does is create optimized bytecode from it. This is either done at runtime (files stores in dalvik-cache), or using a tool called dexpreopt which does the same thing but in a static way.
http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/dexopt.html;hb=HEAD
cyanogen said:
The dex file is already inside the APK. What dexopt does is create optimized bytecode from it. This is either done at runtime (files stores in dalvik-cache), or using a tool called dexpreopt which does the same thing but in a static way.
http://android.git.kernel.org/?p=platform/dalvik.git;a=blob_plain;f=docs/dexopt.html;hb=HEAD
Click to expand...
Click to collapse
thanks for the info and link. So like the dude said, creating the odex file ahead of time should increase the loading time of the app.
anyways, if anyone is interested you can create odex files in for all apps in /data/app with the script below. change /data/app/*.apk to /system/app/*.apk to do the same for all apps in /system. I just did this to my phone running jf151 US. I dont' notice a big performance increase, but I really haven't had a chance to play with it.
for i in /data/app/*.apk
do
odex=`echo $i | sed -e 's/.apk/.odex/g'`
echo "dexopt-wrapper $i $odex"
dexopt-wrapper $i $odex
done
thanks for that script. I am trying it now!
wow! this works nicely. No problems using your script and I do notice a slight difference. About 75 apps installed.
I did both system and data apps
beagz said:
wow! this works nicely. No problems using your script and I do notice a slight difference. About 75 apps installed.
I did both system and data apps
Click to expand...
Click to collapse
i notice a slight speed difference too, but i thought it was just me. anyways, one thing I noticed was that if you update an app from the market you have to delete the obex file or recreate it, otherwise you may get force closes. Very unpleasant side effect.
Thanks for the heads up on that. I will make a mental note so that I recreate the odex after updates.
I think the speed increase in ION is more than just the new dalvik vm.
I download the dudes latest image with the ion dalvik and tested both ion and dudes back to back. The ION image is still faster. Its not a dramatic difference, but its there.
* Swiping between screens in the home app is faster.
* Scrolling in the browser is faster.
* Typing using the virtual keyboard is faster and more responsive.
I don't think the odex files have anything to do with it either because that only speeds up loading and all the things above are all done when the apps are already in RAM so the odex files won't matter.
Could we implent this dalvik-vm in the Hero-Build, and if yes, how?
beagz said:
thanks for that script. I am trying it now!
Click to expand...
Click to collapse
did you try the script for apps from market? i assume you just change the directory to system/sd/app
as for the force close you would just have to run the script each time after using atrackdog?
yes I used it for both system/app and data/app
data/app is the market apps.
don't have system/sd/app since I am using the new a2sd (It's all connected by unionfs)
beagz said:
yes I used it for both system/app and data/app
data/app is the market apps.
don't have system/sd/app since I am using the new a2sd (It's all connected by unionfs)
Click to expand...
Click to collapse
oh. i have the new a2sd as well..... so i just do data/app and it finds them ok? cool.....
Verified. Both odex and apk in there after running script.
maxisma said:
Could we implent this dalvik-vm in the Hero-Build, and if yes, how?
Click to expand...
Click to collapse
You can load it and for things like dxtop that usually lag loading the app drawer it will make a significant difference. Just read above and copy over those files from ion to hero.
I have gone through several applications from the MR release and optimized the images inside in an attempt to free up memory and/or speed things up a bit.
Some things benefited more than others, for example, Rosie.apk has lost around 7MB.
This will only work on software version 1.56.651.2. Don't know what version you have? Go into your settings -> About and scroll down to Software Version
Anyways, here's a list of things that have been optimized:
Code:
Folder: /system/app/
Browser.apk
com.htc.WeatherWidget.apk
htcContacts.apk
HTC_IME.apk
Maps.apk
Phone.apk
Rosie.apk
Settings.apk
Weather.apk
Folder: /system/framework/
com.htc.rersources.apk
Also included in the zip are the animations and boot screen from the Gutted rom
The zip is signed and can be flashed from recovery
This has been tested on the following:
Fresh 0.4b, 0.5d, 0.6
Unofficial MoDaCo 1.2
Disclaimer: I am not responsible for what you do with you device. If you break it, it is solely your responsibility.
Always remember to do a nandroid backup before flashing anything
Downloads
11.24.09 New with zipalign
11.23.19 (Old - non zipaligned)
Installing now... Will let you know how it goes...
Edit.... Wow this really made a noticeable difference. Running really nice on a stock rooted phone. No errors as well...
Installed on Fresh Rom. Works good no errors!
Wow! Just flashed this and it's great. Apps seem to load quicker. thanks for the work!
How are your optimizing these? Just the graphics inside them? have you tried to use zipalign from the SDK on anything?
ekinnee said:
How are your optimizing these? Just the graphics inside them? have you tried to use zipalign from the SDK on anything?
Click to expand...
Click to collapse
You are correct, just the graphics, I haven't looked into any other methods yet
I just flashed this over my stock/rooted image. It does indeed load and run very fast. I was wondering what changes you made to the Settings.apk? I also did notice that the transition effects changed to a fade-in effect. Was this also the result of graphic optimizations? Either way, great work!
excellent mod. really enjoy the fading in and out and works alot quicker!
Spunkzz said:
excellent mod. really enjoy the fading in and out and works alot quicker!
Click to expand...
Click to collapse
Has this been tested on the Gutted ROM?
For further optimization use zipalign on the apks. This allows dalvik to mmap the files for further speed improvements.
I like it alot but I get a ton of force close errors cant even really do anything. Installing from the orignal modaco rom.
Ok I don't know if it was this update or the 1.2 unofficial but my dialer now vibrats and I can't figure out how to shut it off.
My dialer vibrates as well, running Fresh .5d, would also like to disable it.
Looking forward to giving this a shot
QuiQNeZZ said:
Ok I don't know if it was this update or the 1.2 unofficial but my dialer now vibrats and I can't figure out how to shut it off.
Click to expand...
Click to collapse
The dialer started vibrating after the official firmware update from Sprint/HTC. I don't see any option under settings that allows us to disable it.
thanksa bunch I was really hoping someone would slim Rosie down a bit
i keep getting the application touch input process com.htc.android.htciem) has stopped unexpectedly. Please try again
EDIT
aparently i cant text anymore?! help!
To those people who are having errors, are you using this on a rom that has been updated with the Sprint Maintnance Release?
no but i never had a problem XD
By optimizing the images is there a downgrade in quality? Or is there no downside to this mod?
Thanks man. the animations are awesome. and it faster, i didnt notice a change in available memory, but i dont really care.
Thanks again!
i had removed the Browser, so this reinstalled the .apk. just had to go in and remove it again, JIC anyone has removed one of the files, just go in and remove it again.
Just throwing an idea out there, and since it's for developers (specifically people who make their own recovery images) I assume this is the right section.
Since we have 'control' over the recovery image on our phones, would it not be possible to add a little script to an update.zip that a suitably modified recovery image could extract and run to interactively prompt the user for various Rom options? I'm thinking specifically of kernel choices, but it could be extended to almost anything that needs to be done prior to booting the installed image.
Imagine installing a rom, and during the install you got a little menu like this:
1: RamHack, BFS Kernel
2: RamHack, CFS Kernel
3: No-RamHack, BFS....
etc...
inefficient, it adds extra baggage to rom, and more things can go wrong. what would you rather downlaod a 90mb file or a 110 mb file.
Which would you rather download, one 110MB ROM or 2 90MB ROMS?
I'm pretty sure there's more than a few people who'll download different variations of the same ROM so they can see which is faster, how much easier would it be to just download one thing and then choose which options you want in there without downloading anything else.
I believe it is entirely possible. As a matter of fact, I was working on a ROM project that would have an interactive installer from the update.zip that would selectively install different features, apps, customization, themes, etc., based on the recovery menu application. It would use a lot of the /cache for temp space, though, as the installer application and its resources and configuration file, and later, the necessary parts of the ROM itself, would need to be unzipped before the install can run, if I recall correctly.
Does anyone have a good link to a reference for the command syntax for the /META-INF/com/google/android/update-script file? I'll go search for it in a few moments myself. I could probably make a simple ROM installer that chooses between ROM X and ROM Y based on a key input, as a proof of concept. I'll test it myself, I don't really mind half-bricking my device for science. (As long as I don't need to touch the SPL/Radio, that is.)
Update: Some creative searching finds me this:
JesusFreke said:
Assuming you mean update-script in an update.zip update, you will need to either look at existing update-script files for an example of the syntax, or look at the source of the recovery program in the android source
Click to expand...
Click to collapse
There's also a "make-update-script.c" file I'm seeing here and there, I'm trying to find the file in the Android source.
Update 2: From install.c at donut from cyanogen's android_bootable_recovery:
Code:
#define ASSUMED_UPDATE_SCRIPT_NAME "META-INF/com/google/android/update-script"
#define ASSUMED_UPDATE_BINARY_NAME "META-INF/com/google/android/update-binary"
and in commands.c, toward the bottom at register_update_commands is all the commands defined, and above that are all the functions they carry out.
sorry about that deicist i was sleepy when i wrote that so i must have been cranky yea i guess that is a fine idea, with just 30 more mb you have like 300mb worth of stuff. and you can pick which 90 mb you want.
markolo25 said:
sorry about that deicist i was sleepy when i wrote that so i must have been cranky yea i guess that is a fine idea, with just 30 more mb you have like 300mb worth of stuff. and you can pick which 90 mb you want.
Click to expand...
Click to collapse
Well, on the 32B platform with the Death SPL (my phone) we have the following partitions of the internal NAND memory (mtdblock*) from the df and mount command:
NAND 3: /system 92160kb - OS partition, static and read-only
NAND 5: /data 91904kb - User, system config, app config, and apps (without a2sd)
NAND 4: /cache 30720kb - OTA cache, Recovery/update config and temp
And I'd assume NAND 1 and 2 are the kernel, ramdisk, and bootloader config.
So the ROM wouldn't exceed 92MB installed (most leave some room in /system for hacks and updates). And the update process doesn't ever really "flash", per se; it just formats, copies files, and sets permissions and initialization configs, like Windows or Mac.
So the files that are common to the different ROMs being packaged don't need to be duplicated, only the ones that are changed (like a boot.img, or 32A/B compatibility, or different apps). The update script and chooser menu will decide which files to copy. Meaning the ROM package in and of itself shouldn't really need to exceed 128MB, even if choosing from a wide variety of platforms. And upon installation, the system might take less than 32 MB.
yeah, what he said ^
The scenario I was thinking about specifically was SuperD. If you look here:
http://forum.xda-developers.com/showthread.php?t=613809
There's 8 different downloads there. How many files are actually different between those 8? I guess the themes mean a lot of application files are different (due to having different resources in them) but the underlying framework files will be pretty much the same I think.
Deicist said:
yeah, what he said ^
The scenario I was thinking about specifically was SuperD. If you look here:
http://forum.xda-developers.com/showthread.php?t=613809
There's 8 different downloads there. How many files are actually different between those 8? I guess the themes mean a lot of application files are different (due to having different resources in them) but the underlying framework files will be pretty much the same I think.
Click to expand...
Click to collapse
I could download them all, and find the differences of each. It would be cool if a ROM like this were available in a single download, from which you would choose the content from the device before flashing.
Also, inspired by talking about this, I wrote up a guide on the update-script in the package file. It's still not finished, but it'll be the only guide available for that syntax yet (trust me, I couldn't find one myself ). Link's in my sig.
I'm surprised that nobody's mentioned the Droid... the sholes.info rom (now called droidmod) have used a .tgz archive instead of a .zip, the .tgz installs have always allowed this customization, droidmod makes one of the most common recovery's AND rom's. (SPRecovery/Droidmod).
It give you the option to choose what launcher to install, what theme, what apps to remove.
page here: http://droidmod.org/news/droidmod-v1-0-is-out/
how big of a ROM are you thinking about?
There are roms (WG etc...) that offer more than one kernel as update.zip you can flash over an existing installation of your rom instead of adding all the stuff to one big file. also you can download themes for several roms/for metamorph.
so why would you want some big install script instead of just downloading the files you like and flash it?
jmhalder said:
I'm surprised that nobody's mentioned the Droid... the sholes.info rom (now called droidmod) have used a .tgz archive instead of a .zip, the .tgz installs have always allowed this customization, droidmod makes one of the most common recovery's AND rom's. (SPRecovery/Droidmod).
It give you the option to choose what launcher to install, what theme, what apps to remove.
page here: http://droidmod.org/news/droidmod-v1-0-is-out/
Click to expand...
Click to collapse
Is the Droid's recovery image capable of running on the G1, and/or is it open-source enough to be cross-built to the G1? If so, we could port it here. Only problem there though, is that all the roms are in update.zip format for the G1 already, we'd need to make it dual-compatible if we don't want to split the community and annoy generally everyone ("My rom only supports TGZ recovery!" "ROMs are in ZIP format, and I will not make a TGZ one for those unfortunate enough to use the other Recovery!")
domenukk said:
There are roms (WG etc...) that offer more than one kernel as update.zip you can flash over an existing installation of your rom instead of adding all the stuff to one big file. also you can download themes for several roms/for metamorph.
so why would you want some big install script instead of just downloading the files you like and flash it?
Click to expand...
Click to collapse
Well, for one, devs need to host one file only, and users need to download one file only. The file won't be much bigger or more complex at all, really. And the way things look on the recovery side, we could probably put a selection of themes in with the updater and patch them in post-install with a Metamorph script straight from recovery. That way, the rom is as you want it out-of-the-box, no multiple reboots, etc.
Also, those scripts that usually run on first-boot, like zipalign, dexopt, apps2sd etc. should run from the recovery environment, instead of before the Android bootanimation (I do get tired of hearing "This ROM will take a LONG time on the first boot. If it's stuck at the G1 screen, just wait 10-30 minutes.")
So what would you rather have, one single ROM (G1_Android_ROM_v1.17.zip) for each version released,
or six different ZIPs to flash (G1_Android_ROM_10MB_CFS.zip, G1_Android_ROM_Greentheme.zip, G1_Android_ROM_Bluetheme.zip, G1_Android_Nowipe_GApps.zip)?
Would you rather select what you want to include at flash (and be able to change things like themes or features after flashing), or have 20 different files to choose from, wiping and flashing on each?
I am aware of the no-wipe upgrades for many ROMs, but they can get confusing (I once flashed a CFS_10MB.zip that was for a Hero ROM, stupidly thinking that it might have been for the Eclair that I just downloaded.) Needless to say, I had to wipe and reflash. Again.
TylTru said:
Is the Droid's recovery image capable of running on the G1, and/or is it open-source enough to be cross-built to the G1? If so, we could port it here. Only problem there though, is that all the roms are in update.zip format for the G1 already, we'd need to make it dual-compatible if we don't want to split the community and annoy generally everyone ("My rom only supports TGZ recovery!" "ROMs are in ZIP format, and I will not make a TGZ one for those unfortunate enough to use the other Recovery!")
Well, for one, devs need to host one file only, and users need to download one file only. The file won't be much bigger or more complex at all, really. And the way things look on the recovery side, we could probably put a selection of themes in with the updater and patch them in post-install with a Metamorph script straight from recovery. That way, the rom is as you want it out-of-the-box, no multiple reboots, etc.
Also, those scripts that usually run on first-boot, like zipalign, dexopt, apps2sd etc. should run from the recovery environment, instead of before the Android bootanimation (I do get tired of hearing "This ROM will take a LONG time on the first boot. If it's stuck at the G1 screen, just wait 10-30 minutes.")
So what would you rather have, one single ROM (G1_Android_ROM_v1.17.zip) for each version released,
or six different ZIPs to flash (G1_Android_ROM_10MB_CFS.zip, G1_Android_ROM_Greentheme.zip, G1_Android_ROM_Bluetheme.zip, G1_Android_Nowipe_GApps.zip)?
Would you rather select what you want to include at flash (and be able to change things like themes or features after flashing), or have 20 different files to choose from, wiping and flashing on each?
I am aware of the no-wipe upgrades for many ROMs, but they can get confusing (I once flashed a CFS_10MB.zip that was for a Hero ROM, stupidly thinking that it might have been for the Eclair that I just downloaded.) Needless to say, I had to wipe and reflash. Again.
Click to expand...
Click to collapse
You could just have flashed the original rom without wipe.
Would be a step forward if you could simply put roms and additional files in folders... maybe even whole zip files containing some updates and an xml like file to describe them. This would guarantee compatibility with earlier boot images (just unpack the updates in the zip). Tar might work better than zip as it is not compressed thus faster afaik.
http://droidninja.com/?p=26334
We got ninja'd. Apparently the Droid Does exactly this.
So let's get to work on porting it! Like this comment says, I'm working on finding the source code to a good Droid recovery image (sadly Droid hasn't its own forum here), and if it's closed source, I'll get on reverse-engineering a .tgz rom to see exactly how it works.
TylTru said:
http://droidninja.com/?p=26334
We got ninja'd. Apparently the Droid Does exactly this.
So let's get to work on porting it! Like this comment says, I'm working on finding the source code to a good Droid recovery image (sadly Droid hasn't its own forum here), and if it's closed source, I'll get on reverse-engineering a .tgz rom to see exactly how it works.
Click to expand...
Click to collapse
This is pretty awesome. I was going to say, we could easily run bash scripts but this is so much better.
This needs to be merged with both Amon_ra's recovery and the new 2.x based recovery...
Clarification on the poll question:
Yes = The ROM stays up
No = The ROM goes down
With the permission of MildWild I bring to you
MildWild v2.9.5 Lite Final
(based on MildWild V-2.9.5)
This is NOT a new ROM! It's only a trimmed down and fixed up version of MildWild V-2.9.5.
Change Log for Final Version:
- NEW - ZipAligned all system apks
- NEW - Automatic ZipAlign of new apks on every boot
- Fixed 720p HW encoding - works for H.264 format ONLY (see link to test file below)
- Fixed SuperCharger script - now using V6 SuperCharger update 8 with Aggressive 1 Setting
- Updated GO Launcher EX v2.77
- Updated Superuser v3.0.7
- Added HTC Stock Alarms, Notifications and Ringtones to the separate Media Package; converted all sounds to OGG Vorbis.
Fallout 3 Trailer @ 720p in H.264 - test file for HW decoding
F.A.Q.
I. Why would I want to install MildWild v2.9.5 Lite?
- It's smaller so it will fit on the Alpharev Oxygen r2 Hboot meaning that you will get a larger data partition and more space to install your applications. (Alpharev Oxygen r2 partition sizes: 100MB system, 5MB cache, 332MB data; Alpharev CM7 r2 partition sizes: 145MB system, 5MB cache, 287MB data)
- It stores apps and dalvik on sd-ext so you get even more space for your applications. On the downside, the ROM may become a bit slower.
- Alternatively, you can install the version which keeps dalvik on the internal memory.
II. So, how come MildWild v2.9.5 Lite is smaller?
- Some non vital system data and system applications have been removed from the instalation package.
III. Right, so what's missing?
- These applications have been removed:
1. GMmail (Gmail.apk) - you can install it from the Market so it will go to sd-ext instead on the internal memory, hence you get more space;
2. Google Talk (Talk2.apk) - well, you have to make some sacrifices; however, I think you can install it manually from the apk package but I haven't tried myself;
3. Google News & Weather Widget - you can find a whole range of simmilar applications on the Market; or you can probably install it from the apk package but I haven't tried;
4. Stock 3D Gallery (Gallery3D.apk - I recommend QuickPic from the Market instead; it is smaller and does the same job better;
5. Stock Music Application - there is a whole range of media players on the Market; this however will break the ability to play music through the Desk Clock Application; however, you can probably install it manually from the apk package but I haven't tried;
6. Typological Clock (TypoClock.apk) - you can most likely find something simmilar on the Market; or you can probably install it from the apk package but I haven't tried;
7. Timer Widget - you can most likely find something simmilar on the Market; or you can probably install it from the apk package but I haven't tried;
8. File Manager (FileManager.apk) - you can find a whole range of File Manager applications on the Market;
9. Compass (compass.apk) - you can find a whole range of Compass applications on the Market;
- Launcher 2 has been replaced with GO Laucher EX; it's smaller, faster and I think generally better; then again, it's a matter of taste;
- All alarms, notifications and ringtones have been removed from the installation package. Instead, you can download the media package attached (see link further down), unzip it, and place the folder as it is anywhere on the FAT32 partition of your SD card and it will work just the same. The system will automatically detect these files on the SD card.
- All PicoTTS (voice output) data files have been removed from the installation package. Instead, you can either download them from the Market or download the svox package attached (see link further down), unzip it, and place the folder as it is in the root of your FAT32 partition of your SD card and it will work just the same. The system will automatically detect these files on the SD card.
IV. So what's the point if I still want these applications?
- Whatever you install from the Market will go to sd-ext so you will have more space on the internal data partition for additional applications. If you keep the dalvik internal then the application data will stay on the internal memory but you still get some benefit as the apk still goes to the sd-ext.
- On the downside you can't get some of them on the Market and they may not install properly from the apk package so if you want to use exactly these apps then you'd better stick to the fully fledged MildWild ROM.
- However, you can download the apps package attached (see link futher down) and play with the apk files.
DISCLAIMER
ALL CREDITS go to MildWild.
I am NOT a delevoper and I have NOT developed any of the apps, bins, libs, etc. included inside the instalation file. I simply unpacked MildWild's zip file and removed/replaced a couple of things here and there, and then repacked it back. You can ask me questions but I cannot guarantee that I will be able to answer. Also, the responsability of installing the ROM and playing around with it lies 100% with YOU!
Download Links
MildWild v2.9.5 Lite Final (with dalvik on sd-ext)
MildWild v2.9.5 Lite Final (with dalvik on internal memory)
Media Package including HTC Stock Sounds - OGG Vorbis (alarms, notifications, ringtones)
Apps Package (all apks that have been revomed from the installation)
SVox Package (PicoTTS data files)
MildWild v2.9.5 based on Oxygen (The Original)
NOTE! This is the LAST and FINAL version of my modified ROM.
As you may or may not know, to concentrate on the CyanogenMod version MildWild has stopped development on the Oxygen version of this ROM for the foreseeable future (see here: http://forum.xda-developers.com/showpost.php?p=22130173&postcount=2568). As such, this is also the last update from me.
Do check out the ORIGINAL!
MildWild v2.9.5 based on Oxygen
Removing a launcher and replacing it with another one doesn't make it a custom ROM. This could all be put into a flashable ZIP which has to be flashed on top of a stock MildWild ROM, so that the update-script removes all the APKs. But another topic just for a modified ZIP only causes a lot of confusion.
what is the point of this ? everyone could make this.
Chaosz-X said:
Removing a launcher and replacing it with another one doesn't make it a custom ROM. This could all be put into a flashable ZIP which has to be flashed on top of a stock MildWild ROM, so that the update-script removes all the APKs. But another topic just for a modified ZIP only causes a lot of confusion.
Click to expand...
Click to collapse
Please read the description...
expler said:
what is the point of this ? everyone could make this.
Click to expand...
Click to collapse
Constructive comments would be very much appreciated...
Not a fan PERSONALLY of this "I can unzip, remove a few apps, then re-zip and post as a new rom" attitude, but it's a case of supply and demand I suppose. At least the OP has had permission from MildWild.
Screen ? ^_^
lolitz said:
Screen ? ^_^
Click to expand...
Click to collapse
Will do later on.
In any case, appart for the GO Launcher EX bits it looks exactly like MildWild - he's the BEST! (see link below)
MildWild v2.9.5 based on Oxygen
whats the point in making this a whole new thread?
it's some deleting/adding stuff to a zip file.. nothing else.
absolutely no need for this in my opinion, 'cause everyone can open a .zip file and delete stuff they don't want, and add stuff they want.
if we continue this road, we have 20 roms based on mildwild, and 20 different threads filled with the same questions over and over and over and over and over again.
horst0815 said:
whats the point in making this a whole new thread?
it's some deleting/adding stuff to a zip file.. nothing else.
absolutely no need for this in my opinion, 'cause everyone can open a .zip file and delete stuff they don't want, and add stuff they want.
if we continue this road, we have 20 roms based on mildwild, and 20 different threads filled with the same questions over and over and over and over and over again.
Click to expand...
Click to collapse
Please vote in the poll...
If people don't like it, then I'll remove it...
horst0815 said:
whats the point in making this a whole new thread?
it's some deleting/adding stuff to a zip file.. nothing else.
absolutely no need for this in my opinion, 'cause everyone can open a .zip file and delete stuff they don't want, and add stuff they want.
if we continue this road, we have 20 roms based on mildwild, and 20 different threads filled with the same questions over and over and over and over and over again.
Click to expand...
Click to collapse
whats with the hate? it saves people time of doing it themselves if they dont know what system related stuff they can remove without causing problems
it gives more space and mildwild allowed him to do it.
if you dont want it dont use it, im sure some people would be happy to use it.
as fopr putting it on the same thread? why would he hyjack an ops thread with different work. i doubt people would but it could be seen as trying to take people away from the original ops rom or some people might be confused with it being by mildwild himself as its displayed in a rom dev format..
people need to chill out, leave the complaining to the other devs if they have an issue with it and everyone else concentrates on flashing.
i dont see you complaining about the many different varients of stock roms that are modified in a kitchen using the same kernel as every other rom and called something different.
i dont see you complaining of the clones of 3.5 sense roms that have had different apps added just to call it something different.....
grow up
The ROM was great... That's very rude of you guys
He's just trying to help the people that don't know that much about ROM's.
OP, please continue what you're doing, it's great!
I'm already using your ROM
Guizzoni said:
The ROM was great... That's very rude of you guys
He's just trying to help the people that don't know that much about ROM's.
OP, please continue what you're doing, it's great!
I'm already using your ROM
Click to expand...
Click to collapse
Thanks...
Some people really put you down sometimes...
Rastaman-FB said:
whats with the hate? it saves people time of doing it themselves if they dont know what system related stuff they can remove without causing problems
it gives more space and mildwild allowed him to do it.
if you dont want it dont use it, im sure some people would be happy to use it.
as fopr putting it on the same thread? why would he hyjack an ops thread with different work. i doubt people would but it could be seen as trying to take people away from the original ops rom or some people might be confused with it being by mildwild himself as its displayed in a rom dev format..
people need to chill out, leave the complaining to the other devs if they have an issue with it and everyone else concentrates on flashing.
i dont see you complaining about the many different varients of stock roms that are modified in a kitchen using the same kernel as every other rom and called something different.
i dont see you complaining of the clones of 3.5 sense roms that have had different apps added just to call it something different.....
grow up
Click to expand...
Click to collapse
Dito!
Thank you for the support.
I voted yes. Do not delete this thread!
Oh, I do get annoyed by all the Sense ROMs too. With all that ROMs out there it's pretty hard to see the difference, so that's a mess too IMO.
Chaosz-X said:
Oh, I do get annoyed by all the Sense ROMs too. With all that ROMs out there it's pretty hard to see the difference, so that's a mess too IMO.
Click to expand...
Click to collapse
Please vote in the poll...
do3in said:
I voted yes. Do not delete this thread!
Click to expand...
Click to collapse
Do you know if we can get Android in Romanian? I would like to add it to this trimmed ROM.
I'm a little bit confused with the poll:
Do you think this trimmed ROM is useful = yes
or I should take it off = no
how to vote yes and no...? hehe
anyway good luck with the rom and thanks for sharing
I posted this over on the main V6 Supercharger thread but figured I'd post a link here to help out anyone who's using the script.
For those curious and who don't want to read hundreds (thousands?) of posts, the V6 script changes the mileposts the Android system uses to manage applications and the memory they occupy. I feel it does wonders on phones with low memory but still helps with newer devices with more memory like the TF101. One of the results of this change is to make the launcher be much less likely to be killed by the system when it tries to free up memory. So no more redraws when coming back to the launcher after running a big program or a bunch of smaller ones because the launcher is reloading.
Trouble is that ICS changed one of the parts of the memory equation and now it takes a bunch of work to keep the launcher in memory. But I did all the work and you can just get the results. The services.jar file that must be created for ICS has been made for you. And since the ICS ROM is odexed it turns out it is actually the services.odex file that must be replaced. Follow link for file:
http://forum.xda-developers.com/showpost.php?p=23423423&postcount=9055
If the script is new for you but you're interested in using it check out the first post in the thread for links to the latest version of the script and the 2nd post for all the info on what is needed for ICS.