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.
Related
Ahoy hoy.
Just a quickie, I'm using nprussell's lovely Villain 3.2 atm but I'm having an arse of a time pushing things over using adb because the system is always 99% full. Same goes with the other Eris-leak-based-ROMs.
Is this because the rom is based off of a system dump? And does anyone have any clues on how to free it up some...
I would be soooo grateful for any help.
you can try moving apps from /system/app to /data/app, for example google maps gives you 2.6 mb in /system... also check /system/bin and /system/xbin if you can get some stuff out there to /data/xbin. you can probably get ~10mb back easily. also check for stuff you don't need in /system/app (for me that would be twitter, stock, footprints, quickoffice). remember to delete the .odex aswell if there is one, not only the .apk.
Easier way?
Is there any easier way to remove stuff from system/app than remounting it like this?
Code:
mount -o remount,rw -t yaffs2 /dev/block/mtdblk3 /system
other than changing it in the rom before you flash it?
kendong2 said:
other than changing it in the rom before you flash it?
Click to expand...
Click to collapse
Yes, I'm talking pre-flashed.
try my latest rom, i have 14mb free which is about 9%
tricky
I tried moving some apps from /system/sd on Villain 3.3 and it works for apps that are not related to the core system .. so if you move google maps it will work
it is also possible to remove twitter, flickr, facebook .. etc .. (unless you need it)
but when I moved some (many) HTC apps I got fc's and the stock lock screen and so on
I knew it was a stupid idea anyway but I have never tried it so I had to see
anyway: dont remove and/or move core htc apps, they seem to highly depend on each other
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.
Hi, I'm a noob not only to Android but to Linux either. I'm aware this is probably a very old question, but I can't find a topic in wich is explained how to do this manually.
I'm using amarullz a2sd on Sandvold ICS beta 0.6.1.1, and it works fine, like most of you know, is magic works this way:
- system apps and data on nand
- apps and data on ext4
- all dalvik on nand.
So I get lot of space and very little lag.
The problem is: dalvik grows, and grows very fast, and worst of all, the system can't understand why at some point the internal memory have lot of space but it can't ever save the temp install file, or create the dalvik for a new app.
All this problems flush into the famigerate "invalid package file" error, for whose everyone has a different solution.
So we get: dalvik saturate nand = Android go crazy = users go crazy and make any sort of assertion on how to solve this (someone suggest a full wipe everytime this happen XD ).
The solution may be simple and obvious to all of you, but I'm a noob so let's pretend this is a great step for humanity: insert manually a script to put the dalvik too on ext4, on top of the pre-esistent amarullz one.
I googled some time and I come to this script that to me seems the best way:
Code:
su
cp -pr /data/dalvik-cache /system/sd
rm -r /data/dalvik-cache
ln -s /system/sd/dalvik-cache /data/dalvik-cache
(Ok I'm aware the cp is not necessary, but this way I have not to bother about rains of FC until I reboot and system recreate dex files).
That seems to do the magic... but here my two questions:
1) Simple matter: how to make this permanent on reboot? I have to insert it in a text file in init.d? the number on the file name count for the order of execution in respect to other scripts?
2) Not so simple (for me): why "/system/sd" ? I thought the path to the ext4 is "/sd-ext", so the correct dir is not something like "/sd-ext/my-dalvik" ??
If this is right, the correct script must be this way:
Code:
su
cp -pr /data/dalvik-cache /sd-ext/my-dalvik
rm -r /data/dalvik-cache
ln -s /sd-ext/my-dalvik /data/dalvik-cache
(Clearly the cp and rm parts will not be present in the boot script).
Am I right?
DISCLAIMER:
- I'm not discussing if amarullz is good or bad, every post on this subject will be ignored. I like it, I just want to change this thing.
- Posts that invite me to not install tons of apps and live a life of abnegation will be ignored as well.
- Sorry for my english
- Sorry if I'm verbose: I just want to be clear on the explanation.
I want to keep the Samsung camera app, but want to be able to switch to the Google camera app for photo sphere.
I know I can remount system rw, put the apk over there while the os is running, I'm kind of fuzzy on the general dynamics of what happens at the system level once that apk is over there (does it install somewhere else on boot, does it just reach in and use it, is this completely insane) If that is enough for it to run, how pissed are calls to the camera intent going to be?
Alternately, Is there any way to modify the Google camera as a user app that can just run like a camera app from the store? I don't expect I'll be able to use TiBackup and just convert itm just wondering if it's even possibile. (don't need to know how, just need to know if this is a reasonable direction to head)
Sorry for all the questions, If no one knows i'll go back to quietly waiting for my device so I can test. I kind of expect all this to be a bust since I don't see anyone else doing it.
Once u put the apk in the system changes take effect upon reboot.
sounds too complicated to me. I just flashed the 4.2 camera app and I had the app.
Ya.. thats the noob way.. your eventually gonna hafto learn what your doing to your phone when u flash those zips "blindly"
What I understand is you want to convert it to a internal app not a system app? Out can you give me a little more details
Sent from my SAMSUNG-SGH-I317 using Tapatalk 2
details
fabster530 said:
What I understand is you want to convert it to a internal app not a system app? Out can you give me a little more details
Sent from my SAMSUNG-SGH-I317 using Tapatalk 2
Click to expand...
Click to collapse
I just found that skynote rom has this, I may flash it. Essentially I love photosphere and used it quite a bit, but since switching out of my galaxy Nexus, I've found I really like the samsung camera more for everything well not photosphere. I'm rooted and marginally competent. (I've written a couple of apps that actually run from sdk.) I'm also greedy and want everything, so running both cameras side by side is ideal. Getting the stock google camera to a user app would be perfect.
I can toy with it, do you have advice?
Done! Mostly working.
doormouse said:
I just found that skynote rom has this, I may flash it. Essentially I love photosphere and used it quite a bit, but since switching out of my galaxy Nexus, I've found I really like the samsung camera more for everything well not photosphere. I'm rooted and marginally competent. (I've written a couple of apps that actually run from sdk.) I'm also greedy and want everything, so running both cameras side by side is ideal. Getting the stock google camera to a user app would be perfect.
I can toy with it, do you have advice?
Click to expand...
Click to collapse
Downloaded Skynote,
extracted
/system/app/GalleryGoogle.apk
/system/lib/libjni_mosaic.so
/system/lib/liblightcycle.so
/system/lib/libjni_filtershow_filters.so
crammed all that in
/mnt/extSdCard/LOST.DIR
mount -o remount,rw -t yaffs2 /dev/block/mmcblk0p13 /system
cd /mnt/extSdCard/LOST.DIR
cat GalleryGoogle.apk > /system/app/GalleryGoogle.apk
cat libjni_mosaic.so > /system/lib/libjni_mosaic.so
cat liblightcycle.so > /system/lib/liblightcycle.so
cat libjni_filtershow_filters.so > /system/lib/libjni_filtershow_filters.so
chmod 644 /system/app/GalleryGoogle.apk
chmod 644 /system/lib/libjni_mosaic.so
chmod 644 /system/lib/liblightcycle.so
chmod 644 /system/lib/libjni_filtershow_filters.so
mount -o remount,ro -t yaffs2 /dev/block/mmcblk0p13 /system
Just like skynote, works great except for the flash, don't use the flash on the google JB camera app, but spheres and panos work great!