Related
I have the Hero build and I've found it necessary (along with everyone else) to reboot the phone daily. I was wondering if there was some kind of cron-esque script made so it would reboot the phone daily.
esmith972 said:
I have the Hero build and I've found it necessary (along with everyone else) to reboot the phone daily. I was wondering if there was some kind of cron-esque script made so it would reboot the phone daily.
Click to expand...
Click to collapse
cron-esque? Well how hard is it to press three buttons?
Provide solution, not comments
alritewhadeva said:
cron-esque? Well how hard is it to press three buttons?
Click to expand...
Click to collapse
@alritewhadeva, while many of your posts are quite useful, and you have personally assisted me in the past, I don't think your response is at all productive for this forum. While it may not be difficult to "press three buttons," the question is certainly a valid one and deserves to be treated as such. Perhaps he would like his phone to auto-reboot at 6am so it's ready to go when he wakes up. Either way, don't waste time by mocking the question. It is not productive and wastes everybody's time.
While on the subject of cron, I too was wondering what cron-esque solution(s) may be available to Android. I will look into it myself and post my findings, if any, here.
The cron daemon is available in busybox. Haven't tried it but you should be able to start it on boot in userinit.sh or whatnot and make an actual cron job for reboot.
aaronratner said:
@alritewhadeva, while many of your posts are quite useful, and you have personally assisted me in the past, I don't think your response is at all productive for this forum. While it may not be difficult to "press three button," the question is certainly valid and deserves to be treated as such. Perhaps he would like his phone to auto-reboot at 6am so it's ready to go when he wakes up. Either way, don't waste time by mocking the question.
While on the subject of cron, I too was wondering what cron-esque solution may be available to Android.
Click to expand...
Click to collapse
There is a script in the development section that has scheduled reboots. it was recently posted and should be on somewhere on the first 3 pages (probably the first)
Scheduler Location
Here is the post that has the scheduler app. Truth be told I am about to try it out for myself so at the time of this post I know nothing about it. I'm just posting its location for anyone who comes across this thread via searching for "cron."
http://forum.xda-developers.com/showthread.php?t=558822
OK, this is a little strange, but I think the idea is useful for people that want to mod the ramdisk but don't want to fiddle with compilers and such. It requires a kernel, so I'm including a proof of concept here. However, once the basic support is in a kernel, you can change anything about the ramdisk and the boot process WITHOUT changing your kernel!
For example, say you want to change init.rc... You can do that, and if it fails to boot, if you stored it on your external SD card, just pop out the card and boot up, the change won't be able to copy over at boot, so you are back where you started. No odin, no kernel mod.
The basic idea is simple. It runs init.d style scripts (if found) BEFORE the android init process starts up. This allows you to change literally anything in the ramdisk without the hassle of building a kernel. You can replace the /sbin/init binary if you want to, whatever.
This also means you could install and/or upgrade a lagfix, even voodoo, by copying a single file to /system/etc/init.d and rebooting.
This is more useful for devs I think than for end users, but perhaps users will find it useful.
NOTE: This is DANGEROUS STUFF. If you store your files in a world-writable location like /sdcard, ANY app could change your ramdisk! As it is, any root app can do it with this change. Anything run in the pre-init scripts is, by definition, run as root. So watch your permissions and don't store stuff used by the pre-init scripts in a FAT filesystem. EXT2/3/4 and RFS will work fine if you set them to root-write only. If in doubt, use "chmod 700 <file>". All of this should be obvious to most people here, but I think it's important to point out just in case.
This is based on Unhelpful's 1.7 kernel. It runs great on my Vibrant. There is one known bug, it reverts the locale to en_GB on boot, which is mildly irritating. I can't figure out why this happens. If someone knows, please post. I did write a simple app that switches it back to en_US using MoreLocale 2 (market) on boot, if people want it.
Credit to Unhelpful (kernel source and nice build scripts), JAC and Supercurio (examples for setting up the ramdisk properly for this sort of thing).
All the init scripts live in /system/etc/init.d. P*** are pre-init scripts. E*** are early-init scripts run before /data and /dbdata are mounted, allowing you to override mount options and such at that point, S*** are standard init scripts that launch right before the Android OS starts up, so the full environment is available to them. So you now have 3 hooks to start init scripts up. The boot process will wait for them to complete, so don't do anything that takes a long time if you don't have to, or start it in the background with "cmd &" or similar.
http://www.tabbal.net/files/t959-ttabbal-v1.0.tar
Flash with Odin. I'll consider putting up a ZIP later. Please, be at a computer with Odin and a known good kernel when you do this, this should be considered beta at best. Hardware locked phones should probably avoid this as well. Also, disable voodoo before messing with this, it does not include the voodoo script. If you really want to try it, you should be able to copy it to the init.d directory, but it would be better to wait a bit.
If it works well, hopefully other kernel devs will include the framework. I may also start posting updates from Unhelpful's git tree if there is interest as well now that I have a decent environment set up. See his thread in the Captivate forum for details on what changes have been done. OC/UV is supported, but I haven't worked with it much. You have to enable it by creating a config file and putting it on the phone. I'd recommend the external SD card in case you have a problem with a bad config, so you can pull the card and boot without clock changes. The OC/UV config can also be changed at runtime.
There is no need to pre-flash anything, and init.d need not exist or have any scripts in it. The system will boot fine without them.
If you try it, please post your thoughts. I'd like to see if there is interest for this line of work. If you don't understand a thing I said above, please don't install it.
Updates:
http://www.tabbal.net/files/Kernel-ttabbal-v1.2.zip
http://www.tabbal.net/files/Kernel-ttabbal-v1.4.zip
http://www.tabbal.net/files/z4mod-ttabbal-v1.1.zip
Wow, I am afraid to mess with this today. (expecting an important phone call)
I will flash it tomorrow morning however. And post some results, I have an idea about what to do with this.
Thanks Travis!
I hope you find it useful! I forgot to note one thing. If you want to see what your pre-init scripts are up to, there's some info in /init.log. Not a ton, but you can at least see if your script was started and such from there.
Also, if anyone cares, it works on Frankin-Twiz Final. I decided to check it out once I got this little project working.
I'm curious to see what people come up with, I've seen some complaints about not being able to edit the ramdisk without building a kernel. So now they can.
ttabbal said:
I hope you find it useful! I forgot to note one thing. If you want to see what your pre-init scripts are up to, there's some info in /init.log. Not a ton, but you can at least see if your script was started and such from there.
Also, if anyone cares, it works on Frankin-Twiz Final. I decided to check it out once I got this little project working.
I'm curious to see what people come up with, I've seen some complaints about not being able to edit the ramdisk without building a kernel. So now they can.
Click to expand...
Click to collapse
You mind sharing your init setup. I am familiar with Unhelpfuls method and just want to see what you have changed from his.
I stayed away from his method with Voodoo as it was causing issues at diff points of development and went with the run-parts solution. But it may be in better shape now that you have gone over it.
Most users will only need one hook but options are always good.
I've always been one the fence about the runtime OC/UV. Most people are looking for a stable voltage file that will work with their phones in the thread, but it is def awesome for those that are familiar with what they are doing.
justanothercrowd said:
You mind sharing your init setup. I am familiar with Unhelpfuls method and just want to see what you have changed from his.
I stayed away from his method with Voodoo as it was causing issues at diff points of development and went with the run-parts solution. But it may be in better shape now that you have gone over it.
Most users will only need one hook but options are always good.
I've always been one the fence about the runtime OC/UV. Most people are looking for a stable voltage file that will work with their phones in the thread, but it is def awesome for those that are familiar with what they are doing.
Click to expand...
Click to collapse
Talk to braka, we been hi-jacking the init for a bit, I've been working on getting a Desire pport working on are rom.. ( Well, barak has been hi-jacking the init ) I just build kernels.
justanothercrowd said:
You mind sharing your init setup. I am familiar with Unhelpfuls method and just want to see what you have changed from his.
I stayed away from his method with Voodoo as it was causing issues at diff points of development and went with the run-parts solution. But it may be in better shape now that you have gone over it.
Most users will only need one hook but options are always good.
I've always been one the fence about the runtime OC/UV. Most people are looking for a stable voltage file that will work with their phones in the thread, but it is def awesome for those that are familiar with what they are doing.
Click to expand...
Click to collapse
The whole ramdisk is here:
http://github.com/travistabbal/linux-galaxy/tree/ttabbal-v1.0/usr/initrd_files_t959/
The pre-init stuff is in /init.sh.
The basic stuff is the same as his really, I just put the sync hooks in to stall the boot based on an older version of his stuff. The current version didn't seem to work for me. The boot didn't wait, and I couldn't see any reason it would, so I just used the property setting style.
As I said, I haven't tried voodoo with it yet, but I don't see any reason it wouldn't work. You might want to pull the "exec /sbin/init" out if you want more pre-init scripts available, but other than that, it should work fine. A fair bit of the ramdisk came from your voodoo release, useful stuff in there.
If you see any issues with the init.d stuff, let me know and I'll look into them and if I can fix them, send a pull request over to Unhelpful.
Yeah, 3 hooks is overkill, but I figured there might be some use for them all. Most scripts can run in the "standard" hook and work just fine.
I kept the runtime OC/UV stuff just because it was more work to take it out. If you have a nice stable file, I'm happy to include it in the downloads as a default. I'm sure I could pull at least older versions from your github, I honestly haven't messed with it much beyond adding the 600Mhz step and seeing that the phone would use it. I honestly don't see much call for changing that stuff constantly at runtime, but it's nice for experimenting. If it crashes due to low voltage, just reboot and no harm done.
As I'm sure someone will ask, no I won't test it with voodoo. I can't, my phone has the extra NAND so it's not compatible with voodoo. When Beta5 comes out, I'll test it though.
I'm uploading a 1.1 now. The only big change is that I've fixed the backlight notification patch from Unhelpful's tree so it works with Vibrant now! Install the kernel, then copy lights.default.so to /system/lib/hw to get apps able to use it. Anything that can do LED notifications now turns on the button backlights instead.
See the other BLN threads for Q&A's, etc.. The big one, no, we can't flash/fade the LEDs. It would require changes to the binary firmware and nobody wants to try writing it.
http://www.tabbal.net/files/t959-ttabbal-v1.1.tar
http://www.tabbal.net/files/lights.default.so
This has been tested on my phone running Bionix 1.7 and worked with the MMS and GMail apps. I haven't tested the others.
Again, it's an Odin tar file. Put it in the PDA section and flash. If people ask for an update.zip, I'll put one together.
The warning above applies. This flashes a kernel, so it will overwrite whatever you have now. So if you have voodoo, disable it or add the voodoo script to init.d with an E prefix ie. "Evoodoo".
Thanks
I've been looking forward for a way to use the backlight buttons as notification since the phone came out and the idea was hatched a few days later. I'm admittedly new to all this so I have no idea what else this is capable of but I am VERY thankful for the button lights. Also there is another xda thread up with many replies and people offering up some rewards for making this work.
Can this be applied to eugenes froyo ?
Sent from my SGH-T959 using XDA App
dzeinz said:
I've been looking forward for a way to use the backlight buttons as notification since the phone came out and the idea was hatched a few days later. I'm admittedly new to all this so I have no idea what else this is capable of but I am VERY thankful for the button lights. Also there is another xda thread up with many replies and people offering up some rewards for making this work.
Click to expand...
Click to collapse
Rewards? Heh... I had no idea people were that interested in it. Hope it helps. My github has source, so I hope other kernel devs for vibrant add it.
skater991 said:
Can this be applied to eugenes froyo ?
Sent from my SGH-T959 using XDA App
Click to expand...
Click to collapse
Not sure. Froyo usually needs a different kernel. If JAC or KK kernels work, this one should. At worst, it will boot loop and you will have to flash a compatible kernel in download mode. So make sure you can get into download mode before trying it.
Thanks for this. It's working great, and I'm so glad to finally have backlight notifications.
Definitely would like an update.zip, just not comfortable doing it through odin...but I would love to have this
The cake is a lie!
metalfan78 said:
Definitely would like an update.zip, just not comfortable doing it through odin...but I would love to have this
Click to expand...
Click to collapse
Well, since you asked nicely.
http://www.tabbal.net/files/Kernel-ttabbal-v1.1.zip
MD5: 606a1ecaa934f97bd26f0bfb617b23b8
Tested just now via Clockwork. It even installs the library for you, so the button notification should work out of the box.
Running great for me on Bionix 1.9.1.
Wow...thanks, ill give it a go. So just flash through clockwork and good to go?
The cake is a lie!
metalfan78 said:
Wow...thanks, ill give it a go. So just flash through clockwork and good to go?
Click to expand...
Click to collapse
Yup.
Let me know what you think.
Is this ready for overclocking like JAC's OC/UV kernels? If so, any chance of posting a demo script for the OC/UV settings?
Also, can we add a user-script to enable AOSP bootanimation.zip files, or is support still commented out in this kernel?
Thanks for your time and hard work, cheers, =)
I have been wanting button notification since i got the phone. Can you choose which button lights up based on what the notification is?
for example menu = txt, home = missed call, etc....that would be awesome!
s0niqu3 said:
Is this ready for overclocking like JAC's OC/UV kernels? If so, any chance of posting a demo script for the OC/UV settings?
Also, can we add a user-script to enable AOSP bootanimation.zip files, or is support still commented out in this kernel?
Thanks for your time and hard work, cheers, =)
Click to expand...
Click to collapse
It's based on Unhelpful's way of doing OC/UV, you have to modify a file and push it to the phone to enable it, then set up the min/max settings with a script or SetCPU. There's a lot of detail over in Unhelpful's thread on the Captivate forum, so it's probably better to point you over there. They have scripts and such for it as well.
Not sure on the boot animation. I'll see if I can find it.
d_bot said:
I have been wanting button notification since i got the phone. Can you choose which button lights up based on what the notification is?
for example menu = txt, home = missed call, etc....that would be awesome!
Click to expand...
Click to collapse
That would be awesome, but it's not that complex. It's all of them for a notification. The Android API wouldn't really be able to deal with that level, but perhaps we could assign the buttons colors and use the color that the app requested? Maybe, but I'm not sure we can turn on just one of them from the code we have right now. The code looks to make a somewhat simple call that turns them all on at the same time. Hopefully as more people look into things, we will learn how to do stuff like that.
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 also realize I posted this in the Rhodium section - I want to see if there's any TOPAa-specific tweaks that others should be made aware of!
Update to this - I changed around how topic 4 is done. Feel free to re-read that section.
Thanks arrrghhh, but for startup stuff, there are some apps doing the job, like Startup Manager or Startup Cleaner pro (found in Market), honestly haven't tried them yet but from rating, some of them has got 4.1/5.. What do you think mate?
metho88 said:
Thanks arrrghhh, but for startup stuff, there are some apps doing the job, like Startup Manager or Startup Cleaner pro (found in Market), honestly haven't tried them yet but from rating, some of them has got 4.1/5.. What do you think mate?
Click to expand...
Click to collapse
For the pm disable stuff? If you find an app that does it, more power to you. I want to control Android directly, hence the reason I went with a script that utilizes that concept. The pm disable stuff is obnoxious I know - so if you do find an app that'll do it for you, have at it. I didn't want to add any more apps into the mix if it wasn't necessary .
Rhod400 in startup.txt
Does physkeyboard=rhod400 cahnge the keyboard layout when texting?Does it make it bigger or what is that cmdline for?
1edge1 said:
Does physkeyboard=rhod400 cahnge the keyboard layout when texting?Does it make it bigger or what is that cmdline for?
Click to expand...
Click to collapse
Sorry, that part is completely irrelevant to TOPA. It is for a RHOD400, sets up the physical keyboard. You were only supposed to look at the acpu clock command, as it fits in the startup.txt... lol.
Use the startup for your device, I'm just showing you how the line should appear in the startup.txt...
arrrghhh said:
Sorry, that part is completely irrelevant to TOPA. It is for a RHOD400, sets up the physical keyboard. You were only supposed to look at the acpu clock command, as it fits in the startup.txt... lol.
Use the startup for your device, I'm just showing you how the line should appear in the startup.txt...
Click to expand...
Click to collapse
yeah i do use the startup for topaz. Was just wondering. haha. thanx for clearing it up
As promised earlier that I would share my work and yes I stand by that promise. The modified CPU editor script.
CREDITSsmokin1337 The original creator of the scriptupnndwn4par For his support
todobarato For suggesting optimization which was really useful
ONLY FOR ATRIX 4G Running ICSROM or ATRICS
The usual warnings. Do not blame me for bricked phones. This is still under testing phase and I need testers.
Please donot PM me with the results, Post them here in this forum
New Version
Added an optimization suggested by todobarato (thanks!!) Works fine. The only problem still is the sticky bit issue. Still Working on it
Download the New Version Here.
Instructions
1. Flash in CWM
2. Reboot
3. The script should start working on its own (Doesn't Work for now)
Open terminal > "auto-cpu" (Without quotes)
And also please let me know if the CPU frequencies are reverting at boot or not?
Changes Made
1. The original script by smokin1337 is kept intact , so advanced users can still use the script as usual.
2. The modifications automatically shutdown one of the cores when its not required.
So please go ahead test it and let me know results.
Anyone is welcome to help and provide suggestion or even modify this and contribute.
deathscream said:
As promised earlier that I would share my work and yes I stand by that promise. The modified CPU editor script.
CREDITSsmokin1337 The original creator of the scriptupnndwn4par For his support
ONLY FOR ATRIX 4G Running ICSROM or ATRICS
The usual warnings. Do not blame me for bricked phones. This is still under testing phase and I need testers coz I just lost my phone to my girlfriend for a week
Please donot PM me with the results, Post them here in this forum
Download the attachment.
Instructions
1. Flash in CWM
2. Reboot
3. The script should start working on its own (Couldn't test it , Sorry guys)
And also please let me know if the CPU frequencies are reverting at boot or not?
Changes Made
1. The original script by smokin1337 is kept intact , so advanced users can still use the script as usual.
2. The modifications automatically shutdown one of the cores when its not required.
So please go ahead test it and let me know results.
Anyone is welcome to help and provide suggestion or even modify this and contribute.
Click to expand...
Click to collapse
Thanks for your job
I try it..to take off one cpu I have do it manually..on reboot the cpu starts both
andrea_marcello said:
Thanks for your job
I try it..to take off one cpu I have do it manually..on reboot the cpu starts both
Click to expand...
Click to collapse
Yes I got those same results from others. Can you try using SManager and select the script /system/xbin/auto-cpu and let me know of the results.
Thanks!
what is this for?
and how do i know if it is working or not?
mindstorms54 said:
what is this for?
and how do i know if it is working or not?
Click to expand...
Click to collapse
It allows CPU mods without using an app (which of course uses battery).
You can change min/max frequencies on each core individually. You can even take one of the cores offline completely. Running on one core is not noticeably different from two for routine use. I hardly see a difference. I can't give any hard number for the increase in battery life since I have only been using it for less than two days. But battery life is definitely better.
There is some more info here:
http://forum.xda-developers.com/showpost.php?p=34427620&postcount=785
*********************************
deathscream,
I just tried it. The script is not running automatically as far as I can tell. I am not seeing the second core shutting down.
Thanks, and keep up the good work.
I'll look into it. I just got my phone back. Now I can test it without any problems.
Sent from my MB860 using xda premium
Hello,
I am following this and I think you are complicating it to much.
I have test this script and the original and it never disable the 2nd core.
If you will disable it is very easy with the following command as su: echo 0 > /sys/devices/system/cpu/cpu1/online
The only issue is that it comes online very fast again and you have to execute the command again... I have found the script that disable the 2nd core but only when the screen off, this isn't our problem, by CPU-spy it show deep-sleep is working.
I have changed the script to disable the 2nd core when the CPU frequency is under 350Mhz, this check every X second (I use 35seconds, this can be changed) , now the second core is offline when it detects low CPU frequency and stay offline, if you need it again I have observed after switch off and on again the screen it comes back online or by open set-CPU(I have it on widget to check CPU temp) if you have. If you use one very CPU intensive app comes only by itself too.
I put the script on /system/etc change the correct permission, run with SDmanager.
The script is:
--------------------------------------------------------
#!/system/bin/sh
#
#
while [ 1 ]
do
CPU0=`cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq`;
if [ $CPU0 -lt "350000" ]; then && echo 0 > /sys/devices/system/cpu/cpu1/online;
fi;
sleep 35
done
-------------------------------------------------------------
I hope this help, I am using it on CM7 and work better that I have expected.
Sent from my MB860 using xda app-developers app
Thanks a lot. Will try it out.
Sent from my MB860 using xda premium
It' dont work for me automatically after reboot.
I use the terminal to put the values by myself
It's a great tool.
Thanks for the work
Regards
You have a lot of features about OC on Atrix (scripts) here
http://forum.xda-developers.com/showthread.php?p=23715720
And here
http://forum.frandroid.com/topic/93255-autoucuv-forcage-cpu-et-oc-uv-gpu/
And here
http://forum.frandroid.com/index.php?/topic/105205-[APP]-✖-AtrixTweaks-(19/08/12)#entry1701606
it works but not automatically. i noticed a little battery increase. from 12hrs i got about 15 hrs uptime running latest icsrom.
fabianowerner said:
it works but not automatically. i noticed a little battery increase. from 12hrs i got about 15 hrs uptime running latest icsrom.
Click to expand...
Click to collapse
Yes. I tried it . The script doesn't run automatically. The sticky bit setting is driving me nuts. haven't slept the whole night. adding this to userinit also doesn't work , so I guess the only way would be try upacking the booimage, ramdisk and adding to the init.rc . I'll try running that there. That should probably work. But can't say for sure.
relax dude... even with the 2nd core disabled, the battery life had increased just a little almost insignificant hours. im pretty sure that we will have this serious issue solved only if someone can put hands on another ics kernel or this leaked kernel source.
fabianowerner said:
relax dude... even with the 2nd core disabled, the battery life had increased just a little almost insignificant hours. im pretty sure that we will have this serious issue solved only if someone can put hands on another ics kernel or this leaked kernel source.
Click to expand...
Click to collapse
Yeah. Hope for the best . Released a new version. It's not automated but its even better working. The cores are managed better than the original one.
deathscream said:
Yeah. Hope for the best . Released a new version. It's not automated but its even better working. The cores are managed better than the original one.
Click to expand...
Click to collapse
I just released a new version of ICSROM with init.d support.
It might help with your automation.
upndwn4par said:
I just released a new version of ICSROM with init.d support.
It might help with your automation.
Click to expand...
Click to collapse
Perfect. I'll check it. At work now. Thanks!
deathscream said:
Perfect. I'll check it. At work now. Thanks!
Click to expand...
Click to collapse
Thank you for your support!
I'm testing the new version on AOKP (not suggested, I know ) and it seems that doesn't switch well the cores status.....I'm able to set a maximum cpu1 settings but not it doesn't really applies it.
Within my tests I can see that the 2nd core is not so much important....I can play Riptide GP and Shine Runner (heavy games??? ) plus others apps with only 1 core without any noticeable lags...so
I'd like to ask you if you can make a unique profile and cut off other settings:
cpu0 @ 1ghz max, variable
cpu1 @ 456mhz max, variable (enabled only if cpu0 is @ 1ghz more than 5/10 seconds)
screen-off: cpu0 456mhz max, cpu1 disabled.
Thanks a lot for the suggestion. I'll definitely try adding those.
Sent from my MB860 using xda premium
If disabling a core is not fetching significant battery increase in leaked rom(s) then efforts to streamline sampling would we worthless as primary issue of battery drain would not get solved.
This came as a surprise as the second core was suspected to be the mAh drainer. Maybe it could be the GPU that runs at max..
After a long amount of observation, I found out that shutting down a core isn't reducing the battery drain. There is something more to it. Thanks to upndwn4par to release icsrom 1.4.5 so that I could test my scripts... I'm still working on the battery drain issue and will let you guys know the progress soon.
Sent from my MB860 using xda premium
Automatically optimizes SQLite databases on boot, on schedule, every X days.
Just a quick and dirty adaptation of an old SQLite3 optimizer script from init.d days to a Magisk Module using a service.sh script instead, with an internal date offset mechanism to run the script every X days (default: 3 - which is plenty, and specifically to stop silliness).
Update And credit note: finally after a fair bit of digging, i think i located the original author of the original init.d version of the main vacuum code snippet ive repurposed (stolen) for this module. It appears to be from user @mcbyte_it (doesnt seem to be current or active) and from a post here. Although i only saw derivative reworkings of this script, and used only the main sqllite script function, i arrived at a different method of tracking last run date, when his is arguably more mainstream/concise. Im fairly certain this is the originator especially as the post also has a zipalign script that was also suggested to me to do....and which i have been fiddling with for months....
The script will wait until boot is completed AND then until avg CPU usage is under 30%, to minimise the risk of possible corruption.
Disclaimer: As always any use of any 3rd party script/software/advice is at the users discretion. All reasonable efforts have been made to make this as safe as possible, but the responsibility ultimately falls to the user whether to use and run the script.
What it does:It:
Reindexes
Vacuums
Analyzes
all .db files under /data.
It runs a 1st run optimize after install (temp file optimsql_first_run on sdcard is used to enable this, and removed after first run), and then on schedule after that.
By default it logs just script progress to /storage/emulated/0/autosqlite.log, but you can choose to enable more detail in the log if you wish
User Configurable Options:The schedule and loglevel can be changed by an external file on sdcard:
Create a file named autosqlite_options on sdcard (/storage/emulated/0/)
Inside create the follow key=value pairs to suit your preference:
interval=x (where x is the number of days between script runs, for the love of god do not put 1 (this goes out especially to the kind of people who put every app on their Magisk magiskhide/deny list) there is no benefit and you just heighten the possibility of corruption)
loglevel=x (where x is either 1 (detailed logging) or 0 (basic logging - default))
Requirements:This module requires a working SQLite3 binary. If your ROM does not provide one (you can check via typing sqlite3 into a terminal), you can choose to use my SQLite3UniversalBinaries module located here:
https://github.com/stylemessiah/SQLite3UniversalBinaries
Dont forget you need to download a named SQLite3UniversalBinaries.vx.x.zip file from the Releases page under Assets. Do not try installing the source code with Magisk Manager, it will not go as you expect
All the modules action takes place in the service.sh file, its commented reasonably well for those wanting to check how it works
* See... now theres something else to use with my SQLite3 Universal Binaries module other than the GPay SQlite Fix Module <- dont use that anymore, it makes me stabby. It is literally the last resort for getting Google Pay/Wallet to work ,
Please note: the included LICENSE only covers the module components provided by the excellent work of @Zackptg5 's Magisk Module Extended, which is available for here for module creators
https://github.com/Zackptg5/MMT-Extended/
All other work is credited above and no one may fork or re-present this module as their own for the purposes of trying to monetize this module or its content without all parties permission. The module comes specifically without an overall license for this intent.
Download:
Repo: https://github.com/stylemessiah/AutomaticSQLiteDBOptimizer
Release: https://github.com/stylemessiah/AutomaticSQLiteDBOptimizer/releases/latest
Powered by Ponkle
@73sydney Nice! If you're looking for newer sqlite3 binaries, I have a build script you can use to build it or you can just grab the precompiled ones at my repo: https://github.com/Zackptg5/Cross-Compiled-Binaries-Android
Zackptg5 said:
@73sydney Nice! If you're looking for newer sqlite3 binaries, I have a build script you can use to build it or you can just grab the precompiled ones at my repo: https://github.com/Zackptg5/Cross-Compiled-Binaries-Android
Click to expand...
Click to collapse
cheers man, i was trying not to pinch all your toys
i mean i could have done an androidacy and scraped your repo for just the files i needed
plus im lazy
73sydney said:
optimizes SQLite databases
Click to expand...
Click to collapse
Nice
how about no schedule, i want to execute it whenever i want
possible ?
loopypalm said:
Nice
how about no schedule, i want to execute it whenever i want
possible ?
Click to expand...
Click to collapse
I refer the gentleman to the name of the module and title of the thread:
"Automatic SQLite DB Optimizer"
the distinct lack of the word "manual" should be a clue
what are they teaching in school these days?
i made this to be automatic and made special note about the intervals because theres people who would abuse this and run it every day if they could, both designed to avoid misuse/abuse:
interval=x (where x is the number of days between script runs, for the love of god do not put 1 (this goes out especially to the kind of people who put every app on their Magisk magiskhide/deny list) there is no benefit and you just heighten the possibility of corruption)
im not really interested in making a manual version option unless you can convince me where there is a use case benefit, because all i see is potential for misuse/abuse that i specifically made this to avoid....
running it by default it runs every 3 days which is twice a week and probably still overkill, but trying to cover all bases
your other option is to ask me for permission (sadly because of abuse in the past from certain entities trying to monetize my and others work, my contributions are not GPL etc) to fork and alter the code yourself....
73sydney said:
I refer the gentleman to the name of the module and title of the thread:
"Automatic SQLite DB Optimizer"
the distinct lack of the word "manual" should be a clue
what are they teaching in school these days?
i made this to be automatic and made special note about the intervals because theres people who would abuse this and run it every day if they could, both designed to avoid misuse/abuse:
interval=x (where x is the number of days between script runs, for the love of god do not put 1 (this goes out especially to the kind of people who put every app on their Magisk magiskhide/deny list) there is no benefit and you just heighten the possibility of corruption)
im not really interested in making a manual version option unless you can convince me where there is a use case benefit, because all i see is potential for misuse/abuse that i specifically made this to avoid....
running it by default it runs every 3 days which is twice a week and probably still overkill, but trying to cover all bases
your other option is to ask me for permission (sadly because of abuse in the past from certain entities trying to monetize my and others work, my contributions are not GPL etc) to fork and alter the code yourself....
Click to expand...
Click to collapse
i was planing to use it once a week
categorizing me with people who do dumb stuff is an 'insult'
i asked a simple question man, don't jump to level 3 mind game please ...
loopypalm said:
i was planing to use it once a week
categorizing me with people who do dumb stuff is an 'insult'
i asked a simple question man, don't jump to level 3 mind game please ...
Click to expand...
Click to collapse
Im sorry, did you miss the double smileys intended to completely avoid any misunderstanding that i was being jovial. the other tip off that i wasnt burning you was taking the time to write several paragraphs
Can i suggest you just set the options file interval to 6 or 7 and let the module do what its described in the title as doing, it would make no functional difference, other than saving you a trip to terminal?
As i said, give me a valid reason for adding a manual option and ill gladly consider it, choosing a reason that fits completely within the actual parameters of the existing module doesnt really fit that offer...
ill go further to why i specifically didnt put in an option to run it manually (really folks are lucky i didnt block the option to run it every day) because you should understand what the sqlite vacuuming and other processes do:
* They copy the data from the db file to temp file before optimising it and writing it back, at any point in this theres the potential for corruption (sudden power loss, other processes accessing the file etc). Ideally any such corruption would be minimised by journaling but anyone who had used Linux for long enough knows not to count on such things.
* If any db is being written to, then the optimization process will NOT optimize that db...for the above possible corruption reasons. Hence why i not only put in a wait till boot completed function BUT also added a function to block the script from running unless avg cpu load over 5 minutes is less than 30%. all this to try and make things as safe as possible. So im not overly fond of a manual option which bypasses these safeties i specifically put there to hopefully safeguard people as best as possible. I dont want to get messages about how my module hosed someones apps.
Perhaps that better addresses my reasons?
As said, you can also ask me to fork the code, and ill even tell you how to add a manual function, but i personally wont be releasing such a version without a better reason than i want to do it every 7 days, when the script as it stands can do that AND at a far more predictably safe time and way than you manually likely can or will use it....
BTw, how is actually responding, even taking the time to do so and being jovial about it "level 3 mind games?", whatever the hell that even is?
73sydney said:
.
Click to expand...
Click to collapse
i was planing to make a recovery backup of "DATA" after the optimization of DB files ...
if you want better result add a comand to kill the coresponding app, then it would be more stable
or tell the people to use FlushRam or something like that before the proccess start, to make sure the result will be good, or make a 2nd module for advanced users ...
even with the condition you said some system apps stays working in the background and messing with their data can lead to corruption
i don't know you or your previous work and i don't have time to care for that
i just asked a simple question
answer with "NO, my module will not do that"
this will save your time and other people time
loopypalm said:
i was planing to make a recovery backup of "DATA" after the optimization of DB files ...
if you want better result add a comand to kill the coresponding app, then it would be more stable
or tell the people to use FlushRam or something like that before the proccess start, to make sure the result will be good, or make a 2nd module for advanced users ...
even with the condition you said some system apps stays working in the background and messing with their data can lead to corruption
i don't know you or your previous work and i don't have time to care for that
i just asked a simple question
answer with "NO, my module will not do that"
this will save your time and other people time
Click to expand...
Click to collapse
1) whether before or after backup, the files will eventually get optimized - if you want a more manual version use SD Maid or as offfered you can ask me how to alter the code as it sits and make your own version.
2) Im not ever releasing a script that kills anyones apps in the background, i would consider that suboptimal, and basically malware
3) I never said that some "system apps stays working in the background and messing with their data can lead to corruption". What i said was i designed the script to best avoid corruption by running only after boot completed and when avg CPU usage over 5 minutes was less than 30%. The sqlite3 itself generally wont allow access to a file in use. Im just adding what i think is a reasonable level of extra safety by deciding when the optimization routine starts to run, and that it isnt abused/misused by running multiple times in an unreasonable timeframe
4) How does
I refer the gentleman to the name of the module and title of the thread:
"Automatic SQLite DB Optimizer"
the distinct lack of the word "manual" should be a clue
not equal "NO, my module will not do that", only with some attempt at humour and a long explanation (soon followed by a more reasoned explanation) because i didnt want to appear dismissive. Yet it looks like you’d have preferred dismissive??
You seem impossible to please anyway someone tried to do it....
To be honest Im tired of this circular conversation. Everyone else knew from the word automatic in the title how things was going to work. Ive made suggestions of alternatives (SD Maid) and even offered to give you the info to change the script for yourself, and cant do more than that.... please choose one and lets move on, please?