Hey guys,
Seems there's a lot of ways you can improve the speed of Android in general. Some seem to be snakeoil... others, work quite well and there's proof to back it up.
I'm only interested in discussing the latter .
A lot of people have helped me gather a better understanding of Android (hyc, stinebd to name a few) in addition to a lot of Google searching. I am going to compile a list of what I have done, I would like to hear what you guys have done! Most app killer apps / app control will already be addressed, so those tools need not apply... I'm looking for real, permanent fixes here without adding more apps!
I am also trying to have topics that are easy working up to advanced. Obviously the more advanced topics are going to be harder to do. You've been warned.
So here's the disclaimer.
****DISCLAIMER****
Speed is as always relative. That basically means I don't want arguments about which build is faster. I want to argue about how to make every build faster .
Also, these tips should apply to any build, any device... they are pretty generic tips, but are obviously specific to Android, with some idiosyncrasies that apply to our port that wouldn't apply to native Android devices. Some is common sense, others are real ways to tear into the system. Hope you enjoy it!
Topic 1
Difficulty Easy - Apps/Widgets
I've noticed the number of widgets i have on my screens, or the number of apps that I have installed/are running in the background to greatly effect performance, in an obviously negative way.
Once I removed all the widgets (I only have the basic analog clock widget & the Google search widget on one desktop...) this seemed to improve general speed. One minor thing to check is if apps are set to auto/background sync. Only enable the ones you really want syncing, others just check manually.
On this same topic, replacing the launcher (the stock launcher in Android, Launcher2 is quite slow) can help immensely. I like ADW, but I've used LauncherPro in the past and it is good. Zeam also seems like a good launcher. I haven't used Go Launcher EX, I've heard good and bad things about it. Use what works best for you, try 'em all!
The last thing on this topic I would like to mention is animations. Settings -> Display -> Animation -> No animations can make the phone feel quite a bit snappier, obviously at the expense of the look/feel of the OS.
Topic 2
Difficulty Easy - Controlling app 'net Access
This leads me into the next topic, DroidWall. I've noticed that blocking apps from accessing the internet has been a very good thing - it's not so much a performance booster (although it probably does provide a little bump) it's mostly about battery life. Just be warned, if you block an app that is set to background sync, it will probably have very negative effects. Only disable an app's access to the internet with DroidWall after you've checked that app's background sync feature is disabled. I have a few apps allowed in DroidWall, and the rest are blocked. You can "whitelist" everything and check apps you want to block, or "blacklist" everything and check the apps you want to allow. It's a little annoying to remember to enable/disable DroidWall (I use the DroidWall widget to enable/disable it globally) but if you do, it is much better - you have complete control over how apps access the 'net on your device. It is available on the Market.
Topic 3
Difficulty Moderate - SD cache/readahead tweaking
The only reason I'm calling this one 'moderate' is the number of choices you have for settings for this... It's basically telling the SD card how much to hold on to or... read "ahead" if you will . This was turned way up in FRX07, (from 256kb to 2048kb or 2mb...) and I think this might be the source of a lot of the complaints of 'mini-resets' if you will where the boot animation is suddenly seen after a long system hang...
So some cards will work better with a larger setting - I've heard some with spankin new C6 cards that said 3072kb or 3mb was a good setting. Others have found a sweet spot at 256kb or 1024kb (1mb).
There are two ways of doing this - you can hack the init in the rootfs and adjust the setting manually, or be lazy like me and use SD Booster (from the Market). Adjusts the same settings, and they are applied immediately!
I would like to find a "sweet spot" - a good default if you will. Can folks test out 512kb and 1024kb, see if you have any more mini-resets within Android or any other slowness, etc... Obviously this isn't a cure-all for the slowness or the mini-resets, what we're looking to do is mitigate the effects. So let's focus on that, thanks!
Topic 4
Difficulty Moderate - Overclocking
Overclocking is obviously one relatively easy way to improve the speed of Android. In your startup.txt, add a line
Code:
acpuclock.oc_freq_khz=710400
for example to overclock to 710.4mhz. How did I find this value? I actually put in 714000, but if you look at dmesg near the beginning you'll see "ACPU running at ..." - that's what clock is the actual maximum. It goes in 19.2khz increments.
Feel free to experiment with how high your phone can go, just be warned that the higher you go the potential for failure goes up as well . Phone shouldn't blow up, but it might not work correctly or at all. Rebooting and scaling it back will fix it.
Here's the full *example* startup.txt:
Code:
set ramsize 0x10000000
set ramaddr 0x10000000
set mtype 2292
set KERNEL zImage
set initrd initrd.gz
set cmdline "lcd.density=240 msmvkeyb_toggle=off gsensor_axis=2,1,3 pm.sleep_mode=1 physkeyboard=rhod400 acpuclock.oc_freq_khz=710400"
boot
You can put the command anywhere in the cmdline section, just make sure it's between the quotes and at least one space between each command.
Topic 5
Difficulty Advanced - How Android Manages Memory/apps
Ok, I'm going to take two approaches to this. The first, is the full explanation on how Android manages memory.
Please feel free to read the post I originally read that inspired me to start looking at this stuff - How to configure Android's *internal* taskkiller. It was very helpful for me to grasp how Android manages applications. This is the reason why application killers are not a good thing...
If you want to do it manually, Starfox suggests:
Code:
echo "1536,3072,8192,10240,12288,20480" > /sys/module/lowmemorykiller/parameters/minfree
To try to do these commands, adb is very useful. Once you get adb shell working, then you just need to "su" (provides 'super user' privileges (root)) and put in the echo command above ^^.
I had another user (thanks icevapor) suggest this script -
[Script] V6 SuperCharger! HTK & BulletProof Launchers! The ONLY Android MEMORY FIXER!
I tried it myself, and it works very well. This thread is a little overwhelming, but the jist of it is this:
Install Script Manager (on the Market)
Run the V6 SuperCharger script. I use "Aggressive 1 Settings" (#2) and then I use the OOM Grouping Fixes & "Hard to Kill" launcher (#17)
Point Script Manager to run /data/99SuperCharger.sh to run as root & on boot. This will ensure the tweaks are reapplied after a reboot.
Topic 6
Difficulty Advanced - Managing Apps that auto-start on boot
This is one of the most annoying things in Android. When you have no apps installed, it seems very fast. Then you install apps, and you never seem to get that original speed back... Now you can!
This is kind of difficult to do, I am still getting the hang of it... but here goes. All credit goes to hyc, his original post.
The basic idea here is you run a logcat (adb logcat is easiest here, or you can use GetLogs to pull logcat...) Look in this log for "for broadcast" and find apps that start on boot. For example,
Code:
Line 41: I/ActivityManager( 1394): Start proc nextapp.systempanel for broadcast nextapp.systempanel/.monitorservice.BootReceiver: pid=1752 uid=10060 gids={3003, 1015}
Notice there are two sides of the "for broadcast". The name of the package (nextapp.systempanel) and the name of the service, "nextapp.systempanel/.monitorservice.BootReceive". I made the mistake of disabling the app (the left side). Do not do this, you want to disable the right side!
So in the shell,
Code:
pm disable nextapp.systempanel/.monitorservice.BootReceive
This will be persistent across boots, it will go with your data.img.
Obviously this was just one example of an app to disable. So long as you disable the right side (after the 'for broadcast') you shouldn't disable anything that will cause a serious problem. The apps should still work, but for example if you disable Google Voice you won't get messages until you open the app. So think about that... You disable Titanium Backup schedules.BootReceiver, the schedules for Titanium Backup (if you have any) won't run. Stuff like that. Disable calendar, you won't get calendar events... Disable clock no alarms. Get it? Good. I have been rebooting several times, and I keep checking what is set to start on boot. I'm not quite happy with it yet, but there's some things I'm leery of disabling. Just be wary, if you do disable something and don't like it - just pm enable <whatever you disabled>.
Now experiment away! The one caveat is if you do break something with pm disable (and it's serious) you might get a failure to boot. It really depends on how bad you mess up. If you make a copy of your data.img before you start making these changes, you can revert to that data.img and start back there.
Alright guys. Going to use this thread as a way to brainstorm about ways to improve the speed. Read up what I've posted, let me know if I did anything wrong... Also let me know what you guys do to improve speed!
Don't care about what build you're running, this thread isn't about what build is fastest - this is a how do I make every build faster thread.
I've noticed Starfox's test kernel with that turbo mode enabled actually creates quite a boon. It's RHOD-only, so I didn't include it in the first post...
arrrghhh said:
Topic 4
Difficulty Advanced - How Android Manages Memory/apps.....
Right now I'm running (Thanks Starfox):
Code:
echo "1536,3072,8192,10240,12288,20480" > /sys/module/lowmemorykiller/parameters/minfree
.....
One word about durabilty:
If you change the settings like this, they are NOT PERMANENT.
Click to expand...
Click to collapse
I noticed that these settings are written in the /init.cfg/init.froyo.rc file. If I make the changes there, will they be permanent? Is this still the file that loads with FRX07? I am still playing with the settings so I have not tried to make anything permanent yet. I was trying to minimize the number of mini-reboots after an install. The new ext4 seems to help a lot, but I was still playing with this also.
vinceweis said:
I noticed that these settings are written in the /init.cfg/init.froyo.rc file. If I make the changes there, will they be permanent? Is this still the file that loads with FRX07? I am still playing with the settings so I have not tried to make anything permanent yet. I was trying to minimize the number of mini-reboots after an install. The new ext4 seems to help a lot, but I was still playing with this also.
Click to expand...
Click to collapse
Yea, that will definitely make them permanent.
I also thought using the user.conf file would, but someone PM'd me and said that didn't work...
I also was shown that there might be a much easier and more thorough way of doing that step... Seriously considering redoing that whole topic because of this:
[Script] V6 SuperCharger! HTK & BulletProof Launchers! The ONLY Android MEMORY FIXER!
I still need to verify if it works on my phone, but I don't see why it wouldn't...
Bah, it seemed to work but isn't persistent on a reboot... I'll try to figure out why. I see some issues with stock ROM's, so perhaps the issue is similar...
Edit - OK, using Script Manager I think I figured it out... I will update the first post with directions on how to use that "SuperCharger" script in lieu of the manual method.
arrrghhh said:
Yea, that will definitely make them permanent.
I also thought using the user.conf file would, but someone PM'd me and said that didn't work...
I also was shown that there might be a much easier and more thorough way of doing that step... Seriously considering redoing that whole topic because of this:
[Script] V6 SuperCharger! HTK & BulletProof Launchers! The ONLY Android MEMORY FIXER!
I still need to verify if it works on my phone, but I don't see why it wouldn't...
Bah, it seemed to work but isn't persistent on a reboot... I'll try to figure out why. I see some issues with stock ROM's, so perhaps the issue is similar...
Edit - OK, using Script Manager I think I figured it out... I will update the first post with directions on how to use that "SuperCharger" script in lieu of the manual method.
Click to expand...
Click to collapse
I went ahead and began using this script. Not sure if the phone is any speedier yet, as I just got the 99Charger script to run at boot using script manager. Will report back my findings. Im using the Aggressive 1 settings with launcher set to bulletproof.
ACoolGuy said:
I went ahead and began using this script. Not sure if the phone is any speedier yet, as I just got the 99Charger script to run at boot using script manager. Will report back my findings. Im using the Aggressive 1 settings with launcher set to bulletproof.
Click to expand...
Click to collapse
Yup, seems to reapply the settings correctly on a reboot. The only problem with Script Manager doing it is obviously the settings don't get applied until well into the boot process - well after the UI has come up.
Not the end of the world, at least it does get reapplied correctly now.
One last thing - in the article it seemed to indicate the 'bulletproof' method is no longer advisable, and the 'hard-to-kill' method should be utilized.
I'm going to rewrite the first post now.
arrrghhh said:
Yup, seems to reapply the settings correctly on a reboot. The only problem with Script Manager doing it is obviously the settings don't get applied until well into the boot process - well after the UI has come up.
Not the end of the world, at least it does get reapplied correctly now.
One last thing - in the article it seemed to indicate the 'bulletproof' method is no longer advisable, and the 'hard-to-kill' method should be utilized.
I'm going to rewrite the first post now.
Click to expand...
Click to collapse
I went ahead and set the launcher to hard to kill. Also I have manually editted /data/99Chargerminfree with your minfree values and it now boots with your minfree values, which im happier with. ill have to run it thru the paces to see if memory is managed as well as he claims.
autokiller memory
I've been using this app, AutoKiller Memory, from the marketplace and it seems to be working fine. You can put in the values you want for the 6 fields and in settings enable "apply settings on boot". I've ran
Code:
# cat /sys/module/lowmemorykiller/parameters/minfree
to double check after my reboots and without touching the app these changes took affect =). Of course like you said for script, it won't happen right at the start of the boot process.
nasapunk88 said:
I've been using this app, AutoKiller Memory, from the marketplace and it seems to be working fine. You can put in the values you want for the 6 fields and in settings enable "apply settings on boot". I've ran
Code:
# cat /sys/module/lowmemorykiller/parameters/minfree
to double check after my reboots and without touching the app these changes took affect =). Of course like you said for script, it won't happen right at the start of the boot process.
Click to expand...
Click to collapse
That app seems good. It just adjusts the underlying values for Android's memory management, which is exactly what we want. Kudos.
The reason I didn't want an app was a) I don't want more overhead and b) I wanted to have control over it. I wanted to be damned sure the values that were changing were what I wanted to change, and not something else.
arrrghhh said:
Difficulty Advanced - How Android Manages Memory/apps[/center]
Ok, I'm going to take two approaches to this. The first, is the full explanation on how Android manages memory.
Please feel free to read the post I originally read that inspired me to start looking at this stuff - How to configure Android's *internal* taskkiller. It was very helpful for me to grasp how Android manages applications. This is the reason why application killers are not a good thing...
If you want to do it manually, Starfox suggests:
Code:
echo "1536,3072,8192,10240,12288,20480" > /sys/module/lowmemorykiller/parameters/minfree
To try to do these commands, adb is very useful. Once you get adb shell working, then you just need to "su" (provides 'super user' privileges (root)) and put in the echo command above ^^.
I had another user (thanks icevapor) suggest this script -
[Script] V6 SuperCharger! HTK & BulletProof Launchers! The ONLY Android MEMORY FIXER!
I tried it myself, and it works very well. This thread is a little overwhelming, but the jist of it is this:
Install Script Manager (on the Market)
Run the V6 SuperCharger script. I use "Aggressive 1 Settings" (#2) and then I use the OOM Grouping Fixes & "Hard to Kill" launcher (#17)
Point Script Manager to run /data/99SuperCharger.sh to run as root & on boot. This will ensure the tweaks are reapplied after a reboot.
Click to expand...
Click to collapse
Seems to work fine, so far.
Edit: Have to use "Aggressive Setting 2", otherwise Xenonia 3 won't start.
arrrghhh said:
[Script] V6 SuperCharger! HTK & BulletProof Launchers! The ONLY Android MEMORY FIXER!
Click to expand...
Click to collapse
No launcher redraws? Assuming that means what it sounds like, I friggin hate those. That's a huge part of my android wait time. Can't wait to try this, thanks.
Found this script:
Ram Optimizer
Changed my froyo.user.conf to those settings (except lowlevelmemorykiller, using the supercharger script).
großa said:
Found this script:
Ram Optimizer
Changed my froyo.user.conf to those settings (except lowlevelmemorykiller, using the supercharger script).
Click to expand...
Click to collapse
Reading thru that, it seems redundant to that wacky SuperCharger script. OOM - already set, virtual memory - already set, and minfree - already set...
Honestly, that SuperCharger script does anything you could want in relation to memory/RAM. It's a little odd the way its laid out, and there's some qualms I have with how that guy arranged his post... but the script is all-encompassing. No need for others... they will literally bash heads with eachother... In the thread you linked to, it even mentions that if you've done other tweaks like this with other scripts, you should delete those scripts from init.d. So I would recommend the same, if you're going to use different scripts on boot, remove any other entries you have from the SuperCharger script. If you followed my directions, I use the startup script in /data/99SuperCharger.sh.
arrrghhh said:
Reading thru that, it seems redundant to that wacky SuperCharger script. OOM - already set, virtual memory - already set, and minfree - already set...
Honestly, that SuperCharger script does anything you could want in relation to memory/RAM. It's a little odd the way its laid out, and there's some qualms I have with how that guy arranged his post... but the script is all-encompassing. No need for others... they will literally bash heads with eachother... In the thread you linked to, it even mentions that if you've done other tweaks like this with other scripts, you should delete those scripts from init.d. So I would recommend the same, if you're going to use different scripts on boot, remove any other entries you have from the SuperCharger script. If you followed my directions, I use the startup script in /data/99SuperCharger.sh.
Click to expand...
Click to collapse
Yes I'm using the 99supercharger.sh on boot. I missed that supercharger also changes OOM and VM (thanks for the info), so I thought it can't hurt to change the froyo.user.conf directly. It should be logic, that 2 scripts, which do almost the same, will conflict.
BTW, did you try the 3G supercharger or the kickass kernel tweak?
I haven't had any launcher redraws since installing supercharger EXCEPT for keyboard induced orientation changes, which is a nice improvement for me. I'd like to get rid of the orientation change redraws too, since I gain nothing from the launcher itself going landscape anyway.
It did seem snappier, even not taking redraws into consideration. A link in the v6 thread claims the performance increase comes from the free ram being used to cache the filesystem. Not too clear on what "filesytem" means in this context (surely not the disk level filesystem, ext/ntfs/fat, I figure it must be linux terminology), still reading up on it, but if anyone felt like expounding a bit, I'd be grateful.
On this same topic, replacing the launcher (the stock launcher in Android, Launcher2 is quite slow) can help immensely. I like ADW, but I've used LauncherPro in the past and it is good. Zeam also seems like a good launcher. I haven't used Go Launcher EX, I've heard good and bad things about it. Use what works best for you, try 'em all!
Click to expand...
Click to collapse
I seem to recall from searches yesterday that there are a couple of 3rd party launchers that will let you lock in portrait orientation for the launcher only. I'll probably try Zeam later, don't see an option to lock against keyboard slide yet, but it's worth a try. Maybe if it switches back and forth faster, I won't need the lock.
My searches for a plaintext, no icon, no wallpaper launcher have come up empty so far. Zeam looks to have the smallest footprint. I've seen plaintext theme screenshots that I think was from LP+beautiful widgets, but what good is that if your footprint is still huge?
großa said:
BTW, did you try the 3G supercharger or the kickass kernel tweak?
Click to expand...
Click to collapse
I actually did not try those yet. It seemed like he had just started experimenting with that, and I was just trying to get the memory stuff hashed out.
Kinda wondering how it'll react with our build/kernels. But I guess it's worth a shot, worst case seems like a bootloop - might want to try it on an isolated setup before you move it to your main build . Let us know how it goes if you do try it!
fortunz said:
I haven't had any launcher redraws since installing supercharger EXCEPT for keyboard induced orientation changes, which is a nice improvement for me. I'd like to get rid of the orientation change redraws too, since I gain nothing from the launcher itself going landscape anyway.
It did seem snappier, even not taking redraws into consideration. A link in the v6 thread claims the performance increase comes from the free ram being used to cache the filesystem. Not too clear on what "filesytem" means in this context (surely not the disk level filesystem, ext/ntfs/fat, I figure it must be linux terminology), still reading up on it, but if anyone felt like expounding a bit, I'd be grateful.
Click to expand...
Click to collapse
Well, even tho we aren't using traditional file systems as you normally would, most of our files are in ext2. The data.img, the system.ext2 . I believe the rootfs.img is as well. They're just files that have entire file system structures and files underneath them - much like an ISO disc image if you're familiar with that concept.
fortunz said:
I seem to recall from searches yesterday that there are a couple of 3rd party launchers that will let you lock in portrait orientation for the launcher only. I'll probably try Zeam later, don't see an option to lock against keyboard slide yet, but it's worth a try. Maybe if it switches back and forth faster, I won't need the lock.
My searches for a plaintext, no icon, no wallpaper launcher have come up empty so far. Zeam looks to have the smallest footprint. I've seen plaintext theme screenshots that I think was from LP+beautiful widgets, but what good is that if your footprint is still huge?
Click to expand...
Click to collapse
I have heard good things about Zeam. I like ADW, but I haven't run much else than ADW and LauncherPro. Honestly only gave Zeam a whirl a few times, but it does seem snappy.
arrrghhh said:
I actually did not try those yet. It seemed like he had just started experimenting with that, and I was just trying to get the memory stuff hashed out.
Kinda wondering how it'll react with our build/kernels. But I guess it's worth a shot, worst case seems like a bootloop - might want to try it on an isolated setup before you move it to your main build . Let us know how it goes if you do try it!
Click to expand...
Click to collapse
Making a backup at the moment, gonna try it
Topic 5: doesn't show everything in autostart?!
Hmm, doesn't work properly:
Command:
'/system/etc/init.d/98kickasskernel'
-------------
Out:
exec sh '/system/etc/init.d/98kickasskernel'
/ # exec sh '/system/etc/init.d/98kickasskernel'
/ # exec sh '/system/etc/init.d/98kickasskernel'
sysctl: /etc/sysctl.conf: No such file or directory
mount: mounting none on /sys/kernel/debug failed: Device or resource busy
/system/etc/init.d/98kickasskernel: line 8: can't create /sys/kernel/debug/sched_features: Permission denied
vm.oom_kill_allocating_task = 0
vm.panic_on_oom = 0
vm.dirty_background_ratio = 60
vm.dirty_ratio = 95
vm.min_free_kbytes = 8192
vm.vfs_cache_pressure = 20
vm.overcommit_memory = 1
vm.min_free_order_shift = 4
kernel.panic = 0
kernel.panic_on_oops = 1
kernel.msgmni = 2048
kernel.msgmax = 64000
kernel.shmmax = 268435456
kernel.sem = 500 512000 64 2048
sysctl: error: 'kernel.sched_features' is an unknown key
kernel.hung_task_timeout_secs = 0
sysctl: error: 'kernel.sched_latency_ns' is an unknown key
sysctl: error: 'kernel.sched_min_granularity_ns' is an unknown key
sysctl: error: 'kernel.sched_wakeup_granularity_ns' is an unknown key
sysctl: error: 'kernel.sched_compat_yield' is an unknown key
sysctl: error: 'kernel.sched_shares_ratelimit' is an unknown key
sysctl: error: 'kernel.sched_child_runs_first' is an unknown key
kernel.threads-max = 5000
net.core.wmem_max = 524288
net.core.rmem_max = 524288
net.ipv4.tcp_tw_recycle = 1
net.ipv4.tcp_rmem = 6144 87380 524288
net.ipv4.tcp_wmem = 6144 87380 524288
vm.dirty_writeback_centisecs = 2000
vm.dirty_expire_centisecs = 1000
mount: mounting /dev/block/mmcblk0p1 on /card0 failed: No such file or directory
mount: can't find /proc/cmdline in /proc/mounts
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop0/queue/rotational: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop0/queue/iosched/low_latency: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop0/queue/iosched/back_seek_penalty: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop0/queue/iosched/back_seek_max: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop0/queue/iosched/slice_idle: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop0/queue/nr_requests: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop0/queue/iosched/fifo_batch: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop0/queue/iosched/quantum: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop1/queue/rotational: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop1/queue/iosched/low_latency: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop1/queue/iosched/back_seek_penalty: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop1/queue/iosched/back_seek_max: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop1/queue/iosched/slice_idle: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop1/queue/nr_requests: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop1/queue/iosched/fifo_batch: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop1/queue/iosched/quantum: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop2/queue/rotational: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop2/queue/iosched/low_latency: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop2/queue/iosched/back_seek_penalty: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop2/queue/iosched/back_seek_max: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop2/queue/iosched/slice_idle: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop2/queue/nr_requests: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop2/queue/iosched/fifo_batch: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop2/queue/iosched/quantum: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop3/queue/rotational: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop3/queue/iosched/low_latency: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop3/queue/iosched/back_seek_penalty: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop3/queue/iosched/back_seek_max: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop3/queue/iosched/slice_idle: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop3/queue/nr_requests: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop3/queue/iosched/fifo_batch: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop3/queue/iosched/quantum: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop4/queue/rotational: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop4/queue/iosched/low_latency: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop4/queue/iosched/back_seek_penalty: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop4/queue/iosched/back_seek_max: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop4/queue/iosched/slice_idle: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop4/queue/nr_requests: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop4/queue/iosched/fifo_batch: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop4/queue/iosched/quantum: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop5/queue/rotational: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop5/queue/iosched/low_latency: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop5/queue/iosched/back_seek_penalty: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop5/queue/iosched/back_seek_max: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop5/queue/iosched/slice_idle: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop5/queue/nr_requests: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop5/queue/iosched/fifo_batch: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop5/queue/iosched/quantum: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop6/queue/rotational: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop6/queue/iosched/low_latency: nonexistent directory
/system/etc/init.d/98kickasskernel: line 74: can't create /sys/block/loop6/queue/iosched/back_seek_penalty: nonexistent directory
Yikes, Zeam is snappy, right up until an orientation change redraw, then it's even slower than the default launcher. ADW might be better for me even at twice the footprint because I'm pretty sure I remember that one has an option to lock in portrait. I was at peace with redraws until I read this and managed to cut them down dramatically, and now that I have a taste of freedom, my contentment is shot and I need them eliminated entirely
arrrghhh said:
Well, even tho we aren't using traditional file systems as you normally would, most of our files are in ext2. The data.img, the system.ext2 . I believe the rootfs.img is as well. They're just files that have entire file system structures and files underneath them - much like an ISO disc image if you're familiar with that concept.
Click to expand...
Click to collapse
First, thanks for expounding. I am familiar with disk images/isos. Are you saying that underlying disk structure is what is being cached in "free" ram by linux? If so, I'm even more confused than before and maybe this is just beyond my ability to grasp. I assumed when he said the filesystem was being cached, it was a reference to actual files that happened to be called a filesystem in linuxese. Like registry type stuff or some such.
fortunz said:
First, thanks for expounding. I am familiar with disk images/isos. Are you saying that underlying disk structure is what is being cached in "free" ram by linux? If so, I'm even more confused than before and maybe this is just beyond my ability to grasp. I assumed when he said the filesystem was being cached, it was a reference to actual files that happened to be called a filesystem in linuxese. Like registry type stuff or some such.
Click to expand...
Click to collapse
Hrm, maybe I didn't explain that right.
Cache is basically a buffer to store things in. So Android uses cache to store frequently opened programs, etc. It keeps them in memory (RAM) as long as possible before it's necessary to free up that RAM.
So nothing is actually being cached on the file system, all is being cached in RAM. The hurdle here is the stuff that is being cached in RAM normally has to be accessed from the file system - but if it's already in RAM, it's much faster to access it that way than going thru the file system to find what it needs.
It's not the entire file system, just apps or any outside things they might be accessing. To keep it simple, we'll say just apps .
I hope that makes sense...
Related
Finally managed to build a zImage, but now trying to build a *.nbh file with it. I've git both bootenv, tinboot, and also the latest kernel commit for 2.6.32.
Compressed initrd.lzma down to 1.1MB (original initrd.lzma was about 950KB, but with it, still got the error), and my zImage is 1.9MB, but I continue to get this error whenever I run this:
Code:
./compilekaiser
Code:
tinboot.S: Assembler messages:
tinboot.S:142: Error: attempt to move .org backwards
./arm-none-eabi-objcopy: 'tinboot.o': No such file
cat: tinboot: No such file or directory
=== yang v1.1: Yet Another NBH Generator
=== (c) 2008 Pau Oliva Fora - pof @ XDA-Developers
[] Output NBH file: KAISIMG-PANEL3-320-TILT4-FROYO.NBH
[] Input files: output.nb
[] Input types: 0x400
[] SignMaxChunkSize: 64
[] Device: KAIS****
[] CID: 11111111
[] Version: 1.0.MARTIN
[] Language: WWE
[] 0x400 --> output.nb
Done!
I've done some searches, and found that I have to decrease the size of my initrd, but not sure what else to strip from it, and also my zImage is base built, and the size really doesn't change whenever I change any options in menuconfig.
Ok, the original question of this thread has been solved, but a new question...
I used the vogue.config file provided from the git, but everytime I flash the kernel, it just shows a black screen?
Is there anything I'm doing wrong, or better yet, any developer able to provide their .config file that they know works, so I can take a look what I'm configuring incorrectly and correct it?
Krazy-Killa said:
Ok, the original question of this thread has been solved, but a new question...
I used the vogue.config file provided from the git, but everytime I flash the kernel, it just shows a black screen?
Is there anything I'm doing wrong, or better yet, any developer able to provide their .config file that they know works, so I can take a look what I'm configuring incorrectly and correct it?
Click to expand...
Click to collapse
I use the default vogue config, then I use tinboot but I use the initrd.lzma from bootenv since sometimes people update that and forget to update tinboot. Then, after I have an image, I use atools to edit. I always resize the NAND partitions so that /system is almost completely full, and set /system and /data to auto so I can experiment with sdcard /data without reloading the kernel. I could probably find a way to set those in the build so I don't need to run atools, but I just use what I know works.
I haven't used my own kernel build since February 10. I have been using l1q1d's experimental kernel. I have seen kernel updates since then but haven't even checked to see what they are.
n2rjt said:
I use the default vogue config, then I use tinboot but I use the initrd.lzma from bootenv since sometimes people update that and forget to update tinboot. Then, after I have an image, I use atools to edit. I always resize the NAND partitions so that /system is almost completely full, and set /system and /data to auto so I can experiment with sdcard /data without reloading the kernel. I could probably find a way to set those in the build so I don't need to run atools, but I just use what I know works.
I haven't used my own kernel build since February 10. I have been using l1q1d's experimental kernel. I have seen kernel updates since then but haven't even checked to see what they are.
Click to expand...
Click to collapse
Thanks! Using the default initrd.lzma did the trick. Now if only the bootenv git was updated with this compressed initrd. xD
Currently using a custom kernel I built. Made some changes to yaffs2, mtd, and NAND configuration. Had a crash on initial boot, did a soft reset and phone came back with no corruption, and my "bad block 160" went away. I'm currently testing it for 24hrs, then if all goes well, I'm going to go a week and report back.
Though currently I have no bluetooth, as the module isn't loading.. Will look into that, and try and see if it's build related, and if the module can be loaded manually.
if you use the bluetooth as module it doesn't works, probably because it doesn't enable on boot the correct hardware part. You need to select it as built-in.
l1q1d said:
if you use the bluetooth as module it doesn't works, probably because it doesn't enable on boot the correct hardware part. You need to select it as built-in.
Click to expand...
Click to collapse
Currently bluetooth is not my concern, though I did get it running, by loading the modules manually using 'modprobe', but I have no idea how well the bluetooth subsystem works in its current state, but it does turn on, and do a search of nearby devices.
My main concern is my NAND configuration. So far no issues as of yet, but will know more when 1.5days elapses. Had an issue last night with the phone app crashing with acore failing, but coming back after rebooting the phone with no data loss.
Gmail app also crashed, but after 2 crashes it reloaded (possibly some data loss), and started re-syncing my email.
Besides those two, no real issues yet.
Krazy-Killa said:
Besides those two, no real issues yet.
Click to expand...
Click to collapse
What have you changed, just options in the defconfig?
scooter1556 said:
What have you changed, just options in the defconfig?
Click to expand...
Click to collapse
Enabled yaffs ECC support, but forced it to use the same ECC as the NAND driver. Enabled NAND ECC support inside the driver itself, as well as other changes.
Also left block refreshing, background processing, and left force chunk erase check enabled.
Had to disable EXT2, and EXT4 file system support to decrease kernel size, but for my case, don't need them as I'm using full NAND install anyways.
Currently approaching 18hrs, with no issues, installed more apps with no issues with corruption, still getting random FCs with core apps, but they re-enable afterwards (Most likely isolated, so not a real concern at the moment). Once i approach 18hrs, I'll do a safe reboot, and see what happens there.
My bad block 160 came back, but that's the only bad block that has returned, no new ones as of yet.
I'm hoping to concentrate my efforts on working on cpu scaling, whether it be using CPUFreq, or a kernel hack... I'm actually interested in knowing how Myn got his Rogue Tools to adjust the CPU Scale dynamically. As I'm thinking (though horrible at coding), of writing a kernel module to dynamically adjust the CPU core based on activity of the core.
If you ask Myn nicely he might send you a link to his sources. I believe he modified the kernel parameter in /sys or /proc (I always get those two confused). I know that the battery parameters with which i am most familiar can be modified dynamically that way.
Sent from my Android on HTC Kaiser using XDA App
n2rjt said:
If you ask Myn nicely he might send you a link to his sources. I believe he modified the kernel parameter in /sys or /proc (I always get those two confused). I know that the battery parameters with which i am most familiar can be modified dynamically that way.
Sent from my Android on HTC Kaiser using XDA App
Click to expand...
Click to collapse
I'll most likely contact Myn first chance I get. Been busy with family matters as of late.
Built a new kernel yesterday morning, and showing promise. Phone goes into a very deep sleep now (literally have to wait 5-10 seconds for the phone to respond like when a PC wakes from suspend), and actually shows improvement in battery life while in sleep mode but massive increase in battery usage when phone is waking, so may have to change how the phone sleeps.
Phone stability has increased as well. Despite the slow time it takes to wake, the phone has yet to crash, or slow down performance wise.
NAND is also showing improvement. Did a soft reset last night, phone restarted without problem, and no loss of data or any yaffs tragedy errors. Still installing apps at the moment. Data partition is at 45MB out of 101MB.
Free RAM is at 35MB while on home screen.
Currently using Radio 1.70.19.09, and HardSPL 3.56.
If all goes well, tonight I may post my kernel flavor as well.
*EDIT* Anyway that the bootenv git repo be updated with what's being used in initrd.lzma file?
Something went wrong?
I'm eager to test the kernel you have prepared.
Sent from my CyanogenMod Kaiser/Kaiser using XDA App
tiagoclc said:
Something went wrong?
I'm eager to test the kernel you have prepared.
Sent from my CyanogenMod Kaiser/Kaiser using XDA App
Click to expand...
Click to collapse
Currently running into a problem with the acore being corrupted, which doesn't make since as it's in /system.
I'm testing out having CompCache running but not JIT, as each time acore gets messed up the JIT was enabled.
If all goes well tomorrow, I may post the updated kernel and and androidupdate.tgz file with modules.
n2rjt said:
I use the default vogue config, then I use tinboot but I use the initrd.lzma from bootenv since sometimes people update that and forget to update tinboot. Then, after I have an image, I use atools to edit. I always resize the NAND partitions so that /system is almost completely full, and set /system and /data to auto so I can experiment with sdcard /data without reloading the kernel. I could probably find a way to set those in the build so I don't need to run atools, but I just use what I know works.
Click to expand...
Click to collapse
And now, I haven't been able to build a kernel that fits for quite a while.
The initrd.lzma is larger than I remember:
bootenv: 1011446 bytes
tinboot: 1011027 bytes
bootenv/initrd, smallest I can pack it is 1012491 bytes.
And zImage is 2006008 bytes.
I tried to make a smaller initrd.lzma by replacing all the duplicate files with symbolic links. That resulted in 1012491 bytes. I tried using hard links, but ended up with 1582661 bytes. I even tried unpacking the tinboot/initrd.lzma and repacking it, but no success.
n2rjt said:
If you ask Myn nicely he might send you a link to his sources. I believe he modified the kernel parameter in /sys or /proc (I always get those two confused). I know that the battery parameters with which i am most familiar can be modified dynamically that way.
Click to expand...
Click to collapse
An extract from RogueTools source code:
String outputFreq = "echo \"" + strFreq
+ "\" > /sys/module/clock_7x00/parameters/a11\n";
Can parted be moved from initrd to the android rom?
That saves a ton of space, and allows all to fit.
NO, parted is needed for atools - sd partitioner, i change both the 2.6.25 and the 2.5.32 to lzma initrd for it.
n2rjt said:
And now, I haven't been able to build a kernel that fits for quite a while.
The initrd.lzma is larger than I remember:
bootenv: 1011446 bytes
tinboot: 1011027 bytes
bootenv/initrd, smallest I can pack it is 1012491 bytes.
And zImage is 2006008 bytes.
I tried to make a smaller initrd.lzma by replacing all the duplicate files with symbolic links. That resulted in 1012491 bytes. I tried using hard links, but ended up with 1582661 bytes. I even tried unpacking the tinboot/initrd.lzma and repacking it, but no success.
An extract from RogueTools source code:
String outputFreq = "echo \"" + strFreq
+ "\" > /sys/module/clock_7x00/parameters/a11\n";
Click to expand...
Click to collapse
I haven't had a problem with repacking initrd.lzma. I've kept mine below 975KBs, which is perfect for me.
Also as far as using what Rogue Tools uses, I've determined it wouldn't be a good system to code, as it requires to phone to sleep first before the new clock settings take effect.
I'll continue to look into the cpu coding, to find why scaling is not being recognized by the kernel. For now, I'm going to try and downclock the cpu core to 250MHz to see how much of a difference I get in battery life, but I suspect I won't get much since the voltage isn't being changed.
Krazy-Killa said:
Ok, the original question of this thread has been solved, but a new question...
I used the vogue.config file provided from the git, but everytime I flash the kernel, it just shows a black screen?
Is there anything I'm doing wrong, or better yet, any developer able to provide their .config file that they know works, so I can take a look what I'm configuring incorrectly and correct it?
Click to expand...
Click to collapse
Hi! Could you share what you did to slove the problem "tinboot.S:142: Error: attempt to move .org backwards".Thank you in advance.
Kernel plus initrd are too large if you get that message. First be sure your initrd is built with hardlinks to busybox. If that is still too large try fewer kernel features. For me, the standard kernel and bootenv fit. What sizes are the zImage and initrd.lzma files for you?
Sent from my Android on HTC Kaiser using XDA App
Man I need to read up on all the new Linux stuff... I'm so far behind I'm getting lost.
Personally I want to pack initrd and everything else into a package along with a singular build (current 2.2 8/25/2011) and just make one install package for everything. That way I can pack the install, updates and kernel into one kaisimg.
Keep up the good work guys!!!
The starting idea is wrong!
The multiple file: the nbh for kernel and initrd and the tgz file are setted up for large compatibility (multiple device use them). So creating a nbh only for kaiser is a bad idea.
Also you need to create a nbh for every single parameter in atools (like screen, keyboard, panel) it's crazy!
Hi all,
I own no credits to this mod/script, it's all put together by zeppelinrox, Thanks go out to him for this! Orginal thread can be found here.
http://forum.xda-developers.com/showthread.php?t=991276
This is the first post of this kind I have ever made, so it might not be that good, or any help at all, but for those who want to try this script for the first time, I shall try my very best to explain how to do so.
I had been running ROMS for my Nexus with the V6 SuperCharger built in, and decided to see if it'll run well on our humble little Tabs. And indeed it does, it could be a placebo of course, but I seem to notice a good difference.
First, there are a few requirements in order to use this script :-
You NEED to be Rooted, in order to do this (if you aren't already) you could try the excellent Quick and Easy Root Script by the genius Crossix http://forum.xda-developers.com/showthread.php?t=1472521
Download and Install Script Manager from the Market
https://market.android.com/details?id=os.tools.scriptmanager
You also need to have BusyBox installed for the script to be run, I suggest installing the Script attached to the above V6 SuperCharger thread (even if you already have BusyBox installed to avoid errors). Simply scroll to the bottom of the thread and download the file named "busybox_v1.19.3_installer_script_wraithdu.zip"
To install this version of BusyBox navigate to where you saved the ZIP file, if on the Tab it should have downloaded to "/mnt/sdcard/Download", extract it using your file manager, I use ES File Explorer. Then open Script Manager and navigate to the extracted folder, find the script that should be called "busybox_v1.19.3_installer_wraithdu.sh", open this and select the "su" icon, make sure it is selected as a script and not executable.
To Run the Script:-
Scroll to the bottom of the SuperCharger thread and Download the file named " V6_SuperCharger_for_Android-update8.sh.txt" Navigate to where this file is downloaded, if on the Tab it should have downloaded to "/mnt/sdcard/Download", rename it using your favourite file manager, usually via a long-press to "V6_SuperCharger_for_Android-update8.sh"
Then open Script Manager and navigate to the script, open it using script manager, again taking care to run it as "su" as a script not an executable. The script should Run and prompt you for an option numbered 1-17. I chose Option 2, which is Aggressive Level 2 and noticed a good improvement, you can of course opt for the balanced options of 3 or 4. To input a number touch the screen and the on screen keyboard should pop up, hit a number and enter it.
The Script Should run and then prompt you for another option, don't choose another one just yet.
If you are running the excellent build.prop by Crossix, Icewyng et al, it is recommended to disable the device keeping Launcher in memory for the script to run properly. To do this, open Root Explorer, navigate to the build.prop, in "/system", and open it in the text editor. Scroll to the part of the prop file that begins "store launcher in memory" and change the below string to "ro.HOME_APP_ADJ=0"
In order for this to be a persistent change to how RAM is managed on our Tabs, a script has to be set up to be run at boot. To do this, in Script Manager, navigate to "/data" and open the script named "99SuperCharger.sh", and check the boxes of "su" along with "boot" to run it at boot.
After you have followed these steps reboot your Tab and you *should* see a snappier Tab
Please be aware that this is the very first HOW TO I have ever written, and it will probably be inaccurate and crap. So, please, feel free to correct my errors and I will try to help running the script.
Yours,
Toyface
Awesome scripts. Im going to give it a try here in a bit and see if there is a difference in performance.
Could someone confirm if this really works?
I just did this and have notices an improvement but do follow instructions carefully
Sent from my A500 using xda premium
I can't download the update 8 sh.txt file it just opens it in my browser
I used taptalk to download it it worked great and is still working its magic
Sent from my A500 using xda premium
Super huge improvement. Thank you!
rando152 said:
I can't download the update 8 sh.txt file it just opens it in my browser
Click to expand...
Click to collapse
Which browser are you using? If chrome on the PC, try a right click and save as a txt file and rename it as a file ending .sh
Sent from my A500
Thanks for all the cool info. Using info I found in sin threads Skype seems to stay running for hours now instead of just 15 Minutes.
Sent from my modified A100 using Tapatalk and SlideIT keyboard.
so far so good.
Just had time to get this installed. So far it seems to be a bit snappier. Wish i had thought to benchmark first. Grrrr....
I think this should be in the dev section, I might ask to have it promoted... Good Work!
Frankly the whole you cant modify his script deal is a HUGE turn off. I understand him wanting credit for his hard work, BUT wth. I'll stick to safer things.
EDIT: Forget what I said I completely miss understood what he says in his post. He says
"Personal Use: You may tweak the V6 installation script (leaving credits intact) to your own personal liking as long as it is NOT redistributed in any way."
His autostart script script looks very handy. I was considering trying Gscript already here is a new reason hehe.
NoSudo said:
Frankly the whole you cant modify his script deal is a HUGE turn off. I understand him wanting credit for his hard work, BUT wth. I'll stick to safer things.
EDIT: Forget what I said I completely miss understood what he says in his post. He says
"Personal Use: You may tweak the V6 installation script (leaving credits intact) to your own personal liking as long as it is NOT redistributed in any way."
His autostart script script looks very handy. I was considering trying Gscript already here is a new reason hehe.
Click to expand...
Click to collapse
I can see why he doesn't want redistributables floating around, even with the open source (something I feel very strongly about) nature of the forum.
All I wanted to do was spread the word, maybe help along the way, if I've done this then I'm happy
Sent from my Nexus S using xda premium
NoSudo said:
His autostart script script looks very handy. I was considering trying Gscript already here is a new reason hehe.
Click to expand...
Click to collapse
You can also auto start scripts without having to use script manager or any other scripting program by calling them from within install-recovery.sh (see my sdswap mod).
For example if you had a script /data/app/supercharger.sh
in install_recovery.sh you'd add a line sh /data/app/supercharger.sh
crossix said:
You can also auto start scripts without having to use script manager or any other scripting program by calling them from within install-recovery.sh (see my sdswap mod).
For example if you had a script /data/app/supercharger.sh
in install_recovery.sh you'd add a line sh /data/app/supercharger.sh
Click to expand...
Click to collapse
Cool. I have re-written another version of my hulu script in .sh and set it up to be able to run in a normal verbose mode, or to accept "silent" as a command line argument to redirect output to a lhulu.log file instead to better allow for the option of running at startup like a cron entry or what ever our allowed methods are on android.(like the one you just referenced, thanks) I'm planning on playing with it a little to figure out the best and easiest method. Then repost the updated version that can be a semi permanent fix.
NoSudo said:
Cool. I have re-written another version of my hulu script in .sh and set it up to be able to run in a normal verbose mode, or to accept "silent" as a command line argument to redirect output to a lhulu.log file instead to better allow for the option of running at startup like a cron entry or what ever our allowed methods are on android.(like the one you just referenced, thanks) I'm planning on playing with it a little to figure out the best and easiest method. Then repost the updated version that can be a semi permanent fix.
Click to expand...
Click to collapse
install-recovery.sh won't work for the hulu lib, sometime after that script is loaded all the apks libs get extracted for whatever reason. Unless you put a wait in there for the prop sys.boot_complete or something like that. Might also need to use busybox run-parts for a seperate init.d script, not sure if the wait would actually stop the rest of the boot process.
It should be fine, install_recovery is called really late in the boot process you're right about putting the waits in, if you look at my swapscript you'll see the amount of time I used to get it to work (and it does not pause the other processes).
Sent from my MB860 using XDA App
crossix said:
It should be fine, install_recovery is called really late in the boot process you're right about putting the waits in, if you look at my swapscript you'll see the amount of time I used to get it to work (and it does not pause the other processes).
Sent from my MB860 using XDA App
Click to expand...
Click to collapse
It's not as late as I previously thought myself. dmesg won't work at that point and getting a logcat from there you'll see it's the start of the system log just when vold starts up. Which is why you need a few sleeps in your script. Using it was my second attempt at 2nd-init, which wasn't possible until after my first bootloop, the boot animation starts later but also before the libs are replaced.
For hulu I've just been running a gscript after a reboot because of this, at least until I find a different solution.
Anyway install-recovery is the perfect spot for any kind of kernel tweaks and also SuperCharger.
@toyface sorry for being off topic
Sorry a little confused with the last part how do I navigate to /data in script manager?
Edit.. never mind. ma bad noob moment, couldn't for the life of me figure out how to get out of the mnt part of the directory.
Sent from my A100 using Tapatalk
Basically what this does is add a bunch of properties commonly added or adjusted in the build.prop that just makes everything better. I put this together to serve two purposes. The first is that although there are a few custom CM7 build.prop files floating around I never liked the idea of continuously using an old build.prop over what is now a multitude up updates and variants. A, because it shows incorrect or outdated information and B, maybe something new has been added or has been found to work better that will be missed by just swapping the file out. Before putting this together I found myself spending more time then I would have liked in notepad++ adding and adjusting lines in the build.prop after an upgrade or anytime after a system wipe. Second is that I think my Kindle runs pretty dam smooth in comparison to friends and family members who often ask if I can make their Kindle perform more like mine so not only does a script at boot save the time of editing all their build.prop files I would like to think these values and additions work well. Had originally planned on adding these to an init.d script I’m working on but can’t figure out a way that by including a line already present in the build.prop does not result in me needing to boot into recovery and swap out the script by mounting system. I’m sure ill figure it out but until then this method works just fine. Also trying to figure a way of making this script trick the market into thinking the device is a Galaxy Tab. Not there yet but pretty sure it can be done. Anyhow enough with my justification for the need of yet another set of build.prop tweaks for CM7.
Almost forgot, This is of curse at your own risk and I am not responsible for any damage done to anything you own.
Instructions
Download Hollyname Script and place on SD-Card
http://www.mediafire.com/?z964ni67vuy2nea
Install Script Manager from the Market
Open Script Manager and Select Hollyname Script
Select SU, Boot & Save
Reboot
One of the other nice things about using this method to apply these tweaks is that they are not permanently added to the build.prop and can be removed by either deleting the script from the SD Card or UN-selecting Boot in script manager.
If not sure everything was done correctly run “getprop” in either ADB or a Terminal and all current properties will be displayed. The list should include the properties below.
List of Tweaks Include,
debug.sf.hw 1
wifi.supplicant_scan_interval 180
dalvik.vm.heapsize 64m
persist.sys.ui.hw 1
ro.max.fling_velocity 12000
ro.min.fling_velocity 8000
ro.ril.disable.power.collapse 1
pm.sleep_mode 2
windowsmgr.max_events_per_sec 150
ro.media.enc.jpeg.quality 90
media.stagefright.enable-player true
media.stagefright.enable-meta true
media.stagefright.enable-scan true
media.stagefright.enable-http true
net.tcp.buffersize.default=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.wifi=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960
ro.kernel.android.checkjni 0
ro.kernel.checkjni 0
debug.performance.tuning 1
video.accelerate.hw 1
dalvik.vm.dexopt-flags m=v,o=y
persist.adb.notify 0
Some irrelevant entries
Thank you. Unless your Kindle Fire has a camera and GSM radio you might rethink the following four items, as their inclusion does not inspire confidence:
ro.media.enc.jpeg.quality 90
net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960
If you have such a device, can I have it?
Sent
chairshot215 said:
Had originally planned on adding these to an init.d script I’m working on but can’t figure out a way that by including a line already present in the build.prop does not result in me needing to boot into recovery and swap out the script by mounting system. I’m sure ill figure it out but until then this method works just fine.
Click to expand...
Click to collapse
Here's one way to do it in an init.d script:
busybox sed -i 's|windowsmgr.max_events_per_sec=.*|windowsmgr.max_events_per_sec=150|' /system/build.prop
busybox sed -i 's|wifi.supplicant_scan_interval = .*|wifi.supplicant_scan_interval = 300|' /system/build.prop
You might also find ease in making a .txt file with your edits ready to copy and paste into your build.prop file after a new flash. You might save yourself some hassle this way. Don't worry about doubling up on entries; the last instance of a value will override the previous instance. So, while your build.prop might have:
wifi.supplicant_scan_interval=60
something.use.situation.fun=7
wifi.supplicant_scan_interval=300
300 will win. Doesn't it always?
Sent from my mind using magic
manchucka said:
Thank you. Unless your Kindle Fire has a camera and GSM radio you might rethink the following four items, as their inclusion does not inspire confidence:
ro.media.enc.jpeg.quality 90
net.tcp.buffersize.umts=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.gprs=4096,87380,256960,4096,16384,256960
net.tcp.buffersize.edge=4096,87380,256960,4096,16384,256960
If you have such a device, can I have it?
Sent
Click to expand...
Click to collapse
Sorry, thought "ro.media.enc.jpeg.quality 90" was the value for displaying a Jpeg and not actually taking the image. Never mind, checked a few sites and this line does pertain to displaying images and not taking them. The other 3 I usually use with my phone and always see them together when looking at other scripts so figured the worst including them all could do is that they would just not do anything. Should probably just remove them anyhow if for no other reason than to avoid sarcastic alpha smart person in the room comments like "If you have such a device, can I have it?” It's a good one though as far as those kind of comments go, gave me a laugh anyway. Still don't understand why their inclusion would be any cause for concern?
Thanks for this though, I think I see what I may have been doing wrong.
manchucka said:
Here's one way to do it in an init.d script:
busybox sed -i 's|windowsmgr.max_events_per_sec=.*|windowsmgr.max_events_per_sec=150|' /system/build.prop
Click to expand...
Click to collapse
You might also find ease in making a .txt file with your edits ready to copy and paste into your build.prop file after a new flash.[/QUOTE said:
This is what I had been doing previously but then also had a few other Tweaks I have been using in an init.d script and had originally just planned on adding these to that script. Either way I just figured I could learn something new and at the same time avoid the need of having to paste in the lines as after each new flash the script would still be on the sd-card and script manager would apply the values with out needing to do anything extra after flashing. At least I had thought it was a good idea.
Click to expand...
Click to collapse
Hi. I just finished installing CyanogenMod 11 on my Galaxy Nexus. I also put the DirtyV-SR kernel on as well. Everything seems to be working fine. I then learned about a custom edit of the DirtyV kernel by Nephilim that seems to be popular. I have no idea how to change the settings manually though. Luckily in the DirtyV post there is a link to a script by the user "buscher" that supposedly does the changes for you. I followed the instructions and put the script in the System/etc/init.d folder, removed the .txt extension on the script, and changed it's permission settings (I think I changed the permissions correctly). I'm using an app called SManager to do this BTW. When I try to launch the script I get a syntax error. Here is a screen shot of said error...
i.imgur. com/ b5jAVe3. jpg
(Added spaces so I could post the link)
Link to DirtyV thread: http://forum.xda-developers.com/galaxy-nexus/development/kernel-dirtyv-t2613655
Link to buscher's post with the script: http://forum.xda-developers.com/gal...nel-dirtyv-t2613655/post50202995#post50202995
Does anyone have any idea what im doing wrong? Or perhapsna different way to use Nephilims version of DirtyV?
Thx
I've never used any of the scripts you're talking about, but normally that syntax error means that there's a coding error in the script file that the interpreter doesn't know how to handle. I looked at the script in that thread and I can't see anything that would jump out as being problematic, so there's a chance something may have happened when you downloaded the script or copied it to the device.
I'd say you should try downloading the script again directly on your device, and make sure you're clicking the "Download" button on the Mediafire page with the script instead of doing a "save link as" or anything similar from the forum thread. You may even want to open it up in a text editor app and compare it to the version online to make sure that the file matches.
Alright so I redownloaded it and got it to run this time. My problem now is that it seems some of the required directories for the script don't exist on my phone for some reason.
Here's a new screenshot of the errors
http:// i.imgur. com /mjBjQ88. jpg (again had to add spaces)
It's probably safe to ignore those errors, they probably come from that script being older than the latest kernel version you're running it against. Basically, Linux kernels create a whole bunch of files and folders in /sys that control certain kernel settings. By writing a value to specific files, you can change those settings. Those two errors are the result of the script trying to change two settings files that don't exist anymore, possibly because they were removed in a newer version of the kernel. The rest of the script should run without problems and make the rest of the changes.
just wanted to say, there is no need for script manager to run that script.
remove the .txt
put it in /etc/init.d folder/dir
set all perms(i.e rwxrwxrwx)
then just reboot
it will automatically run and set everything in the script when the device boots.
also
if you want to set those things from nephilim thread, use the app called trickster mod(or Synapse, though trickster might be less overwhelming for someone new to setting these things)
enjoy
any questions feel free to ask
Hi all,
I'd like to share my experience with V6 SuperCharger script by zeppelinrox [V6U9RC13] on my Galaxy Y
For those who wonder what V6 SuperCharger is I'd say it's a very long shell script (about 11.000 lines of code) that aims to optimize some system parameters and system/apps files in order to boost the phone performance.
Official thread of V6 SuperCharger is here along with the official downloads:
http://forum.xda-developers.com/showthread.php?t=991276
To execute the V6 SuperCharger main script any terminal emulator is suitable, but it's advised to install and use SManager app, available at Google Play store.
So, here is how my story begin.
I ran the script but the SManager paired with the Galaxy Y small screen, doesn't make it quick to go through all the Driver Options without having to tediously use the super small full keyboard, and having hard time to hit the proper keys.
I'm used to use the numeric pad, bigger buttons, but unfortunately on SManager numeric pad only can input number, not letters, and V6 SuperCharger doesn't usually accept numbers as answers to the many options.
So I decided to make a "quick" modification to the script on-the-fly, seeking all the 11 thousands lines for the options answers like y, Y, n, N, a, A etc... and adding a 1, 2, 3,4 at convenience.
After that, going through the Driver Options has been as nice as a breeze, using only the numeric pad to answer to all the options
Good right? no, not much...
Somehow the script didn't work at all... the Driver options were set but the boot script were not made, and all the main menu options were actually inactive....
Well... I thought it was a problem with my own phone configuration but I finally found out, after many hours of debugging, that zeppelinrox had hidden in the code a check that automatically and silently disable almost all the script functions if the script is been modified in a way that there are more o less lines than the original script.
Ok, found the problem, fixed, now everything run properly...
The scripts makes and installs its boot scripts and the tweaks are applied at everyboot... fine!
I then tried the zipalign function.
Zipaligning the apps packages (apk files) provide quicker access to their contents by system and apps... sounds good... isn't it?
Well... the 1st run of the Zipaligning wasn't a good one.... the script found something like 8 thousands apk files to check for zip alignment... and that was very weird as I don't have more than 200 apk in my phone.
Plus the process to check and eventually zipalign each apk was dramatically slow... something like 8-10 seconds per package (that is about 20 hours needed to process 8000 apk ).
Something was wrong somewhere... and I found it!
In the script the command used to find all the APKs doesn't work properly on the Galaxy Y stock rom... problably because of some simlinks that makes like a loop between folders.
Anyway the problem has been recognized too by another developer, Black Dog http://forum.xda-developers.com/showthread.php?p=42884332 , who actually fixed it in upd9 RC12, but the latest V6 script, upd9 RC13, from zeppelinrox, unfortunately didn't kept the "fix"... so, after I stumble on the issue, I had to find the source of the problem and make the fix myself
I just actually found the command used by Black Dog script to seek the APK and copied to the latest RC13 script by zeppelinrox.
Fine... let's try the Zipaligning again...
Ahh... this time the script found 187 apk to check for zipalignment... sounds nice.
But hey!... still processing each apk takes many seconds... and seems that ALL the apks aren't zipaligned... is that possibile?
No, something was wrong again.
And more I was sure it was wrong because repeating the zipalignment didn't report any of the previous zipaligned apk as already aligned, but instead, they were processed and zipaligned again
I then tried the zipalign command manually on terminal to check it's behaviour on any of the supposed not aligned apk.
Weird enough... the zipalign executable, that I installed with the SuperCharger_Starter_Kit_RC12.zip provided by zeppelinrox in it's official download page http://forum.xda-developers.com/showpost.php?p=18703418&postcount=5021 , when executed it simply didn't do anything... just few seconds of "nothing" and then... nothing!
No output of any kind in the terminal screen.
I then got a zipalign executable from another package (Adrenaline Engine, or Universal v.3.1... very same executable there) and copied to my phone and tried and this time... yeah... that's it! I got output!
Code:
# zipalign
Zip alignment utility
Usage: zipalign [-f] [-v] <align> infile.zip outfile.zip
zipalign -c [-v] <align> infile.zip
#
Tried again the so called "Wheel Alignment" (the zipalign task) and this time, finally, everything worked as supposed.
Found 187 APKs, 10 were not aligned and so they been aligned.
Repeated the process... 187 APKs found, 0 not aligned
I guess that the zipalign executable provided in SuperCharger_Starter_Kit_RC12.zip is been compiled to run on KitKat 4.4 and somehow it broken the backward compatibility with earlier version of Android like the one running on Galaxy Y (GingerBread 2.3.6).
Hope that sharing my own experience in here will help someone :angel:
Hi, so it is better to use RC12Fix over RC13 because of the zipalign function? Should I downgrade from 13 to 12Fix?
Fix align, Wheel align, and Fix emmisions on RC13 always has error on my galaxy y. But I am 100% supercharge.
If Im staying at Rc13, I have to manually zipalign my apks? and fix permission on cwm right? For it to work..
When I try the zipalign command. Nothing happens.
#zipalign
(wait for 5 seconds then goes back nothing)
#
Hi Klmiciano,
yes, the Wheel alignment (ZipAlin APKs), Fix emissions (Fix Force Close Errors) and Fix Alignment (which is just the execution in sequence of both Wheel alignment and Fix emissions) options are not involved with the system parameters optimization done by the script to achieve the "supercharge", so no wonder you still can get 100% supercharged.
Actually the "Fix emissions" option is just a set of commands that automatically scan all the system and try to fix any files and folder permissions (write, read, modify permissions) inconsistency.
Fixing of permission is an utility task provided also by other common apps, like, for example, "Nandroid Manager", which in my opinion everyone should have it installed along with "Online Nandroid Backup", obviously for backup purpose.
Fixing permissions (called Fix Emission in Supercharge) isn't really a task that has to be done on a regular schedule; it is a "fix", so it's meant to be executed when there's a problem (an app that keeps Force Closeing, after an update, or backup restore).
ZipAligning too isn't much important. Almost all apps available are already Zipaligned and even if you might have one app not aligned among one hundreds Apps installed, that won't problably affect your phone performances in a way that can be recognized also because is only the App that comes with a "not aligned" APK file that is affected, not the whole system.
Anyway, if you like to have the Wheel Alignment to run properly you need to replace the zipalign executable (which is located in /system/xbin/zipalign ); using RC12Fix won't work either because the issue is caused by the Zipalign executable version installed with the SuperCharger_Starter_Kit_RC12.zip provided by zeppelinrox in it's official download page.
It's not a script issue, it's a zipalign executable issue.
So, if you care to have Wheel Alignment to run properly you need to replace the /system/xbin/zipalign with zipalign executable from another package (Adrenaline Engine, or Universal v.3.1... very same executable there).