GearBoot is a very simple program which can run executables during boot dynamically.
GearBoot supports four different boot stages.
GearBoot is very lightweight and superfast. It assigns each of the executables with a unique PID.
The logfile is
During GearBoot runtime
PATH variable is set to:
If GearLock came pre-installed in your system then gearboot dir can be found at
If it was a manual installation then it should be at
For most developers
boot-comp stage should be fine and shouldn't mess with other stages unless you know what you're doing!
Use the custom-core package to work with gearboot scripts
To be honest, the first three stages (
boot-post ) are passed real quick but there are some key changes in between.
Below I will try to explain what and how each of the gearboot stages that matter.
This is basically valid before you see the early console-tty blinking after grub has loaded your kernel and is about to switch on the secondary-ramdisk. In this stage android-system won't be running or active. Not a good idea to think of hooking into it unless you know what you're doing.
There are actually a few more *early stages before
post-fs to be completed when android-x86 switches to the secondary ramdisk. Now you might be wondering why don't we just hook those stages also ?
In simple words, it's literally unnecessary and not really a good thing to do. Even hacking into something over the
post-fs stage also seems quite rare though.
As much I can understand, this stage can be marked when you get to see the OS hostname blinking in the early tty screen (command line). This is also two steps before you see the bootanimation to be appearing.
This is obviously after
post-fs stage. During this stage,
build.prop and most of the system modules are already loaded.
The bootanimation comes after this stage.
This is the beginning of bootanimation and is valid till android-x86 enter the graphical interface.
This is after bootanimation then you see something like
Android is loading... in graphical interface.
To be noted that this is basically the final stage and no more stages are to come after this.
For most cases it's suggested to target this stage for your executable.
Write GearBoot logfile
gearboot.log is present in
/gearlock/tmp which holds the records of what executables were run during each boot-stage. So if you want to write something over your executable name in the log then you can use
write_gblog in your gearboot-executable.
So, let's say
my-cool-program3 was your gearboot-executable and then
gearboot.log was like
# Start of boot-post stage @ Wed XYZ 123456:12:44 : boot-post : my-cool-program 123456:12:45 : boot-post : my-cool-program2 # Start of boot-comp stage @ Wed XYZ 123456:12:47 : boot-comp : my-cool-program3 123456:12:48 : boot-comp : my-cool-program4
Now, if you do this in
write_gblog "Opps, something wrong"
gearboot.log will be like:
# Start of boot-post stage @ Wed XYZ 123456:12:44 : boot-post : my-cool-program 123456:12:45 : boot-post : my-cool-program2 # Start of boot-comp stage @ Wed XYZ 123456:12:47 : boot-comp : my-cool-program3 : Opps, something wrong 123456:12:48 : boot-comp : my-cool-program4
If you want to re-execute the boot executables without rebooting as a user then you can do it easily. (Not recommended)
Usage: gearboot <boot-stage> Example: gearboot s2 # For executing post-fs-data executables <Boot-Stages> s1 : post-fs s2 : post-fs-data s3 : boot-post s4 : boot-comp
- GearProp can be useful while changing props during boot
- Check GearBoot Executables section in GetStarted page
- Take a look at environment variables
- Must check out GearLock Dev Utilities