Related
I've been working on getting jit working in the hero, but have hit a wall... I can get my legend ROM to boot and run the setup wizard fine, except that as soon as sense comes along, the entire phone crashes
I'm using the libdvm.so from the g1 thread (the one called something to do with donuts )
I've tried this on my own ROM, benhaam's legendary alpha and RaiderX303's Rom. So I've tried an odexed and unodexed ROM, but both behave the same...
I know the cdma guys got this working, anyone got any suggestions on what I've missed?
I just tried this on vanillain some weeks ago and it was working out of the box, but never got it working on any senseroms
Got it working on HeroDroid 0.3, but it force closes on unlocking by sliding (double-hitting menu button works) and on screen switching, again, by sliding (works if you use pinch-to-zoom out, then selecting the screen you want). Everything else works smooth and fast, but these two problems are an extreme pain in the ass
I've made a JIT build, but there are still too many stability issues to use it in production (everyday use).
Thanks all. Guess this is one for my vanilla roms in future...
Anyone heard any more about dalvik turbo (the commercial product)?
Supposedly, it is for OEMs and manufacturers. I expect the company wants their product licensed by phone manufacturers such as HTC and Motorola (that would be a simple means of collecting recurring revenue). Although it would be nice if they offered it in the Marketplace.
Let me say that the library could work on many ROMs on many Android Devices that use similar processors.
This library may or may not work, I didn't compile it only figured out that it works on CyanogenMOD based on 1.6. since you are able to get booted it seems you are good to go.
Since the update of CyanogenMOD 4.2.15.x the library loops FCs, checking further revealed that some dex files of /data/dalvik-cache were relocated to /cache/dalvik-cache (you can check his wiki page on moving dalvik-cache).
Haven't found where the script is doing this yet and haven't asked either but we have a work around that basically moves the dex files to either /data/dalvik-cache or /system/sd/dalvik-cache (for apps2sd users) remove the /cache/dalvik-cache folder and create a symbolic link there instead.
Code:
ln -s /data/dalvik-cache /cache/dalvik-cache
or
Code:
ln -s /system/sd/dalvik-cache /cache/dalvik-cache
or both
Code:
ln -s /system/sd/dalvik-cache /data/dalvik-cache
ln -s /system/sd/dalvik-cache /cache/dalvik-cache
replace /data/dalvik-cache with /system/sd/dalvic-cache or vice versa (you really just want to get them in one location where ever your dex files are located should be your target.)
FYI, clearing your dex files seems to resolve stability issues.
Good luck, let me know if it works via a PM.
BTW the hack is called "Dusted Donuts"
anon2122 said:
the one called something to do with donuts
Click to expand...
Click to collapse
The cause (I think) is that binding /cache/dalvik-cache to /data/dalvik-cache or to /dev/block/mmcblock4 is failling with this library or apps2sd is causing it.
anon2122 said:
I've been working on getting jit working in the hero, but have hit a wall... I can get my legend ROM to boot and run the setup wizard fine, except that as soon as sense comes along, the entire phone crashes
I'm using the libdvm.so from the g1 thread (the one called something to do with donuts )
I've tried this on my own ROM, benhaam's legendary alpha and RaiderX303's Rom. So I've tried an odexed and unodexed ROM, but both behave the same...
I know the cdma guys got this working, anyone got any suggestions on what I've missed?
Click to expand...
Click to collapse
licknuts said:
Let me say that the library could work on many ROMs on many Android Devices that use similar processors.
This library may or may not work, I didn't compile it only figured out that it works on CyanogenMOD based on 1.6. since you are able to get booted it seems you are good to go.
Since the update of CyanogenMOD 4.2.15.x the library loops FCs, checking further revealed that some dex files of /data/dalvik-cache were relocated to /cache/dalvik-cache (you can check his wiki page on moving dalvik-cache).
Haven't found where the script is doing this yet and haven't asked either but we have a work around that basically moves the dex files to either /data/dalvik-cache or /system/sd/dalvik-cache (for apps2sd users) remove the /cache/dalvik-cache folder and create a symbolic link there instead.
Code:
ln -s /data/dalvik-cache /cache/dalvik-cache
or
Code:
ln -s /system/sd/dalvik-cache /cache/dalvik-cache
or both
Code:
ln -s /system/sd/dalvik-cache /data/dalvik-cache
ln -s /system/sd/dalvik-cache /cache/dalvik-cache
replace /data/dalvik-cache with /system/sd/dalvic-cache or vice versa (you really just want to get them in one location where ever your dex files are located should be your target.)
FYI, clearing your dex files seems to resolve stability issues.
Good luck, let me know if it works via a PM.
BTW the hack is called "Dusted Donuts"
The cause (I think) is that binding /cache/dalvik-cache to /data/dalvik-cache or to /dev/block/mmcblock4 is failling with this library or apps2sd is causing it.
Click to expand...
Click to collapse
Cheers for the info. I will take a look tonight on a build without A2SD (I've got one handy for this kind of thing...)
So, to confirm, I could quickly test this by pushing the libdvm.so file to the usual place (on a ROM with no A2SD) immediately after flashing it (ie. not booted after installing the ROM)
That should then, as far as I understand, do it. I take it that if I wipe dalvik cache before the install of the test ROM, there is no need to re-wipe the dalvik cache (no dex files should have been created)?
Then, I do 'ln -s /data/dalvik-cache /cache/dalvik-cache' to pop a redirect on the data folder?
Please let me know if I'm reading this right before I go and try it again, as I'd hate to try it and find out I was doing it wrong...
Cheers
just wanted to say, would be nice if you could keep the updates coming to this thread, as i am following it as well. just because of the reference to pm. thanks
kendong2 said:
just wanted to say, would be nice if you could keep the updates coming to this thread, as i am following it as well. just because of the reference to pm. thanks
Click to expand...
Click to collapse
No worries. I'll post anything on here, as I'm sure it's not just us that want to know if it works. I'm not doing anything hero related tonight, but maybe friday...
Must do some other work
It's Sense that's making issues..
rolle3k said:
It's Sense that's making issues..
Click to expand...
Click to collapse
Yup. I've not got time to flash tonight, but have you looked at some of the stuff posted by 'licknuts' on page 1? He suggests a couple of commands that should keep the optimised dex files in the right place using symlinks.
anon2122 said:
Yup. I've not got time to flash tonight, but have you looked at some of the stuff posted by 'licknuts' on page 1? He suggests a couple of commands that should keep the optimised dex files in the right place using symlinks.
Click to expand...
Click to collapse
Well, I was experimenting with that dalvik library on my own. Of course you have to clear the dalvik cache, it's just Sense that does not like to operate with jit enabled.
You can use jit without problems if you disable Sense and use androids default lockscreen, which is in my opinion much cooler anyway.
Interesting. How is it, stability-wise in vanilla config?
(I am considering releasing an 'add-on' unofficial update.zip for a couple of roms to make them vanilla with jit, but only if its really stable. I was thinking villain 3.4 and legendary 1.2
As small incremental updates that just remove the rosie & lockscreen and push the new libdvm.
Open question @all:
Any views in this? Would you want this as an add-on to existing roms if stable? Would you usr it? Suggestions welcome. Obviously this is just an idea. Would need to test and consult devs first...
anon2122 said:
Interesting. How is it, stability-wise in vanilla config?
(I am considering releasing an 'add-on' unofficial update.zip for a couple of roms to make them vanilla with jit, but only if its really stable. I was thinking villain 3.4 and legendary 1.2
As small incremental updates that just remove the rosie & lockscreen and push the new libdvm.
Open question @all:
Any views in this? Would you want this as an add-on to existing roms if stable? Would you usr it? Suggestions welcome. Obviously this is just an idea. Would need to test and consult devs first...
Click to expand...
Click to collapse
I would def. use it. I was playing around with it (managed it to open some applications/browse) and it was very fast. You can feel how much better it works.
the work around I posted is really catered specifically for CyanogenMOD 4.2.15.x based with Android 1.6 with some eclair bits thrown in but could work on older Android versions. Our work around was to deal with dex files being in two locations and it seemed that binding the two directories would break caused by the library or apps2sd script.
If you know where you dex files are for a particular ROM are located , easiest to try and put them in one location IF THEY ARE SPLIT up and create a symbolic link pointing to the single location, it might not be needed at all, I just don't have a Hero to test with and our Hero ROMs are brutal to run run with our G1s because of lack of memeory.
As for a Hero ROM if the dex files are in one location I think it should be good. Set the permissions, owner and group on the file.
##back up your original file incase it don't workout
cp /system/lib/libdvm.so /sdcard/dusted-donuts/bak/
## install from where ever you extracted from
cp -f /sdcard/dusted-donuts/lib/libdvm.so /system/lib/
## set owner permissions
chown 0:0 /system/lib/libdvm.so
chmod 644 /system/lib/libdvm.so
##only make a symbolic link if you had to move dex files from a different location..
ln -s /data/dalvik-cache /sdcard/sd/dalvik-cache
just an example.
This may be your best option for older Android builds.
Grab the vmlibs.zip extract the files and don't use the build.prop and copy the additional files as so back up your original files first incase it don't work.
assuming you extracted the files to a newly created /sdcard/vmlibs directory
cp -f /sdcard/vmlibs/bin/dalvikvm /system/bin/
cp -f /sdcard/vmlibs/libdvm.so /system/lib/
cp -f /sdcard/vmlibs/libdhelper.so /system/lib/
rm -f /data/dalvik-cache/*
Booting is slow like 5-10 minutes and if previously your tried the libdvm.so file and got the device to but and FCs, you may just need to find and additional work around.
these commands are for recovery console and terminal. might be a typos in there.
anon2122 said:
Cheers for the info. I will take a look tonight on a build without A2SD (I've got one handy for this kind of thing...)
So, to confirm, I could quickly test this by pushing the libdvm.so file to the usual place (on a ROM with no A2SD) immediately after flashing it (ie. not booted after installing the ROM)
That should then, as far as I understand, do it. I take it that if I wipe dalvik cache before the install of the test ROM, there is no need to re-wipe the dalvik cache (no dex files should have been created)?
Then, I do 'ln -s /data/dalvik-cache /cache/dalvik-cache' to pop a redirect on the data folder?
Please let me know if I'm reading this right before I go and try it again, as I'd hate to try it and find out I was doing it wrong...
Cheers
Click to expand...
Click to collapse
Been playing around with it now.
I had to remove the Hero Lockscreen by doing the following
Code:
# adb remount
# adb shell rm system/app/HtcLockScreen.apk
And I also had to disable Sense.
Once you did that, you can use JIT altho you will lack of the Sense Home screen.
Hmm, nice job. Give this this a try for the screen lock, have had similar issues with varrying apps and this seems to fix them especially when trying various Launcher.apk replacements. Really looking to clear the app settings found in /data/data somewhere the name does not have to match the app name so you may need to hunt for it in /data/data.
mount data for read write and backup your HtcLockScreen.apk to sdcard somwhere.
Code:
******optional**********
killall android.process.acore
***********************
rm -f /system/app/HtcLockScreen.apk
rm -f /data/dalvik-cache/*HtcLockScreen*
rm -fr /data/data/*HtcLockScreen*
cp -f /sdcard/backup/app/HtcLockScreen.apk /system/app/
chown 0:0 /system/app/HtcLockScreen.apk
chmod 644 /system/app/HtcLockScreen.apk
reboot
/sdcard/backup/app (replace the path with the location of a backup of the file.)
rolle3k said:
Been playing around with it now.
I had to remove the Hero Lockscreen by doing the following
Code:
# adb remount
# adb shell rm system/app/HtcLockScreen.apk
And I also had to disable Sense.
Once you did that, you can use JIT altho you will lack of the Sense Home screen.
Click to expand...
Click to collapse
Installed libdvm.so on aHero 0.4, a vanilla rom, everything works fine.
I've made a script that relocates all your apps into an EXT2 filesystem in /sdcard/andboot/apps.img.
Advantages
- Get a LOT of space for apps even if everything else is running in NAND
- Never need to reinstall apps when upgrading (as long as the release has this script)
- Dual boot, for example, Eclair in NAND, Froyo on SD-card, but share the same apps.
- Wipe data (all settings) but keep all the apps stays (but not their settings)
Disadvantages
- Propably a bit slower than keeping everything in NAND
- If you intend to keep apps when when upgradring/switching releases then odex:ing your Market apps is not a good idea when using this.
Attached is an update that should work on any Android build (for our devices). The script in the update is only used once to create /sdcard/andboot/apps.img. Once it exist, the init script in the new initrd.gz (included in the attached NBH for NAND users) will automaticly mount /sdcard/andboot/apps.img to /data/app on boot no matter what Android build you are using.
Instructions
1a. Flash the attached kernel (but configure it first if needed with Loserskaters NBH editor) (NAND Users)
1b. Replace andboot\initrd.gz (HaRET users)
2. Apply attached update (adds relocate_apps.sh to /system/bin)
3. Do this in a terminal:
$su
#relocate_apps.sh 256 (for 256Mb storage, the choice is yours)
<wait until it finishes>
That's it. Upon the next boot your old apps in /data/app will be deleted to free up space.
To uninstall, delete the apps.img file on the SD-card, then wipe your data.
I've done some testing and it seems to work fine. I'm currently dual booting VaniljEclair (NAND) and Fresh Froyo (SD-card instal) and they share the same apps. Works fine for me but I cannot guarantee that it is without bugs.
Known limitations
- Won't work with apps that installs to /data/app-private (like some banking apps) so you have to reinstall them if you switch build or wipe your data.
- You can't remove the SD-card without powering off the phone since your apps are now stored on it.
kallt_kaffe said:
I've made a script that relocates all your apps into EXT2 filesystem in /sdcard/andboot/apps.img.
Advantages
- Get a LOT of space for apps even if everything else is running in NAND
- Never need to reinstall apps when upgrading (as long as the release has this script)
- Dual boot, for example, Eclair in NAND, Froyo on SD-card, but share the same apps.
- Wipe data (all settings) but keep all the apps stays (but not their settings)
Disadvantages
- Propably a bit slower than keeping everything in NAND
- If you intend to keep apps when when upgradring/switching releases then odex:ing your Market apps is not a good idea when using this.
Attached is an update for VaniljEclair RLS10b but it could tweaked into any release if you know what you are doing ("/system/bin/relocate_apps.sh boot" needs to be executed early, could be done either in a userinit.sh if the build has one or set up as a run-once service in sysinit.rc)
Instructions
$su
#relocate_apps.sh 256 (for 256Mb storage, the choice is yours)
<wait until it finishes>
That's it. The final version will delete your old apps on the next reboot to free up space in /data but this experimental version does not do that.
THIS IS AN EXPERIMENTAL SCRIPT. USE IT AT YOUR OWN RISK.
Click to expand...
Click to collapse
Interesting....so to get it work on fresh froyo I need to add this line /system/bin/relocate_apps.sh boot into userinit.sh?
Also when could we expect the version that deletes apps from system after moving them to sd?
-Arturo- said:
Interesting....so to get it work on fresh froyo I need to add this line /system/bin/relocate_apps.sh boot into userinit.sh?
Click to expand...
Click to collapse
Not anymore, the new version has that part in the initrd.gz so it will work in ANY build without modifications once you've relocated your apps.
Also when could we expect the version that deletes apps from system after moving them to sd?
Click to expand...
Click to collapse
Right now.
If this works as well as it seems to do I will push my changes to the bootenv and tinboot repo's so that all new kernels will have support for this. I will also include the relocate_apps.sh script in next VaniljEclair release and push it to Fresh Froyo.
While I have never needed more space on /data I still find this very useful as I now only need to reinstall one single app (my banking app) when I reinstall my phone (which I do quite often).
btw, I'm using a 512Mb image for /data/apps right now I don't think I will ever come close to fill it up.
kaffe, can we put apps (only apps, data still on NAND) on a second ext2 partition instead ext2 filesystem? I think it will be faster.
kallt_kaffe said:
Not anymore, the new version has that part in the initrd.gz so it will work in ANY build without modifications once you've relocated your apps.
Click to expand...
Click to collapse
Just a quick question, i know i could just try it and find out for myself but with the new kernel, does it mount /data/app normally if the apps.img does not exist??
EDIT::
Just realised that it must do this for it to work the first time but i'm guessing at the minute there is no way to revert back to apps on the /data partition without wiping and starting a fresh.
Hi..thanks for the app.
I follow direction unitl the app.img was mounted and saw the msg saying /data will be deleted after reboot, but after reboot the internal memory is still the same. Any idea?
ps. I am running your 2.1 built (on polaris) so I didn't follow your step1, so maybe that is why it didn't work?
Cookiekaikai said:
Hi..thanks for the app.
I follow direction unitl the app.img was mounted and saw the msg saying /data will be deleted after reboot, but after reboot the internal memory is still the same. Any idea?
ps. I am running your 2.1 built (on polaris) so I didn't follow your step1, so maybe that is why it didn't work?
Click to expand...
Click to collapse
Are you saying you didn't flash the kernel provided?? If so the apps.img on the sdcard will not be mounted. You need to modify the kernel NBH with the NBH editor to work with Polaris, flash it and try again. Sorry if i misunderstood and you have already done this.
Can the kernel file you attached be used for vogue at 320x240 res?
edit: actually, if it's not too much trouble...could you explain how to get this working on a vogue froyo nand 320x240? Thanks!
kallt_kaffe said:
Not anymore, the new version has that part in the initrd.gz so it will work in ANY build without modifications once you've relocated your apps.
Right now.
If this works as well as it seems to do I will push my changes to the bootenv and tinboot repo's so that all new kernels will have support for this. I will also include the relocate_apps.sh script in next VaniljEclair release and push it to Fresh Froyo.
While I have never needed more space on /data I still find this very useful as I now only need to reinstall one single app (my banking app) when I reinstall my phone (which I do quite often).
btw, I'm using a 512Mb image for /data/apps right now I don't think I will ever come close to fill it up.
Click to expand...
Click to collapse
Ok seems to be working fine for me with 512 image. Will report back in a few days.
scooter1556 said:
Are you saying you didn't flash the kernel provided?? If so the apps.img on the sdcard will not be mounted. You need to modify the kernel NBH with the NBH editor to work with Polaris, flash it and try again. Sorry if i misunderstood and you have already done this.
Click to expand...
Click to collapse
I didn't flash the kernel because the file name says FROYO but I am running eclair. However I am pretty sure the file was created and mounted as well.
I do know how to use NBH editor but just want to be sure that the kernel is safe even if I am running eclair.
Thanks for the reply
UPDATE: never mind I forgot you can select eclair as type. I will report back once I am done with the rest of the steps. THX!
Cookiekaikai said:
I didn't flash the kernel because the file name says FROYO but I am running eclair. However I am pretty sure the file was created and mounted as well.
I do know how to use NBH editor but just want to be sure that the kernel is safe even if I am running eclair.
Thanks for the reply
Click to expand...
Click to collapse
Yes it's safe.i think Kalt has made all the required changes to make kernel work on both froyo and eclair.
Kalt I'm wondering about something.I've already created the image for apps but I'm not sure what's going to happen when I instal new applications.will they automatically be moved to the image or do I have to run the script after ever installation off apk file?
tuannam said:
kaffe, can we put apps (only apps, data still on NAND) on a second ext2 partition instead ext2 filesystem? I think it will be faster.
Click to expand...
Click to collapse
It would propably be a little bit faster but it will be a lot more complicated to make and perhaps even more complicated to use. We allready have a de facto standard with this partitioning:
part 1 - FAT32
part 2 - system
part 3 - data
part 4 - swap
Now, not many uses swap on SD-card so we could propably say partition 4 should be used for this, right? But then we also would need to now that partition 4 really is ext2 and is having apps on it before we mount it. And it is also quite complicated for most people to partition their SD-cards in the first place.
So basicly, what I'm saying is that it propably could make small difference in performance but I'm not convinced it would be worth it. The way it works now is pretty safe as it won't do anything unless /sdcard/andboot/apps.img exist and setting it up is a simple one-liner in the terminal.
On the other hand an advanced user could set up their own apps on ext2-partition manually and add some lines to userinit.sh that mounts it.
So I don't know, at least I don't have any plans to add it at the moment. Perhaps someone could add it later if the advantages turns out to be big enough to make it worth it.
EDIT: Another aspect is that /data/app is only written to when installing, all other accesses should be only reads. All writing to /data is still in NAND so I really think the performance penalty is minimal. I haven't been able to tell the difference myself.
scooter1556 said:
Just a quick question, i know i could just try it and find out for myself but with the new kernel, does it mount /data/app normally if the apps.img does not exist??
EDIT::
Just realised that it must do this for it to work the first time but i'm guessing at the minute there is no way to revert back to apps on the /data partition without wiping and starting a fresh.
Click to expand...
Click to collapse
Your logic is correct.
Cookiekaikai said:
UPDATE: never mind I forgot you can select eclair as type. I will report back once I am done with the rest of the steps. THX!
Click to expand...
Click to collapse
If you are using the latest VaniljEclair then use a Froyo kernel. With the latest version of the libcamera.so the Froyo kernel can and should be used to get the extra 11Mb of memory.
-Arturo- said:
Yes it's safe.i think Kalt has made all the required changes to make kernel work on both froyo and eclair.
Kalt I'm wondering about something.I've already created the image for apps but I'm not sure what's going to happen when I instal new applications.will they automatically be moved to the image or do I have to run the script after ever installation off apk file?
Click to expand...
Click to collapse
As long as you have the new kernel and have run the script once then everything you install will end up i apps.img.
I must be doing something wrong. I flashed the new kernel, performed the update then ran the script(saw the /data/app copied screen and was told after reboot it would take effect, but internal memory is still going down after reboot).
UPDATE: after doing some PD I found the app.img disappeared from andboot. Not sure what is going on but i am recreating another one now.
Played around with this, and I think it's working on my vogue... ~60mb free on phone. Performance isn't too bad. Thanks!
kallt_kaffe said:
As long as you have the new kernel and have run the script once then everything you install will end up i apps.img.
Click to expand...
Click to collapse
Kalt I have a feeling that the script messes up compcache(it could also be the new cell location patch) My sd card is not recognized after restart of the system with compcache enabled. I remember that we had already suffered with this problem and you fixed it by adding 120 s delay to the script. I've notice that with apk image the system takes a bit more time to boot and load widgets in comparison to apks on nand. Could that be the problem? I would like to increase the delay in compcache script to maybe 180 seconds or so to see if it fixes the issue.
What should i change in this script to change the delay time?
Does this 2>&1 stands for 120 seconds?
Code:
#!/system/bin/sh
#
# Compcache manager
#
#
# Change these variables to tweak the compcache
#
opts= # Use default (25% of the avaliable RAM (~23-24Mb))
#opts='disksize_kb=16384' # 16Mb compcache
#opts='disksize_kb=32768' # 32Mb compcache
#opts='backing_swap=/dev/block/mmcblk0p4' # compcache (default size 15% of available RAM) + backing swap (on SD card)
#opts='backing_swap=/dev/block/mmcblk0p4 memlimit_kb=32768' # 32Mb compcache + backing swap (on SD card)
# Swappiness
swappy=30
case "$1" in
start)
sleep 120
insmod /system/lib/modules/lzo_compress.ko >/dev/null 2>&1
insmod /system/lib/modules/lzo_decompress.ko >/dev/null 2>&1
insmod /system/lib/modules/xvmalloc.ko >/dev/null 2>&1
insmod /system/lib/modules/ramzswap.ko $opts >/dev/null 2>&1
swapon /dev/block/ramzswap0
sysctl -w vm.swappiness=$swappy
;;
stop)
swapoff /dev/block/ramzswap0
;;
enable)
setprop persist.service.compcache 1
echo "Compcache will be enabled in 120 seconds."
;;
disable)
setprop persist.service.compcache 0
;;
*)
echo "Usage: $0 {start|stop}"
exit 1
esac
exit 0
Thanks
-Arturo- said:
Kalt I have a feeling that the script messes up compcache(it could also be the new cell location patch) My sd card is not recognized after restart of the system with compcache enabled. I remember that we had already suffered with this problem and you fixed it by adding 120 s delay to the script. I've notice that with apk image the system takes a bit more time to boot and load widgets in comparison to apks on nand. Could that be the problem? I would like to increase the delay in compcache script to maybe 180 seconds or so to see if it fixes the issue.
What should i change in this script to change the delay time?
Does this 2>&1 stands for 120 seconds?
Code:
#!/system/bin/sh
#
# Compcache manager
#
#
# Change these variables to tweak the compcache
#
opts= # Use default (25% of the avaliable RAM (~23-24Mb))
#opts='disksize_kb=16384' # 16Mb compcache
#opts='disksize_kb=32768' # 32Mb compcache
#opts='backing_swap=/dev/block/mmcblk0p4' # compcache (default size 15% of available RAM) + backing swap (on SD card)
#opts='backing_swap=/dev/block/mmcblk0p4 memlimit_kb=32768' # 32Mb compcache + backing swap (on SD card)
# Swappiness
swappy=30
case "$1" in
start)
sleep 120
insmod /system/lib/modules/lzo_compress.ko >/dev/null 2>&1
insmod /system/lib/modules/lzo_decompress.ko >/dev/null 2>&1
insmod /system/lib/modules/xvmalloc.ko >/dev/null 2>&1
insmod /system/lib/modules/ramzswap.ko $opts >/dev/null 2>&1
swapon /dev/block/ramzswap0
sysctl -w vm.swappiness=$swappy
;;
stop)
swapoff /dev/block/ramzswap0
;;
enable)
setprop persist.service.compcache 1
echo "Compcache will be enabled in 120 seconds."
;;
disable)
setprop persist.service.compcache 0
;;
*)
echo "Usage: $0 {start|stop}"
exit 1
esac
exit 0
Thanks
Click to expand...
Click to collapse
How about the line "sleep 120".
I've experienced some strange things with this so far. I installed a new app this morning. Some hours later I got a freeze and pin-reset my phone. The new app was gone... The .apk is no longer in apps.img, not even in lost+found. The system however believes it is still installed and I cannot reinstall it.
I have now added the "sync" flag when mounting the sdcard in /init and I'll give it another try. With a little luck it might prevent it from happening again.
I attached the new NBH and initrd.gz here if anyone else experienced the same problem and want to give it another try.
Hey Devs,
As you may have noticed, I recently released a ROM with 276 MB free space on /data.
I accomplished this by using the MTD hack discovered by firerat and lbcoder.
It changes the kernel cmdline and includes addresses where the partitions are located.
This way, we are able to change the sizes.
That's exactly what I did.
The bad thing is that you need a recovery with a cmdline, which matches the ROM's boot.img's one!
So, a user needs to flash a recovery first and can then flash the ROM after a reboot into the new recovery.
Now, if the user wants to change his ROM to something else, he will need to revert the recovery.
It would be a lot easier if some other developers here would be interested in the MTD hack, so there is no need to revert.
I hope that some other developers will jump on the bandwagon now.
Here is the command I use for creating boot.img's, with modified partition sizes:
Code:
mkbootimg --kernel kernel --ramdisk ramdisk --cmdline 'mtdparts=msm_nand:[email protected](misc),[email protected](recovery),[email protected](boot),[email protected](system),[email protected](cache),[email protected](userdata)' -o boot.img --base 0x19200000
This reduces the /cache partition to 4 MB and makes /data as big as possible (the space which is left).
Now, the Market would normally fail to download huge APKs, because /cache is so small.
The problem can be easily solved by symlinking /cache to /data/cache and mounting the native cache partition on /dev/cache.
This can be done even without modifying the ramdisk, just do it in a script which runs before the Android frameworks start, like a2sd scripts.
Here are the necessary commands:
Code:
mount -o rw,remount /
umount /cache
rm -rf /cache
mkdir /data/cache
ln -s /data/cache /cache
mkdir /dev/cache
mount /dev/block/mtdblock4 /dev/cache
chmod 777 /data/cache
mount -o ro,remount /
Regarding the recovery:
Klothius from the Sapphire section created an update.zip which automatically patches the current recovery to use the provided cmdline.
You can find it here and include it in your instructions:
http://www.megaupload.com/?d=FY6CBAEE
I hope this little documentation will help you and will make you interested in doing this for your ROM.
Nice work. We'll look at implementing this into the next FroydVillain release. My only reservation would be keeping a wee bit more space on /cache than 4MB since our OTA app uses it. We could always hack it to use a dir on /data I suppose.
Hacre said:
Nice work. We'll look at implementing this into the next FroydVillain release. My only reservation would be keeping a wee bit more space on /cache than 4MB since our OTA app uses it. We could always hack it to use a dir on /data I suppose.
Click to expand...
Click to collapse
Yea, that would be better.. The whole purpose of this thread is to make things more compatible, means same cmdline Also you wll need to write the instructions for the recovery to /dev/cache then, keep that in mind
I will also add the RecoveryMod and an explanation in the documentation now.
I think the limitation of needing to switch recovery when changing ROMs is quite bothersome. Is there anyway we can get a recovery which supports both modes?
erasmux said:
I think the limitation of needing to switch recovery when changing ROMs is quite bothersome. Is there anyway we can get a recovery which supports both modes?
Click to expand...
Click to collapse
Sure, it can be done, but that would take a looot of work!
maxisma said:
Sure, it can be done, but that would take a looot of work!
Click to expand...
Click to collapse
More than I think it would be worth, to be honest. It'd make more sense for all the ROM developers to pull together on this and just make it a fact that we're giving more space to data, since it also eliminates the need to create fancy hacks moving dalvik to cache or to sdcard or splitting it between 2-3 file systems to cater for people who like to have the entire Android Market on their phone.
This has my/Villain's full support Maxisma, it makes perfect sense. Might I suggest you PM the other ROM developers here, or at least the popular ones like Fusion etc, and refer them to this thread so we can all work together on it.
Now that it's safe to assume that HTC have pretty much ditched the Hero, it makes sense for us to fix/improve -everything- including partition layout. There is a lot of wasted space in /cache that only gets used if a ROM developer starts fudging about with where dalvik lives, but /cache isn't quite big enough to completely migrate dalvik cache to for people who like to have a lot of apps.
Is there any more work on this? :d
shinyfong said:
Is there any more work on this? :d
Click to expand...
Click to collapse
I believe maxisma stopped work on it due to it breaking something or causing something not to work. I think he mentioned it in his Rom thread...
pulser_g2 said:
I believe maxisma stopped work on it due to it breaking something or causing something not to work. I think he mentioned it in his Rom thread...
Click to expand...
Click to collapse
It was me who broke it ;-) I accdidentally booted with a different mtd layout and thus killed all my data.
This method is perfectly fine though.
But I switched to a Nexus and I don't have a Hero anymore.
UPDATE: Another good news!! I'm currently testing an odexed version and so far it's holding very well with reboots, battery pulls and resets...I think this is because less data is written to dalvik-cache when it is odexed LOOKS LIKE WE ARE GETTING CLOSER TO A SOLUTION
--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
I've got some good news! It seems like I got the solution for data corruption on restarts, reboot and resets...I've done 5 reboots, 2 resets and I have not lost a single app on my Launcher. Not a single FC. This is with installation of System and Data on NAND with my data loaded with apps and widgets full on every screen (with pics, music, youtube, etc). I am also using l1q1d 11-27 kernel with my All Language ROM.
Here is my solution.
Since l1q1d put the cache on RAM, opening logcat shows that data written to our NAND is done more by "dalvik-cache" so I decided to move the "dalvik-cache to SD card with the following commands steps. Before I begin, I'll warn you that all your apps should be installed and updated coz if you do this you won't be able to install or update your any of your apps. Here it is:
Open up terminal
1. Type su
2. mkdir /sdcard/dalvik-cache
3. chmod 777 /sdcard/dalvik-cache
4. cp /data/dalvik-cache/* /sdcard/dalvik-cache
5. rm -rf /data/dalvik-cache
6 ln -s /sdcard/dalvik-cache /data/dalvik-cache
7. echo x > /data/.dalvikcache
LMK how it goes for you.
I am using l1q1d's latest kernel 11-27 with my All Language ROM.
Make that 5 reboots and 5 resets and 2 battery pull...still going strong but need to sleep now..
I don't doubt that this will help as it is the main directory which gets written to on the /data partition and can cause cycling and reboots if it gets corrupted or the phone is reset whilst it is still being written to but putting it on the sd card isn't an ideal solution for me. The reason i have data and system on NAND is so that i can unmount my sd card and have the phe unning as fast as possible wthout the bottlenecks caused by the card. I'm not sure there is much more benefit to this then just putting data on SD to start with, however, it will be worth looking into dalvik-cache and trying to get it more stable on NAND so good work
scooter1556 said:
I don't doubt that this will help as it is the main directory which gets written to on the /data partition and can cause cycling and reboots if it gets corrupted or the phone is reset whilst it is still being written to but putting it on the sd card isn't an ideal solution for me. The reason i have data and system on NAND is so that i can unmount my sd card and have the phe unning as fast as possible wthout the bottlenecks caused by the card. I'm not sure there is much more benefit to this then just putting data on SD to start with, however, it will be worth looking into dalvik-cache and trying to get it more stable on NAND so good work
Click to expand...
Click to collapse
Indeed..Looks like the inability to install and update makes data install to SD a better option. Regarding speed, I didn't notice any difference while having the dalvik-cache on SD, but I have a class 6 SD so that could be why. Looks like simply deleting dalvik-cache fixes everything for now. Re: making dalvik-cache more stable on NAND, do you think this is better done via kernel?
BTW, you think an Odex build would be better?
clemsyn said:
Indeed..Looks like the inability to install and update makes data install to SD a better option. Regarding speed, I didn't notice any difference while having the dalvik-cache on SD, but I have a class 6 SD so that could be why. Looks like simply deleting dalvik-cache fixes everything for now. Re: making dalvik-cache more stable on NAND, do you think this is better done via kernel?
BTW, you think an Odex build would be better?
Click to expand...
Click to collapse
How about... uhm....
mount a file for the dalvik cache like we used to mount a ext2 file ?
-o loop iirc..
BTW!!! chown 777 or chmod 777 ??
daedric said:
How about... uhm....
mount a file for the dalvik cache like we used to mount a ext2 file ?
-o loop iirc..
BTW!!! chown 777 or chmod 777 ??
Click to expand...
Click to collapse
It's chmod 777...Oopps looks like I made a typo. Thanks Daedric
I think I got a better solution that this. So far I have 5 reboots and 3 battery pulls and so far no FC. It seems like an ODEX'ed version is better. I think with the odex, there are less data written to dalvik-cache so it's more stable on reboots or resets... I'll continue testing but with a non-odex, I would get errors with loaded data and widgets. So far so good with odex'd. Looks like we are getting closer
I am using an HTC Desire. It was rooted a few days ago and I just installed CyanogenMod-7.0.3-Desire. In addition, I am a newbie in Android operating system. I am using LauncherPro
Here are some information about my HTC Desire
Baseband version: 32.44.00.32U_5.09.05.30_2
Mem info 217/405 MB
Internal storage: 38MB used, 110MB free
SD Card storage: 730MB used, 1,1GB free
Ram: 109MB used, 266MB free
I have been trying to download some certain applications: Adobe AIR, Flash player 10.3, Fruit Ninja but the downloads haven't started. The icon of downloading appeared for a few minutes then disappeared. I have been trying many ways to download those certain applications.
Can anyone help me with this problem ?
Has anyone been through this kind of problem ?
I am really appreciated for your help
That's happened to me sometimes when I had really poor signal.. try downloading over WiFi
bortak said:
That's happened to me sometimes when I had really poor signal.. try downloading over WiFi
Click to expand...
Click to collapse
I am using Wifi with strong signal but still, I was unable to download.
In terminal emulator type the following commands it worked for me on cm-7 and rcmix2.0
su
mount -o remount,rw /dev/block/mtdblock3 /
mkdir /sdcard/marketcache
mkdir /sdcard/marketcache/cache
mkdir /sdcard/marketcache/cache/webviewCache
cd /data/data/com.android.vending
rm -R cache
ln -s /sdcard/marketcache/cache cache
cd cache
ls
At this point make sure that you see webviewCache after you type ls
if you do, great, then you are all done and the market cache should now be stored onto you storage card.
Yeah i also have this problem sometimes but it usually happens when i have poor wifi signal .. what i do then is i press cancel ,press download again and get better position ... It works for me... Or reflash
altair_allen said:
I am using Wifi with strong signal but still, I was unable to download.
Click to expand...
Click to collapse
Thanks for your help but I am only still able to download low-byte applications <1MB. I am still unable to download Adobe AIR or Flash Player 10.3
Exiled_SouL said:
In terminal emulator type the following commands it worked for me on cm-7 and rcmix2.0
su
mount -o remount,rw /dev/block/mtdblock3 /
mkdir /sdcard/marketcache
mkdir /sdcard/marketcache/cache
mkdir /sdcard/marketcache/cache/webviewCache
cd /data/data/com.android.vending
rm -R cache
ln -s /sdcard/marketcache/cache cache
cd cache
ls
At this point make sure that you see webviewCache after you type ls
if you do, great, then you are all done and the market cache should now be stored onto you storage card.
Click to expand...
Click to collapse
Thanks for your help but I am only still able to download low-byte applications <1MB. I am still unable to download Adobe AIR or Flash Player 10.3
Maybe this thread offers you a working solution:
http://forum.xda-developers.com/showthread.php?t=934127