[Android Software/Hacking General [Developers Only]] dk_zero-cool:
Most people in here knows what init.d is, and almost all their devices (If not all) has init.d implemented, a widely used feature that a lot of people (Users and Devs) finds essential for any ROM. There is however one major issue with init.d implementations on Android, that is, we do not have any standards for how it should work.

The two most used methods are

Starting a service at boot which executes 'run-parts' on the init.d folder

Doing a direct execution of 'run-parts' at boot on the init.d folder

In the init.rc code they don't look much different from one another. Both will make sure that run-parts is executed from the onboot section, but they could not be further apart from the way they do it.

Executing run-parts from a service will transfer the whole execution to a new process, meanwhile init continues with the rest of the boot process. This means that all of the scripts are executed while the phone continues to start it's services and prepare everything. Depending on the scripts in init.d and the speed of the device, it might even start completely into the UI before init.d has finished all of it's scripts.

Executing run-parts directly from init.rc however, will execute the init.d scripts in the same process. This means that init cannot continue with anything until all of the init.d scripts has finished. This is the way that init.d should work, and here is why.

Some times you will get or make a script where it is essential that it get to finish before anything else is executed or started. One example could be sd-ext which job is to move content between partitions. This is not a job that works well while a device is booting, as a lot of the data being parsed around is actually being used by the system during boot.

Also should you have a script that needs to be executed while the device is booting, then it is quite simple to accomplish this by adding a function to the script and start that into another process from within the script. However this does not work the other way around. So you can use the second init.d implementation for both purposes.

But it gets even worse. This article explains how to add init.d to ROM's without altering the ramdisk. The problem is that this introduces a third way of how init.d might operate, as this will not execute init.d neither before or during boot, but after. Looking at the default implementation of install-recovery.sh, this file is not executed until after the UI has been started, meaning when the device is fully booted.

We need a standard here people. Something that will ensure anyone building init.d scripts of how and when the scripts will be executed. Otherwise we are limited to small operations where init.d's implementation has no factor, in which case we might as well just stop implementing it in the first place.

Last I want to make a notice to anyone that thinks it is wise to place Sleep commands in init.d scripts.

#!/system/bin/sh

# Wait until we see some android processes to consider boot is more or less complete
while ! pgrep com.android ; do
sleep 1
done

# ... The rest of the code

This is an example I have made. First consider all of the scripts in init.d that is set to be executed after this one. Now consider adding this script to ROM's with the second init.d implementation (Hint, the device will never boot).

The better way to do something like this, is like fallowing

#!/system/bin/sh

)
# Wait until we see some android processes to consider boot is more or less complete
while ! pgrep system_server; do
sleep 1
done

# ... The rest of the code
) &

if pgrep logwrapper; then
killall logwrapper
fi

First of all this will allow the rest of the init.d scripts to be executed right away. Secondly it will allow anyone with the second init.d implementation to boot in the first place.

Note the "killall logwrapper". Almost every init.d implementation adds logwrapper to execute run-parts, "/system/bin/logwrapper /system/bin/run-parts /system/etc/init.d". However, logwrapper will not continue until all of the scripts sub-processes has finished. So we will have to force our way out. The script will continue normally below the kill code and the rest of init.d will as well.