[Guide][init.d]How to run init.d scripts on boot + Best Battery Life

[kobridge]

How to run init.d scripts on Boot- 4/26/12

Before starting this guide, I'd like to say "thanks to many Devs" on this forum.

[Update] sfhub just added init.d support function into his auto root tool at http://forum.xda-developers.com/showthread.php?t=1342728
If your kernel does not support init.d, then use his tool to add init.d support without flashing a new kernel.
Just in case you only want to have a script which invoke the init.d scripts, check the second post in this thread.

4/29/12 sfhub improved his auto root tool to support some other kernels, those are enabling init.d through different .xc files.
Stock kernels and some repacked kernels are supporting init.d scripts through init.xc and/or install-recovery.sh but some other repacked kernels are supporting init.d scripts running through different .xc files. So, sfhub made some modification on his script. Because he's adding a new install-recovery.sh file into /system/etc folder, if there's a existing install-recovery.sh file at the same location, the existing install-recovery.sh file will be replaced by his previous version of Auto Root Tool. To prevent the replacing existing install-recovery.sh file with his same named install-recovery.sh file which supports the init.d scripts, his tool now creates a copy of old file and create a new one. Old install-recovery.sh file will be named as install-recovery-orig.sh.

If you just want to simply enable init.d support without using sfhub's tool, then download the new-install-recovery.zip file from my second post and unzip it. If there's any existing install-recovery.sh file and it's not related to init.d support, then rename it to install-recovery-orig.sh and move the unzipped file to same directory (/system/etc). Assign the file permission 550 (r_xr_x___). New install-recovry.sh file will execute the init.d scripts (if it's there) and old install-recovery-orig.sh (if it's there) during the boot.
4/30/12 I've modified his install-recovery.sh file (new-install-recovery.zip, attached) to use the default busybox command. If you don't have busybox installed on your phone, you will also need to download attached busybox.zip and unzip, place into /system/xbin folder with permission 755.

Update2 I'm uploading my tweaks again. Based on my test, this tweak works much better and extended my battery life a lot more. In this battery tweak, the max cpu speed would set to 1000000, but normally it would run with 800000 or less. Based on my test, this works great and no fc, no random reboot. If you really want to extend your battery life, then test your battery life with this tweaks. (tweak file is attached in second post). My test was done under FD19 and FD24 Stock Roms

Update3 Found that Camera app kept freezing, fc, and made system reboot if max CPU frequency is set to under 1Ghz. So because of this app, had to keep max cpu speed to 1Ghz when the phone is in awake mode. Uploading new tweak files.

Upon his tools update, my guide in here would be only for some limited people who just want to test the scripts or want to selectively run the scripts during the boot. For example, if you have 10 scripts in init.d and just want to selectively run from those, you can use SManager.

Issue: /system/etc/init.d scripts does not run automatically during the boot

Details:
Rogue Repacked Kernels are started supporting init.d scripts during the boot and many custom roms are now including the scripts in /system/etc/init.d. But usually repacked kernel is not ready when the new rom comes out and we need to use old version of repacked kernel to get the init.d support.

How to test: (only applicable to the phones having Repacked Kernel and supporting init.d scripts. For the stock kernel, I’ll explain it later how to run it during the reboot)

It seems like Rogue Repacked kernel allows the init.d script running thru /init.rc. init.rc file is part of bootimage and this file is over-written everytime when the system reboots. So, editing this file is not possible. Only the way editing this file would be by extracting bootimage and making modification, repact the kernel image.

Running the init.d script from init.rc is,

(FD02)
# Run init.d scripts
service sysinit /system/bin/logwrapper /system/xbin/busybox run-parts /system/etc/init.d
class main
user root
group shell
oneshot

(before FD02)
# Run init.d scripts
service sysinit /system/bin/logwrapper /sbin/run-parts /system/etc/init.d
class main
user root
group shell
oneshot

So, if you are not sure whether a script in /system/etc/init.d is running on boot, you can simple add a script into this directory.
Create a script using text editor in root explorer (don’t use ES File Explorer to edit the file). The character set used in es file explorer causes a problem to run the script. This is very important thing to remember. Even syntax and everything looks correct but the script would not run if it includes some hidden character which is not supported by shell. Be sure to use the editor supported by the shell.

Example)
Create a file 0test into /system/etc/init.d

#!/system/bin/sh
touch /data/local/tmp/initd_test.txt
echo "Hello Android" > /data/local/tmp/initd_test.txt

File permission is 755.
If there’s some scripts in /system/etc/init.d, then backup those files to your sdcard for later use. Sometimes, it’s hard to find the script running result and that’s the reason why I’m testing it by simply writing a file.
If you are done with creating a file, reboot your phone and go to the /data/local/temp directory.
If the initd_test.txt file is there and content is “Hello Android”, then it means that any other scripts in the init.d directory will be executed during the boot and you don’t need to follow this guide any more.

Workaround to run the init.d scripts during the boot:
This workaround is nothing to do with Repacked or stock kernel. In another words, this workaround would work on both repacked and stock kernel.

[Update] Again, if you don't need to test the scripts and only want to run someone else's tested script, then you can simply use sfhub's auto root tool to add the init.d support option.

What you need:
Download Script Manager – Smanager app from Google play store (it’s free) and install it.
https://play.google.com/store/apps/details?id=os.tools.scriptmanager&hl=en
You must have busybox installed and have su permission.

Steps to test the existing scripts:
1. run Script Manager and open 0test script. Click the su icon and run.
2. SManager will show the ‘exit code’ and any messages from the script. Be sure that you got the exit code ‘0’.
3. Go to the directory /data/local/temp and check if file is create and has ‘Hello Android” in it.

SManager is a great tool to verify the script syntax or any errors during the run. So if you have any init.d scripts, you can test those scripts before you start to run during the boot (this may prevent any boot loop or any issue).

How to run the scripts during the boot using SManager:

Steps to run the scripts during the boot:
1. Test the scripts out completely before start to run on boot.
2. From the SManager tool, select su and boot icon. Exit the application and reboot the phone.
3. If you did not change the SManger config, then you will see the SManager log after the boot. Check if everything is fine. If the scripts run OK many times without any issue, then you can uncheck the option showing SManager log after the boot.

This tool is great because you can run the scripts on both stock and repacked kernel. Also, you don’t need to put the scripts into /system/etc/init.d. You can place those files in any locations.

Using this tool, currently I’m running Calk’s init.d tweaks without any problems.
Calk’s tweaks are included in his FD02 Rom.
My current phone is
D710 + FD19 Stock Kernel + FD19 Rom + FD19 Modem with init.d scripts running

** This is an initial version and I’m going to add some more stuff in this thread. If you like this info and if this info is helpful for you in any way, please leave your feedback and consider to buy me a beer! **
** Because of sfhub's great job, it seems like I'm done in here. I hope you had enough information that you wanted **

 

[kobridge]

What makes your phone even better?

If you use the stock kernel, then you may want to replace the build.prop and gps.conf files with attached files (unzip it).
These files are based on Calkulin's and Agat's Rom. Because I modified the files based on my demand, you may also want to change the files based on your situation.
Because these files are not changed after the reboot, you can replace these files with any tweaked files that you want to use.
(these files won't be changed by Kernel change but flashing rom will replace all these files)
You can use gps.conf and init.d scripts with any rom but build.prop is dependent on the rom. This build.prop is based on FD19. So, be sure that you need to modify it if it's used on different rom.

Attached file also includes the init.d scripts. These scripts are also same as on Calk's FD02 init.d scripts. I only changed few default option based on my requirement. So, if you want to original init.d scripts, please download Calk's FD02 v1.4 rom and extract the init.d scripts.

Again, all thanks should go to Calkulin and Agat if you use their tweaks.
Update1: Many thanks to sfhub for his auto root tools including init.d support

Update2: I've added one more script file (attached) which can be used alone with previous one or standalone. All these tweaks are tested on my phone and working version. If you need to edit, be sure that it's properly edited and tested before adding it to the init.d.

Update3: If you just want to use the script which runs init.d scripts during the boot without running sfhub's auto root tool, you may download the third attached file in here. Download, unzip it. Place the install-recovery.sh file to /system/etc with permission 550. This script will be executed by init.rc during the boot if you are on the stock kernel and this script will run the init.d scripts. If you are on the repacked kernel, which supports the init.d, this install-recovery.sh wouldn't do anything (init.d script will be executed by init.rc instead of this install-recovery.sh)
4/26/12 sfhub's auto root tool is updated. Check the updated information from top thread update section. http://forum.xda-developers.com/showpost.php?p=25120371&postcount=1

Update4:I've found that some attached tweaks is preventing the ondemand governer changes. So, until I find the issue and fix it, I dropped the attached files (you are still able to download the install-recovery.sh script).
edit:4/24/12 I fished testing Calk's CPU governor scripts and reposting it with minor changes. Adding my tweaks back to this post.

Update5: Extreme battery saver tweaks
I added one more zip file which can be used to save the battery life a lot more. If you are really concerning about your battery life and want to extend it, try this new set of tweaks. It's based on Calk's tweaks (I modified the values) and some other tweaks. If you want to use this, I highly recommend you to back up your old init.d files and replace those with the tweak files in init.d.zip files (unzip and move the files to /system/etc/init.d).

[Guide] How to mod Calk's 2cpufreq_governor
2cpufreq_governor script is quite simple/handy tool and it could replace many CPU governing tools. 2cpufreq_governor script can be used to define the CPU governor and change the options on selected governor.

1. The governor selected in this script works as a master governor to control the cpu.
Select the governor which one you want to use. In here, I used 'ondemand' as a default (value "1"). Only one governor works as master governor. If you want to use different governor, change the governor's value from "0" to "1" and reset the old governor's value "0".

2. Govenors
Conservative (default governor on original Calk's tweak)
This governor uses more power and faster than ondemand. Under this governor, the following values are set.

SAMPLING_RATE="35000"
UP_THRESHOLD="75"
DOWN_THRESHOLD="35"
FREQ_STEP="15"

If your kernel does not support this governor, it won't be enabled.

ondemand and lazy
If one of these governors is selected then the following values will be set -
SAMPLING_RATE="50000"
UP_THRESHOLD="75"

interactive Performance Powersave smartass govenors
Just enables the governor. No value changes by these tweaks.

So, for most of you, only the thing you can do with this script is, just selecting the governor whichone you are going to use. If you want to change the detailed options then you can make those changes using 3cpufreq_screestate_scaling script.

[Guide] How to mod Calk's 3cpufreq_screenstate_scaling
3cpufreq_screenstate_scaling script can be used to decide how you want to deal with different phone states. Basically your kernel automatically controls most of it but if you want, you can also have a control over it using this script.
This script can be used as standalone or in conjunction with 2cpufreq_govenor script. The difference between these two scripts are , 2 works as a master governor and 3 is only based on the phone's state.

The things that you need to decide or know before using this script:

awake mode
If the phone is on "awake" status then script uses the "ondemand" cpu governor and you can change the governor as you want (AWAKE_GOVERNOR). Battery save profile only can be used during this "awake" mode.
If the BATTERY_PROFILES_ON is set to "1", then script will use the various governor based on the phone's state and battery level (remaining percentage). For the most of the user, don't need to change the Calk's default settings. But in attached Calk's script, I changed a little to use only ondemand governor for any battery level.
This change would be benificial for the user who is frequently use the phones (not in sleep or lazy mode). If you want to use Calk's original script, you can extract the script from Calk's FD02 Tweaked rom.
As Calkulin already mentioned on this thread, if you are already using any CPI Tweak app like ANDROID OC, Over Click widget, Quick Lock, or SETCPU, then this script won't do anything during the awake mode and sleep mode.

Battery profile 1 and battery profile2 define how your phone reacts based on the battery level and I changed the script a little to use the same ondemand governor regardless the battery level. Regardless of battery level, this script will force to use the maximum 1000000 CPU frequencies.
If you want to differenciate the governor, you can change the governors, max CPU speed, and battery level values based on your demand. Battery profile 1 defines which governor will be used when battery level is above the value in BATTERY_PROFILE_1. Battery profile 2 defines which governor will be used when the battery level is below the value in BATTERY_PROFILE_2.
When the battery level is between BATTERY_PROFILE_1 and BATTERY_PROFILE_2, then the values defined in MAX_CPU_SPEED, MIN_CPU_SPEED and GPU_SPEED will be used.

sleep mode
When your phone goest to sleep mode, this script defines which CPU governor could be used. If you want to change the default CPU governor values during the sleep mode, keep the SLEEP_GOVERNOR_ON value to "1". Otherwise, set the value to "0" (this is Calk's default).
In there, the CPU Max speed will be changed to 800000 to save the battery during the sleep mode. But if you have any issues during the sleep mode, your can increase the SLEEP_MAX_CPU_SPEED value. If you want to save more battery, then you can decrease this value and this is what I'm goint to test for the next experimental test.

This is not a complete tutorial for Calk's CPU tweak but I just wanted to give you the idea how CPU tweak works. For any time, if this tweak does not work as you intended, you can change the values and/or increase/decrease the frequencies and threshold values.
The attached tweaks work on FD19 stock rom and kernel without any issues so far. But I'm not sure if it works on any other repacked kernel and customized roms. Before applying any tweaks, I recommend you to make full nandroid backup and test it. The risk of using these tweaks would be minimal at least you stay on with the values those are already tested and proven.

(attached snapshot shows the CPU times based on two modified Calk's tweaks)
(the last two snapshots are based on my extreme battery saver tweaks - CPU time & battery usage over about 10 hours)

 

[d12unk13astard]

Thanks to you and the other devs for these initd scripts.

I'm currently on blazer 4.1 would these work for that rom? Also I remember seeing one of my favorite apps (link2sd) mentioning that some phones are missing these initd .ko modules and is the reason the app comes up with errors on this phone, since the sdcard is internal storage and my external sdcard is mounted as ext_sd so link2sd can't find my partitions. Will these scripts also make link2sd work now and is there a way I can add the .ko or .ko2 tweaks the app needs to read in order to mount ext sdcard.

Sent from my SPH-D710 using xda premium

 

[kobridge]

Thanks to you and the other devs for these initd scripts.

I'm currently on blazer 4.1 would these work for that rom? Also I remember seeing one of my favorite apps (link2sd) mentioning that some phones are missing these initd .ko modules and is the reason the app comes up with errors on this phone, since the sdcard is internal storage and my external sdcard is mounted as ext_sd so link2sd can't find my partitions. Will these scripts also make link2sd work now and is there a way I can add the .ko or .ko2 tweaks the app needs to read in order to mount ext sdcard.

Sent from my SPH-D710 using xda premium

Because I don't use the link2sd, I'm not sure about that. It seems like we need a little test. I've seen a script that solving your issue in somewhere but not sure where it was. I'll post the info if I find it.

 

[d12unk13astard]

If it has anything to do with partitioning the sdcard I don't need it lol I know how to do that and have used link2sd religiously back on the g2x since it could read the sdcard on that phone(probaly cuz it had the initd scripts already)

Sent from my SPH-D710 using xda premium

 

[gershee]

this looks very interesting..
would love a newer aosp kernel with init.d support..
heading to work for the next 12 hours and no time to unpack the current fd19 aosp kernel and modify it and try it.. would love it if someone with a bit of free time could unpack and modify the current kernel!
link to fd19 aosp: http://www.androidfilehost.com/main..._Blend/Stable_Builds/NOCTURNAL VENUM/KERNELS/

i wouldn't mind testing..

EDIT:
never realized it was as simple as modifying one line of code to add init.d support.. why is it not done more often? by default even..

 

[kobridge]

One more init.d script added in my second post.

 

[sfhub]

I included an Experimental feature, in the Auto Root package, to add init.d support to any stock kernel

I was wondering if anyone could help test it out:
e4gtauto-lite-sfx.exe

You need to be rooted.

Just choose Option E (extra options), then Option E (Add init.d support)

I've tested it on FD19 and EL29 and stock ROMs.

I have *not* tested on any ROMs other than stock. It doesn't modify your kernel, so I don't anticipate anything bad would happen.

I've also tested it in the case where you start with stock kernel, add init.d support, then later install a repacked kernel with builtin init.d support. In that case this will defer to the builtin init.d support in the kernel so the init.d scripts are not run twice. What that means is you don't need to remove this if you should later switch from stock kernel to stock kernel+CWM. If you want to remove it, just choose Option F (Remove init.d support)

If you install a new ROM, then you will need to re-run this option to add init.d support (if the included kernel does not have builtin init.d support)

 

[scarmon25]

I included an Experimental feature, in the Auto Root package, to add init.d support to any stock kernel

I was wondering if anyone could help test it out:
e4gtauto-lite-sfx.exe

You need to be rooted.

Just choose Option E (extra options), then Option E (Add init.d support)

I've tested it on FD19 and EL29 and stock ROMs.

I have *not* tested on any ROMs other than stock. It doesn't modify your kernel, so I don't anticipate anything bad would happen.




I've also tested it in the case where you start with stock kernel, add init.d support, then later install a repacked kernel with builtin init.d support. In that case this will defer to the builtin init.d support in the kernel so the init.d scripts are not run twice. What that means is you don't need to remove this if you should later switch from stock kernel to stock kernel+CWM. If you want to remove it, just choose Option F (Remove init.d support)

If you install a new ROM, then you will need to re-run this option to add init.d support (if the included kernel does not have builtin init.d support)

I'll hook up and give it a shot. Let ya know how it goes. I'm on FD16. Don't see why it would matter if it worked on FD19


Just ran it, Booted fine, Going to load a test init.d script and see what it does,


This is my setup

Stock FD16 ROM
Stock FD19 Modem/Kernel



That is awesome. Loaded a script to change read ahead on SD card, worked like a charm

 

[scarmon25]

Question Sfhub. The folder that it puts on the SD card. The 000root folder I think it is. Does that have to stay on the card or can it be deleted?

 

[sfhub]

Question Sfhub. The folder that it puts on the SD card. The 000root folder I think it is. Does that have to stay on the card or can it be deleted?

It can be removed.

I usually keep it around when I install kernels because it allows me to switch from stock to stock+cwm using a terminal shell on the phone without need for PC. Can also use Mobile ODIN with the zImage's kept there.

 

[scarmon25]

OK. Good to know. Well looks like that little tool does it again. Way to go man. Both ways are complete win. Thanks to the OP for the great write up too. Good info.

 

[kobridge]

I included an Experimental feature, in the Auto Root package, to add init.d support to any stock kernel

I was wondering if anyone could help test it out:
e4gtauto-lite-sfx.exe

You need to be rooted.

Just choose Option E (extra options), then Option E (Add init.d support)

I've tested it on FD19 and EL29 and stock ROMs.

I have *not* tested on any ROMs other than stock. It doesn't modify your kernel, so I don't anticipate anything bad would happen.

I've also tested it in the case where you start with stock kernel, add init.d support, then later install a repacked kernel with builtin init.d support. In that case this will defer to the builtin init.d support in the kernel so the init.d scripts are not run twice. What that means is you don't need to remove this if you should later switch from stock kernel to stock kernel+CWM. If you want to remove it, just choose Option F (Remove init.d support)

If you install a new ROM, then you will need to re-run this option to add init.d support (if the included kernel does not have builtin init.d support)

It took me couple of hours to understand what's achieved by e4gtauto-lite-sfx tool. So, this tool is doing -
1. If kernel is repacked (having init.d support thru init.rc) then it does not execute the script inside of /system/etc/install-recovery.sh.
2. If kernel is stock, then it use the install-recovery.sh thru init.rc (repacked init.rc includes the init.d support but stock only includes install-recovery.sh). Your tool creates and writes a shell command into the install-recovery.sh file.

But in here, my question is -
1. does that shell command actually works and execute the scripts in init.d?
2. have you tested any init.d scripts?
3. If everything works, what's the permission of init.d directory and script files inside of it?

I'm asking this question because I successfully install the tool and rebooted. But init.d scripts were not executed by some reason. Whenever I used SManager, it ran ok and I could see the result after the boot.

 

[sfhub]

But in here, my question is -
1. does that shell command actually works and execute the scripts in init.d?

Yes

2. have you tested any init.d scripts?

Yes

3. If everything works, what's the permission of init.d directory and script files inside of it?

The scripts you run should have "execute" permission set. run-parts in busybox will only run scripts with execute permission set. run-parts is what the repacked kernels are using, so this is not a new requirement

I notice you set your scripts to "chmod 666" so that might be why they aren't running. Try changing to "chmod 755".

I'm asking this question because I successfully install the tool and rebooted. But init.d scripts were not executed by some reason. Whenever I used SManager, it ran ok and I could see the result after the boot.

Either
1) the permissions on your scripts are not set to have "execute" permission
2) you don't have busybox installed in /system/xbin/busybox
3) you are not running a stock kernel nor stock+cwm nor stock+cwm-rogue

My guess is 1 or 2.

With some feedback with testing of custom ROMs, in the latest upload, I actually removed the requirement for busybox to be installed, so if that is your issue, just download the newer one (the link in the original post was updated but I'm providing it here for convenience)

e4gtauto-lite-sfx.exe

 

[scarmon25]

I know that I threw a script in init.d and set permissions to rwx/rwx/rwx and it worked fine. I'm not all that savvy on what 666 and 755 translate to in the terms if rwx but if set to rxw on all three it works like a charm. Sfhub or OP. I know its a little off topic but since you seem to know. How is that translated from rwx to ###

 

[sfhub]

I know that I threw a script in init.d and set permissions to rwx/rwx/rwx and it worked fine. I'm not all that savvy on what 666 and 755 translate to in the terms if rwx but if set to rxw on all three it works like a charm. Sfhub or OP. I know its a little off topic but since you seem to know. How is that translated from rwx to ###

r w x (4 2 1)

owner group other

So if you wanted the owner to be able to read, write, and execute the file and everyone else have no permissions allowed, you would do "chmod 700" (that 7 is comprised of 4+2+1)

If you wanted owner, group, other to have read,execute permission (but not write permission) "chmod 555" (5 being 4+1)

755 would be rwxr-xr-x

 

[scarmon25]

OK. That makes sense. That is actually really simple. Thanks.

 

[kobridge]

Yes


Yes


The scripts you run should have "execute" permission set. run-parts in busybox will only run scripts with execute permission set. run-parts is what the repacked kernels are using, so this is not a new requirement

I notice you set your scripts to "chmod 666" so that might be why they aren't running. Try changing to "chmod 755".


Either
1) the permissions on your scripts are not set to have "execute" permission
2) you don't have busybox installed in /system/xbin/busybox
3) you are not running a stock kernel nor stock+cwm nor stock+cwm-rogue

My guess is 1 or 2.

With some feedback with testing of custom ROMs, in the latest upload, I actually removed the requirement for busybox to be installed, so if that is your issue, just download the newer one (the link in the original post was updated but I'm providing it here for convenience)

e4gtauto-lite-sfx.exe

Working like a charm without the SManager app. Permission set to 755. I'll update my thread with this info.
Thank you guys!

 

[gershee]

can't wait to try this in the morning.. thanks guys.. this was exactly what I have been looking for the past couple weeks.. stoked.

 

[sfhub]

For example, if you have 10 scripts in init.d and just want to selectively run from those, you can use SManager.

BTW for the auto root init.d support, you pointed out the way to selectively run init.d scripts with your earlier questions. If you want to disable an init.d script, just chmod 666 the script. If you want to enable it, chmod 755 the script.