Init process && Parse Android startup script init.rc && modify it so that you do not start an sh file in Android && init.rc

After Android starts, the first process that the system executes is a executable program called Init. The following features are available: Device management, parsing startup scripts, performing basic functions, starting various services. The path to the code:
System/core/init, the result of the compilation is an executable file: init. This init executable is the first user-space program that the system runs, and it runs as a daemon. The startup script is the init.rc to be said below.

===========================================================================================

Using the startup script init.rc in Android, you can do some simple initialization during the initialization of the system. This script is directly installed on the target system's root filesystem and parsed by the Init executable. Use the method reference System/core/init/readme.txt, keyword reference system/core/init/keyword.h.
Init.rc is the startup script that is executed after Init is started, and its syntax mainly includes the following:
Commands: Command
Actions: Actions
Triggers: Trigger Condition
Services: Service
Options: Option
Propertise: Properties
(1) Commands is a basic operation, for example:
Mkdir/sdcard 0000 System System
Mkdir/system
Mkdir/data 0771 System System
Mkdir/cache 0770 System Cache
Mkdir/config 0500 Root root
Mkdir/sqlite_stmt_journals 01777 Root root
Mount Tmpfs tmpfs/sqlite_stmt_journals size=4m

These commands are parsed in the init executable and are then invoked to implement the related function.
(2) Actions represent a series of commands, usually called in triggers (trigger conditions), in the form of actions and trigger conditions:
On <trigger>
<command>
<command>
<command>
Examples of use of actions are as follows:
On Init
Export Path/sbin:/system/sbin:/system/bin:/system/xbin
Mkdir/system
Init represents a trigger condition that, after the triggering event occurs, is called an "action" to set the environment variable and create the directory.
(3) Services (service) usually means that an executable program is launched and the options (option) is an additional content of the service that is used in conjunction with the service.
Service Vold/system/bin/vold
Socket Vold Stream 0660 root mount
Service Bootsound/system/bin/playmp3
User Media
Group Audio
OneShot
Vold and Bootsound are the names of two services, respectively,/system/bin/vold and/system/bin/playmp3 are the executable programs they correspond to. sockets, user, group, oneshot are the options used with the service. Where the OneShot option indicates that the service is started only once, and if there is no oneshot option, the executable will persist-if the executable is killed, it will be restarted.
(4) Properties (attributes) are some of the values used in the system and can be set up and read.
SetProp ro. Foreground_app_mem 1536
SetProp Ro.sf.hwrotation 90

On Property:ro.kernel.qemu=1
Start ADBD
SetProp is used to set properties, which can be used to determine properties, where the properties are consistent across the entire Android system. The init script keyword can refer to the INIT process's System/core/init/keyword.h file. Init.rc the use of the method, you can refer to the documentation system/core/init/readme.txt. If you want to modify the boot process only need to modify INIT.C (system/core/init) or init.rc content.

The above describes the various components of init.rc, which have a fixed order of execution, which is determined by the four keywords Early-init, init, early-boot, boot. A typical RC file is written in the following notation:
On Early-init
--------------

On Init
--------------

On Early-boot
--------------

On boot
--------------

The 4 parts of the RC file can be scrambled in order, but after parsing the execution sequence is fixed and the execution sequence is as follows: Boot, early-boot, Early-init, Init
=============================================================================================================== ===

Now that Android is running on Linux, can we just start Linux and not start Android, so that the hardware running requirements are greatly reduced and kernel services are available in devices that do not require a graphical interface. We can do that by modifying the init.rc.

An important process in Android system applications is zygote, where all Java application processes are derived from zygote, zygote this process is "birth son". The zygote process was launched after the Linux kernel startup through this file, specifically see init.rc in this paragraph: service Zygote/system/bin/app_process-xzygote/system/bin --zygote--start-system-server.   A period of analysis of this code: start the service name zygote. /system/bin/app_process: The specific path of the bin file of the process followed by the startup parameter-xzygote/system/bin--zygote--start-system-server.

=================================================================================================

Suppose the file name you want to build is iperf. (1) Place the Iperf in any directory in codebase (the directory must be searchable when searching for android.mk), such as System/iperf/iperf. (2) Add a android.mk file under the System/iperf directory, with the following contents:
Local_path:= $ (call My-dir)
Product_copy_files + = $ (local_path)/iperf:system/iperf/iperf
Recompile the codebase and the file will be built into the System/iperf directory of your phone. Note This method prohibits copying the apk file.

=================================================================================================

Assuming that we have the ADB debug command to adjust the hardware module of a peripheral, the next step, need to let the system boot automatically run these commands and normal start the work of the module. At this time, it is necessary to use the SH to combine these commands and put them into the init.rc to achieve this (do not put in the init.project.rc, will affect the WIFIBT).

For the reason of execution permission, KO file can be placed under vendor/system/lib/modules (cannot be placed in vendor corresponding/data directory, release version/data no permission insmod), The executable file, including the shell, is placed under the/system/bin of vendor so that it can be executed at all times.

[CPP]View Plaincopy

2. #!/system/bin/sh
4. Pkg_dir=/system/lib/modules
6. App_dir=/system/bin
10. CD $PKG _dir
12. Cur_pkg_dir= ' pwd '
14. echo "Cur_pkg_dir = $CUR _pkg_dir"
18. Insmod $PKG _dir/accel_qlulpsh.ko
20. Insmod $PKG _dir/mag_qlulpsh.ko
22. Insmod $PKG _dir/gyro_qlulpsh.ko
24. Insmod $PKG _dir/pedometer_qlulpsh.ko
26. Insmod $PKG _dir/gestures_qlulpsh.ko
28. Insmod $PKG _dir/contexts_qlulpsh.ko
32. CD $APP _dir
34. Cur_app_dir= ' pwd '
36. echo "Cur_app_dir = $CUR _app_dir"
40. #Program the Sensor Hub
42. Echo "Sensorhub programming using loader APP"
44. Sleep 1
46. ./qlulpsh_loader_app-i./ulpsh_s2_main.shexe-b 1-s 1-t 10-d
48. Sleep 1
50. ./qlulpsh_loader_app-c 1-a 0002
54. echo "Starting Sensorhub ..."
56. echo 1 >/sys/devices/virtual/ql_sensors/qlulpsh/intr_enable
58. echo >/sys/devices/virtual/ql_sensors/qlulpsh/ffe_runcnt
60. Sleep 1
64. echo "Starting sensorservice ..."
66. Sensorservice &

Note: (1) Two executable files to add./, otherwise prompt executable not found, you need to indicate the current directory. (2) Consider the actual implementation of the hardware, SH has a sleep statement, some read operation to wait for the real hardware initialization OK. (3) Sensorservice & Activate the Sensor service of Android system.

In Init.rc, fill in the following statement and start a shell with service.

[CPP]View Plaincopy

1. # Senhub Scripts
2. Service myshell/system/bin/sensorhub_init.sh
3. OneShot

Init process && Resolve Android startup script Init.rc && modify it so that you do not start an sh file in Android && init.rc