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.
Related
Below are steps to increase your real ram by about 10%. Imagine your hero rom having about 10% more ram to work with!
Download bootimg:http://www.mediafire.com/?dvwmwyit4yn
Directions to install are below
Copy the bootimg on to your sdcard.
Go into recovery console and enter the commands below.
mount sdcard (enter)
mount system (enter)
flash_image boot /sdcard/boot.img (enter)
reboot
or install using Fastboot
Copy the bootimg on to your sdcard.
Go into fastboot and enter this command: fastboot flash boot bootmem.img
Check to see if your ram upgrade worked enter the below in terminal
su (enter)
cat /proc/meminfo (enter)
supposedly we are missing 18m of ram. we can have 128m. Lets figure out how to get that back? :-D
UPDATE :
daproy said:
Reuploaded the boot.img, and attached is the latest patch used to make the kernel.
MD5SUM 9e49829ad466b2f3adf9402bcba9c9c0
http://www.mediafire.com/?dvwmwyit4yn
http://drop.io/mempatch
Click to expand...
Click to collapse
Attachment:
http://forum.xda-developers.com/attachment.php?attachmentid=232380&d=1254152183
whats there to work out? Huanyu has already done it
alritewhadeva said:
whats there to work out? Huanyu has already done it
Click to expand...
Click to collapse
We need a tutorial. This is big and really no one knows about it. This is not swap we are talking about here. We are talking about real ram not virtual. This could help us with our roms.
····
How to do it?
If this works with no strings like(radio wont work as good or something like that), then I am all for it.
I think that is an issue if you recover to much ram. So far no complaints on using 106-109MB. If you use to much I think your phone will keep restarting its self until you change back the setting or flash a new rom.
Yea that's what I was reading like if you want like 15% more or something along those lines.
How does it run? Nothing noticeable right?
~~Tito~~ said:
Yea that's what I was reading like if you want like 15% more or something along those lines.
How does it run? Nothing noticeable right?
Click to expand...
Click to collapse
If your running Hero I am sure its noticeable. We are talking about 10% more real ram. Even though we have 10% more we might still need to use swap. But swap sucks its virtual.
Edit:
Yes its reversible.
Yea we still need to use swap since its a lot of stuff to handle. The Hero has 288mb ram, and we have a bit more than 1/2 of that.
Is it reversible if it goes into a bootloop?
I recompiled cyanogen's kernel with the change in board-trout.c to
mi->bank[0].size = (106*1024*1024);
and it boot looped as soon as the gpu was initialized. I am not sure how much ram you can actually squeeze out without stepping into the gpu's allocated space. I might give some other values a try tonight.
I'm running alla's mt3g ROM which has the extra ram hack on my mt3g and its running great.
http://forum.xda-developers.com/showthread.php?t=555499
Its just as fast as cyanogen's ROM and the extra RAM is definitely noticeable.
Where you can see the difference is browser refresh. Alla's ROM has compcache enabled by default just like cyanogen's ROM, but the browser refreshes much less frequently than CY's ROM. I'm also noticing foreground apps run smoother when music is streaming in the background.
I'm hoping cyanogen will incorporate this into his future releases. I haven't noticed any stability issues with this hack. Of course I've only been running it for a day or two. But so far, its been stable.
Same results on G1 with:
mi->bank[0].size = (104*1024*1024);
reboots at:
D/SurfaceFlinger( 2240): pid 2248 requesting gpu surface (current owner = -1)
Try 103. That should work.
maxisma said:
Try 103. That should work.
Click to expand...
Click to collapse
you know how to do this?
Ok I've dug a little deeper and indeed on the G1 the GPU1 memory (8M) comes directly after the linux memory (101M). Following the GPU1 memory is the RAM CONSOLE memory (128K). There is no space space between them. Increasing the size of the bank overwrites GPU1 memory and that's why it will boot loop. The total memory defined in the EBI bank is 110M and that pretty much eats it up other than 896K.
Is there any reason why you guys couldn't run RogerMod (or any Magic-specific ROM that includes the extended RAM) by doing the reverse of what we do to convert a Dream ROM?
i.e.
unpack rom zip
unpack boot.img
rename init.sapphire.rc to init.trout.rc (we would do this the other way round)
repack boot.img
repack rom zip
resign rom zip
???
It might be an interesting experiment to try, you'd be using a known good set of extended RAM settings and could see whether the concept can be applied to the Dream at all.
The memory map is compiled in the kernel for each separate board. Changing the init scripts won't do anything to the memory.
The EBI memory map is very similar on trout (dream/G1) to sapphire meaning biktor_gj's method of extending the linux memory on sapphire should overwrite GPU1 memory too, unless he moved GPU1 to some other memory location?
daproy said:
The EBI memory map is very similar on trout (dream/G1) to sapphire meaning biktor_gj's method of extending the linux memory on sapphire should overwrite GPU1 memory too, unless he moved GPU1 to some other memory location?
Click to expand...
Click to collapse
I have a modded Cyanogen Kernel with this RAM Mod and it works w/o reboots.
Only thing I've noticed is a lag in Hyperspace (3DGame), but I don't know if this is an issue of the kernel, but CM-Experimental itself.
maxisma said:
I have a modded Cyanogen Kernel with this RAM Mod and it works w/o reboots.
Only thing I've noticed is a lag in Hyperspace (3DGame), but I don't know if this is an issue of the kernel, but CM-Experimental itself.
Click to expand...
Click to collapse
hyper space works ok the 41.111.
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.
Please Read
This will not change anything on your phone that would prevent you from ever flashing a new rom or nandroiding back to a working one. Everything this update will do can completely be erased with a wipe or nandroid. Also flashing any rom, clean install or not, will preplace the boot.img this update.zip puts on your phone. So dont blame these downloads for your simple user errors of not being able to flash a new rom or nandroiding.
This is an overclocked kernel from toastcfh godmode .29 source. The kernel was actually pulled from Fresh Toast
This works on DamageControl and roms based off of his, it will not effect any of DC mods, including the Dconig app.
UPDATE
6/6/10- This should be working on the newest damagecontrol 2.09. Please report (if overclocking has worked in the past for you) if you have a problem on the newest release.
Click to expand...
Click to collapse
I made an attempt to get compcache to work, so it might or it might not. Someone with more experience might want to double check it.
Both include setcpu.txt for Setcpu OC app.. Select "custom" at the very bottom for device. Do not select hero. Or you can select "Auto Detect" at the top, this does not need the setcpu.txt.
*View attachment damage710v2.zip* THIS IS A TEST KERNEL FOR THE NEWEST DAMAGECONTROL 2.09.. It is the exact same as damage710 but with a newer ramdisk, this is in hope of fixing any problems anyone is having with 2.09 and OC kernel. There might not even be a difference in the new ramdisk between the old one. I didnt have time to check. Sooo ya.
*View attachment damage537.zip* 537mhz is the default.. scalable to 768 if you use an OC'ing app
*View attachment damage768.zip* 768mhz default clock speed -read below
*View attachment damage710.zip* 710mhz default clock speed -read below
Both can be scaled from 19.2 to 768mhz..
DAMAGE710--The damage710 will default 710mhz, you must use an OC app to scale it to 768. Use damage710 if your phone can not boot the 768mhz. And dont scale any higher then 710mhz or your phone might reboot.
DAMAGE768--If your phone can boot the 768mhz then either download will work. But if you dont want to use an OC'ing app then the damage768 will scale to 768mhz.
This IS a flashable update.zip.. This will only replace your boot.img of your phone. So it is not a full rom. This is applied on top of your rom.
ALWAYS MAKE A NANDROID BEFORE FLASHING.
You Do Not Need A Partition On Your Sdcard For Overclocking
THIS IS A MUST FOR SWAP/compcache
To get swap working, you must have an ext partition on your sdcard. This will format you sdcard erasing everything, so do the following. Back up everything from your sdcard to your computer(exp- In a folder on your desktop named Sdcard). In recovery, select partition sdcard, use all default values, 32mb swap, 512mb ext partition, the rest fat32. Then when its finished change ext2 to ext3. Then reboot the phone. And then move all the files you backed up to the computer back to your sdcard.
If thanking me for putting this together. You should also give an even bigger thanks to Toastcfh for this kernel.
Thanks also goes to flipzmode, cuz i pulled the kernel from his boot.img in fresh toast.
Also darchstar for the defaulting clock speed tip.
So does this mean we can get the real AOSP dialer on Damaged's ROM?
mattshaver said:
So does this mean we can get the real AOSP dialer on Damaged's ROM?
Click to expand...
Click to collapse
No.. this just adds overclocking and the few extra things that come along with it in the kernel. Has nothing to do with AOSP.
you rock
10 char
Excuse my ignorance on this topic.
But with Darchdroid, the issue was porting the Eris .29 Kernal to get a full hardware working AOSP Rom (I think) , so what is the difference?
My apologizes for taking up the space with my questions. Just a noob trying to get his facts straight.
If anyone wants to know how to do this, follow this guide starting at Step 8.
Essentially just extract the kernel you want from the right boot.img, extract the ramdisk from the other boot.img, then use mkbootfs and makebootimg to put them back together.
PM me if you need help.
mattshaver said:
Excuse my ignorance on this topic.
But with Darchdroid, the issue was porting the Eris .29 Kernal to get a full hardware working AOSP Rom (I think) , so what is the difference?
My apologizes for taking up the space with my questions. Just a noob trying to get his facts straight.
Click to expand...
Click to collapse
I dont mind, ask anything here. Its how we learn
But that was the issue with all 2.1 roms. Toastchf cracked the code (in a way, not literally). And was able to give us a working source for .29 kernel. That kernel can then be used to work on any cdma hero 2.1 rom. But there are different things you have to do to get it to work on Darchdroid AOSP rom, he has already done that and its in his newest release. This one I posted above is just to work with damagecontrol roms or ones based off of it.
To get the AOSP dialer working you would have to have a rom based on AOSP, which darchdroid is the only rom so far. All the other roms are based on htc framework or just something different then AOSP. But im pretty sure theres AOSP dialers for damagecontrol. Go check the apps and themes section.
EDIT: the dialers are also completely separate from the kernel. Its based on what the rom is.
i'm running ic3rom and in the process testing it out
jeremysterling said:
i'm running ic3rom and in the process testing it out
Click to expand...
Click to collapse
If you downloaded the compcache one, can you go into terminal and type
adb shell
free
Tell me if it says "swap" in what comes up and that it doesnt have all 0's.
ive been running the 2.07.2.3333 with jit enabled for weeks now flawlessly..... will flashing this zip cause the jit to stop working... or will they work in unison like i want? if its a one or the other deal ill just keep jit... thanks for your help
I think I may be confused as to what exactly the kernel's role/job is, as well as to what the drivers role/function are.
a kernel is what tells the hardware how to interact with the software, and drivers are what tell the software how to interact with the hardware? Correct?
So, why would it take a different kernel to run a full AOSP ROM? Why not just write new drivers for the difference of hardware?
On another topic. The framework would be comparable to what CounterStike is to Half-Life. It still uses the underling software, but is modified and branded in its own way as to give such a "proprietary" feel?
I am so confused. (Google here I come)
schmooo said:
ive been running the 2.07.2.3333 with jit enabled for weeks now flawlessly..... will flashing this zip cause the jit to stop working... or will they work in unison like i want? if its a one or the other deal ill just keep jit... thanks for your help
Click to expand...
Click to collapse
It doesnt effect jit at all. It only adds a few files and changes your boot.img.
schmooo said:
ive been running the 2.07.2.3333 with jit enabled for weeks now flawlessly..... will flashing this zip cause the jit to stop working... or will they work in unison like i want? if its a one or the other deal ill just keep jit... thanks for your help
Click to expand...
Click to collapse
JIT is controlled by other variables, namely build.prop and the dalvikvm.so library; it won't hinder those settings at all.
Jus10o said:
If you downloaded the compcache one, can you go into terminal and type
adb shell
free
Tell me if it says "swap" in what comes up and that it doesnt have all 0's.
Click to expand...
Click to collapse
i used adb on my computer (not sure if that makes a difference):
C:\androidsdk\tools>adb shell
# free
free
total used free shared buffers
Mem: 195764 193404 2360 0 7384
Swap: 0 0 0
Total: 195764 193404 2360
#
Re: [KERNEL] Toast-godmode .29 source for DamageControl
So I can flash this and oc icerom? Etc....
-------------------------------------
Sent via the XDA Tapatalk App
mattshaver said:
I think I may be confused as to what exactly the kernel's role/job is, as well as to what the drivers role/function are.
a kernel is what tells the hardware how to interact with the software, and drivers are what tell the software how to interact with the hardware? Correct?
So, why would it take a different kernel to run a full AOSP ROM? Why not just write new drivers for the difference of hardware?
On another topic. The framework would be comparable to what CounterStike is to Half-Life. It still uses the underling software, but is modified and branded in its own way as to give such a "proprietary" feel?
I am so confused. (Google here I come)
Click to expand...
Click to collapse
Haha well you are right sorta on what the kernel does, but all cdma htc heros use the same kernels but it depends on what android version you are using. 1.5 uses .27 kernel, and 2.1 can use a edited .27 kernel but something things wont work, like camera. What toast did was made his own .29 kernel based on other sources and what we already have then we use for our 2.1 roms. The 2.1 roms that come from sprint use a .29 kernel that work, but we cant edited anything within the kernel until they release the source to the kernel. You must have source to the kernel to be able to change anything with in it. You cant download a rom from xda and take the kernel out and change the files and put them back. You have to already have the files to the kernel, change what you want, make your own kernel and then put it on the rom. Cuz once you compile the kernel its not able to be opened back up.
In a boot.img there are 2 parts, the kernel and a ramdisk. The ramdisk CAN be opened back up and changed. But if its trying to call something within the kernel it has to already be there, since you cant add anything to it. If you start with all the kernel files and compile your own like what toast did, then you can add the special things like overclocking frequencies.
I know I really suck at explaining things. I only know the basics of how it all works.
jeremysterling said:
i used adb on my computer (not sure if that makes a difference):
C:\androidsdk\tools>adb shell
# free
free
total used free shared buffers
Mem: 195764 193404 2360 0 7384
Swap: 0 0 0
Total: 195764 193404 2360
#
Click to expand...
Click to collapse
And you have the compcache.. or the newer one i posted?
Jus10o said:
It doesnt effect jit at all. It only adds a few files and changes your boot.img.
Click to expand...
Click to collapse
Decad3nce said:
JIT is controlled by other variables, namely build.prop and the dalvikvm.so library; it won't hinder those settings at all.
Click to expand...
Click to collapse
sweet im gonna give it a try
Jus10o said:
And you have the compcache.. or the newer one i posted?
Click to expand...
Click to collapse
i downloaded and flashed damage1.zip with compcache
jeremysterling said:
i downloaded and flashed damage1.zip with compcache
Click to expand...
Click to collapse
Ok thanks.. yea compcache and swap arent working. Ill work on it.
But overclocking and everything else is. So its not gunna make a noticeable difference.
Introducing...
Darktremor Apps2SD 2.7.5.3 Beta 04
Date of Release: January 29, 2011
Download Current Version
Instructions - Change Log - Commands - ROM List - Developer's Guide
Darktremor Apps2SD Fan Page ----
Darktremor Apps2SD Development Group
Are you installing Darktremor Apps2SD on your phone? Here are the instructions to help you: Facebook
Are you a developer wanting to include Darktremor Apps2SD in your latest ROM? Here is the Developer Guide: Facebook
Click to expand...
Click to collapse
Update on Beta 4
It seems I'm getting mixed results with these betas. I'm not sure why this is occurring, some people have been able to get this working right while others have had a hard time with it.
Currently, I'm rebuilding the entire program. This takes a while because I have to figure out how to pack all these options into the program but make it small enough to where it will run correctly.
I will say that some of the beta features are coming back out...one of them is the search for a partition code. I suspect that code may be leading me into issues with certain platforms, so I'm going back to the 2.7.5.2 method of mounting (mmcblk0p2 or mmcblk1p2).
Also, parts of the code will use Busybox Ash (the only code that won't will be starta2sd, which will still use Bash for the time being). The startup code will definitely use Busybox Ash.
Until then, here are the links to the the last two betas and the last official release:
Version 2.7.5.3 Beta 04 - http://www.darktremor.info/files/a2sd/dtapps2sd-2.7.5.3-beta04-signed.zip
Version 2.7.5.3 Beta 03 - http://www.darktremor.info/files/a2sd/dtapps2sd-2.7.5.3-beta03-signed.zip
Version 2.7.5.2-1 - http://www.darktremor.info/files/a2sd/dtapps2sd-2.7.5.2-1-signed.zip
And, if you want past versions, you can view the repository: ftp://dtuser:[email protected] (ignore the smiley face...that's XDA doing that.)
Click to expand...
Click to collapse
Beta 04 took longer than I expected to release. I have done major changes to the code:
1. New commands: convert-ext4 - This will convert your EXT3 partition into EXT4. Just a friendly reminder on this command: Not every rom supports EXT4, so it is possible to go into a boot loop if you switch roms. Use with caution.
2. Reworked convert-ext3 (convert-ext4 gets similar code)...now a flag file is set before the reboot (no conversion is done before the reboot). At load time, the conversion is performed. This takes longer in the reboot process and you may think your phone has locked up...wait about five minutes before doing anything with the phone.
3. Repair is rebuilt...now it uses existing commands to repair the setup (reinstall, remove, cachesd, cachepart, nocache, datasd, nodata). Definitely shrinks the code.
4. Added fix_permissions program to the package. This may help with Superuser issues when using the datasd feature. It is used in reinstall, remove, datasd and nodata.
5. a2sd install is back!!! Both a2sd install and a2sd reinstall do the exact same thing.
6. Dalvik heap code has been shrunk and now creates a file called dalvikheap. Actually, the code has been doing this all along (since about 2.7.5.2, I think), but I never put the code in to use the file.
7. Low Memory Killer code has also been shrunk and uses a file caled dtset_lowmem to set the low memory killer parameter.
8. Replaced Busybox PS function with Toolbox PS. The issue with Busybox PS is that it gives a false reading when I look for android.process.acore (which is the main program when the GUI starts up). If that is present, the program thinks you are trying to run Darktremor without any command line parameters. This was because Busybox would report the process was there when, in reality, it wasn't (validated this when my phone was boot looping.) Toolbox's PS reports the correct setting. This should fix the bootlooping issues some people are experiencing.
9. New commands: usedtbusybox and usedefaultbusybox - these commands may help in diagnosing issues that is may be related to the native Busybox on your rom. a2sd usedtbusybox will use the Busybox that is packaged with Darktremor. a2sd usedefaultbusybox will turn back on the scan behavior of the program introduced in Beta 03.
10. Support for Darktremor Apps2SD version 2.7 and earlier has been discontinued. To upgrade correctly from one of those versions, use version 2.7.5.3 Beta 03b or earlier.
11. Finally fixed stalled boot issues (or at least my tests with several roms says so.)
See the change log for additional details.
You will notice that if the program runs repair and finds a problem, it will correct the issue and reboot. You will see a second reboot when the dalvik-cache clears (this is to fix timing issues with CyanogenMod...I can't control that startup as well as I can other roms). This only happens if repair is ran or you flash a new rom (as repair will realign all data). If you are upgrading from a previous version of Darktremor, you should not see the reboots.
Click to expand...
Click to collapse
This is Darktremor Apps2SD, a multipurpose program that primarily allows a user to execute applications created for the Android OS on their Secure Digital card (with the proper setup...more on that later). But, Darktremor Apps2SD is all about stability. The goal is to be able for all users of the Android OS to be able to take advantage of a method to run their applications from a secure digital card.
But just because the Darktremor Apps2SD is all about stability, doesn't mean it isn't packed with features:
- Move applications (both free and paid) to the Secure Digital card.
- Move Dalvik Cache to run either from your Secure Digital card or from your cache partition and clears the cache on demand.
- Boot Loop Protection: prevents the phone from boot looping in the event the SD card could not be mounted.
- Dalvik JIT for faster performance on Roms which support it.
- User selectable sizes for the Dalvik heap sizes, allowing a user to freely optimize their system.
- Activate a swap partition on your SD card and sets how often the swap partition is utilized.
- Automatically fixes configuration issues.
- Users can check the free space on their SD card and check the installation to make sure all is setup correctly.
- Runs ZipAlign on demand...this makes your programs load faster.
- Built in help system for easy reference of commands.
- All features can also be reversed without repartitioning your Secure Digital card.
- New logging features assists in troubleshooting issues.
- Commands to set the Low Memory Killer feature at boot time. Great for those people who are the "set it and forget it" type.
- And more...
Darktremor Apps2SD is not the same as Froyo Apps2SD. Froyo Apps2SD creates a secure folder on the FAT32 section of your SD card (this is the section that you see when you mount your phone to your computer) and stores the programs there. This is nice as you don't have to do anything special with the phone, but it isn't backwards compatible with older versions of Android (Cupcake, Donut, Eclair) and, because of the way Froyo works, older programs not designed for Froyo will automatically stay on your internal storage (unless you install a program that forces the move to your SD card).
Darktremor Apps2SD takes a different approach. Based on the original CyanogenMod works, Darktremor Apps2SD uses symbolic linking to force Android into moving your applications to the SD card. Because Android will not allow anything to be ran from the FAT32 partition on your SD card (and, in Froyo, it will only allow you to run programs from a special folder), Darktremor utilizes filesystems called EXT2, EXT3 and EXT4. Each one of these filesystems is native to Linux (the operating system running Android), which allows you to run programs from them (same as, say, a computer running Ubuntu). This method is completely compatible with all versions of Android, including Froyo. In fact, you can run both the Darktremor Apps2SD and Froyo Apps2SD at the same time.
Check out the list of Roms that either have Darktremor Apps2SD installed or are compatible with Darktremor Apps2SD. Click on the link labeled ROM List at the top of this message.
Darktremor Apps2SD Installation Instructions
For the list of people that helped me test this on the various roms that use or can use Darktremor Apps2SD and the changelog: http://forum.xda-developers.com/showpost.php?p=7034326&postcount=3
Click to expand...
Click to collapse
The installation instructions can be found here: http://forum.xda-developers.com/showpost.php?p=7021325&postcount=2
Click to expand...
Click to collapse
If you want a list of commands for Apps2SD, type a2sd help.
Desire aint listed??
I don't have any roms using it in Desire...hence why I'm posting this. But:
Kurt666
- For testing on Pay's ROM for Desire v1.4 (HTC Desire)
Click to expand...
Click to collapse
So there is one rom that is tested with it.
I've checked a good segment of the roms here, and it should work just fine, especially the 2.7.5 version (as the swap, dalvik-cache and the applications are all separate functions now).
I'm trying to expand the program's scope. I have six different platforms that run it (21 roms total) and I have one Desire rom tested...but none actually using it (my fault...should've expanded this a month ago).
Nekromantik said:
Desire aint listed??
Click to expand...
Click to collapse
Backing up just now my Open Desire 1.5 on nandroid.
Going to be your guinea pig for Open Desire (AOSP)
I will paste the logcat output of my first boot (if there will be any)
Will try to test on modaco r3.1, wish me luck
Sent from my HTC Desire using Tapatalk
well, it seems that it changed... Nothing.
http://pastebin.com/6D346gwX
Maybe the chef was already using your script?
So it didn't work?
Sent from my HTC Desire using Tapatalk
antz88c said:
So it didn't work?
Sent from my HTC Desire using Tapatalk
Click to expand...
Click to collapse
It booted in the same time that it booted without applying the tremor script, and I think that the logcat was quite similar too.
And the free space reported is the same than before.
So, it didn't work, or it was already working before
EDIT:
I decompressed the script inside OSx, and I looked inside folders.
Well, it seems that the script didn't run at all, since I have no "a2sd" neither "app2sd" on my /system/bin.
REEDIT:
I ran it again, now it seems that it actually ran.
I will provide my new pastebin later
http://pastebin.com/mx3PsHwZ
First run, then I got a reset. Then it reset-loop. With the same message.
Sorry man, it isn't quite ready for AOSP it seems
Those are a couple of after-install output, it doesn't do much though.
http://pastebin.com/ZVx5svQj
Boot loop only here, nandroid back to my previous ROM.
Sent from my HTC Desire using Tapatalk
antz88c said:
Boot loop only here, nandroid back to my previous ROM.
Sent from my HTC Desire using Tapatalk
Click to expand...
Click to collapse
Please provide logcat, otherwise your test wil be useless to the developer.
This sounds very interesting, and I would like to try and help when I can, which probably won't be for a couple of days.
But........for when that day comes.......how do I do a logcat?
Sorry, I am still relatively new to the whole Android thing.
StuMcBill said:
This sounds very interesting, and I would like to try and help when I can, which probably won't be for a couple of days.
But........for when that day comes.......how do I do a logcat?
Sorry, I am still relatively new to the whole Android thing.
Click to expand...
Click to collapse
yes, i got a bootloop on defrost 1.8.
how to do a logcat?
bradputt said:
yes, i got a bootloop on defrost 1.8.
how to do a logcat?
Click to expand...
Click to collapse
decompress android sdk (check on google for the sdk package, is quite small), then go inside the "tools" folder (I assume you have already your drivers installed).
then go on command prompt, and
Code:
adb logcat
will show the logcat.
Code:
adb logcat > bootlog.txt
will create the boot log (you won't actually see anything on screen since the output is redirected on the txt file.
You can:
start your phone
type adb logcat
CTRL+C when the phone is booted.
It will automatically stop if a reset occurs.
Then you go on pastebin (search on google) and paste the txt inside the pastebin.
And you can provide here simply the pastebin url that you can find after the submit button.
Nope...I can tell that's not my script. That must be what's already in Modaco...which means it's another file I haven't caught on the renaming script.
Are you using Modaco?
gatsu_1981 said:
well, it seems that it changed... Nothing.
http://pastebin.com/6D346gwX
Maybe the chef was already using your script?
Click to expand...
Click to collapse
Last time I saw that message, root wasn't working correctly. At least it wasn't working correctly on my phone.
Is there something different relating to root on these phones? Does the boot sequence have root access to /system (or is this phone have nand protection on it? I know the Evo has that but can be circumvented).
That part is just a piece that moves other apps2sd/dalvik-cache/zipalign programs so they don't interfere...the 2.7.5 Preview Fix 2 also removes those files during the flashing process, so that part really is only a failsafe.
The main program comes after that part (04apps2sd for busybox run-parts, a2sd for direct run).
gatsu_1981 said:
http://pastebin.com/mx3PsHwZ
First run, then I got a reset. Then it reset-loop. With the same message.
Sorry man, it isn't quite ready for AOSP it seems
Those are a couple of after-install output, it doesn't do much though.
http://pastebin.com/ZVx5svQj
Click to expand...
Click to collapse
The important piece is the part after the realignment program...the one that starts with:
[*] Starting Darktremor Apps2SD version 2.7.5 preview fix 1
The lines after that one is the Apps2SD portion.
gatsu_1981 said:
http://pastebin.com/mx3PsHwZ
First run, then I got a reset. Then it reset-loop. With the same message.
Sorry man, it isn't quite ready for AOSP it seems
Those are a couple of after-install output, it doesn't do much though.
http://pastebin.com/ZVx5svQj
Click to expand...
Click to collapse
tkirton said:
The important piece is the part after the realignment program...the one that starts with:
[*] Starting Darktremor Apps2SD version 2.7.5 preview fix 1
The lines after that one is the Apps2SD portion.
Click to expand...
Click to collapse
I can't understand what you mean.
Do you need some other line from adb logcat output? Since there is no more lines after the * line it just keeps resetting.
Or are you telling that it's installed? If so, why it keeps resetting our phone on froyo?
If I can help please send more flashable version or update this thread, I already have my nandroid so testing it for you will be very quick.
EDIT: double post...sorry.
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