init
is the first
process after kernel started. The corresponding source code lies in: /system/core/init.
It does the following tasks step by step:
1.
Initialize log system.
2.
Parse /init.rc and
/init.%hardware%.rc.
3.
Execute early-init action in
the two files parsed in step 2.
4.
Device specific initialize.
For example, make all device node in /dev and download firmwares.
5.
Initialize property system.
Actually the property system is working as a share memory. Logically it looks
like a registry under Windows system.
6.
Execute init action in the
two files parsed in step 2.
7.
Start property service.
8.
Execute early-boot and boot
actions in the two files parsed in step 2.
9.
Execute property action in
the two files parsed in step 2.
10.
Enter into an infinite loop
to wait for device/property set/child process exit events. For example, if an
SD card is plugged in, init will receive a device add event, so it can make
node for the device. Most of the important process is forked in init, so if any
of them crash, init will receive a SIGCHLD then translate it into a child
process exit event, so in the loop init can handle the process exit event and
execute the commands defined in *.rc(it will run command onrestart).
The .rc file is a script file defined by
Android. The default is /system/core/rootdir/init.rc. We can take a loot at the
file format (/system/core/init/readme.txt is a good overall introduction of the
script). Basically the script file contains actions and services.
Actions
-------
Actions are named sequences of commands. Actions
have a trigger which is used to determine when the action should occur.
When an event which matches an
action's trigger occurs, that action is added to the tail of a to-be-executed
queue (unless it is already on the queue).
Each action in the queue is dequeued in sequence
and each command in that action is executed in sequence.
Init handles other activities (device
creation/destruction, property setting, process restarting) "between"
the execution of the commands in activities.
Actions take the form of:
on <trigger>
<command>
<command>
<command>
...
Services
--------
Services are programs which init launches and
(optionally) restarts when they exit.
Services
take the form of:
service <name> <pathname> [
<argument> ]*
<option>
<option>
...
Options
-------
Options are modifiers to services.
They affect how and when init runs the
service.
Triggers
--------
Triggers are strings which can be used to match
certain kinds of events and used to cause an action to occur.
The builtin supported commands are defined in
device/system/init/keywords.h. Commands are implementd in
device/system/init/bultins.c.
The init program only executes five kinds of
triggers: “early-init”, “init”, “early-boot”, “boot”, “property:*”. Take a look
at the following line in default init.rc.
class_start
default
This line is a command for the action
corresponding to “boot” trigger. It will start all services whose class name
equals to “default”. By default, if no class option is defined for a service,
the service’s class name is “default”. So this line will start all the services
in the order of position in the file by default. (BTW, you can start any
service using start commands, if you like.) Any service is run as a forked
process of init, take a look at the source code of service_start in /system/core/init.c.
So according to the default init.rc, the
following services will be executed step by step:
console
: star a shell. The source is in
device/system/bin/ash.
adbd
: start adb daemon. The source is in
device/tools/adbd. By default is disabled.
servicemanager
: start binder system. The
source is in device/commands/binder.
mountd
: mount all fs defined in
/system/etc/mountd.conf if started, receive commands through local socket to
mount any fs. The source is in device/system/bin/mountd.
debuggerd
: start debug system. The source is in
device/system/bin/debuggerd.
rild
: start radio interface layer daemon. The source
is in device/commands/rind.
zygote
: start Android Java Runtime and start system
server. It’s the most important service. The source is in device/servers/app.
media
: start AudioFlinger, MediaPlayerService and
CameraService. The source is in device/commands/mediaserver.
bootsound
: play the default boot sound
/system/media/audio/ui/boot.mp3. The source is in device/commands/playmp3.
dbus
: start dbus daemon, it’s only used by BlueZ.
The source is in device/system/Bluetooth/dbus-daemon.
hcid
: redirect hcid’s stdout and stderr to the
Android logging system. The source is in device/system/bin/logwrapper. By
default is disabled.
hfag
: start Bluetooth handsfree audio gateway, it’s
only used by BlueZ. The source is in device/system/Bluetooth/bluez-utils. By
default is disabled.
hsag
: start Bluetooth headset audio gateway, it’s
only used by BlueZ. The source is in device/system/Bluetooth/bluez-utils. By
default is disabled.
installd
: start install package daemon. The source is in
device/servers/installd.
flash_recovery
: load /system/recovery.img.
The source is in device/commands/recovery/mtdutils.
Zygote
service does the
following tasks step by step:
1.
Create JAVA VM.
2.
Register android native
function for JAVA VM.
3.
Call the main function in the
JAVA class named com.android.internal.os.ZygoteInit whose source is
device/java/android/com/android/internal/os/ZygoteInit.java.
a)
Load ZygoteInit class
b)
Register zygote socket
c)
Load preload classes(the
default file is device/java/android/preloaded-classes)
d)
Load preload resources
e)
Call Zygote::forkSystemServer
(implemented in device/dalvik/vm/InternalNative.c) to fork a new process. In
the new process, call the main function in the JAVA class named
com.android.server.SystemServer, whose source is in
device/java/services/com/android/server.
i.
Load libandroid_servers.so
ii.
Call JNI native init1
function implemented in
device/libs/android_servers/com_android_server_SystemServers. It only calls
system_init implemented in device/servers/system/library/system_init.cpp.
l
If running on simulator,
instantiate AudioFlinger, MediaPlayerService and CameraService here.
l
Call init2 function in JAVA
class named com.android.server.SystemServer, whose source is in
device/java/services/com/android/server. This function is very critical for
Android because it start all of Android JAVA services
.
l
If not running on simulator,
call IPCThreadState::self()->joinThreadPool() to enter into service
dispatcher.
init1 初始化一些本地库,包括audio, media , camero ,内部 执行过程 /system_init.cpp
extern "C" status_t system_init()
{
LOGI("Entered system_init()");
sp<ProcessState> proc(ProcessState::self());
sp<IServiceManager> sm = defaultServiceManager();
LOGI("ServiceManager: %p/n", sm.get());
sp<GrimReaper> grim = new GrimReaper();
sm->asBinder()->linkToDeath(grim, grim.get(), 0);
char propBuf[PROPERTY_VALUE_MAX];
property_get("system_init.startsurfaceflinger", propBuf, "1");
if (strcmp(propBuf, "1") == 0) {
// Start the SurfaceFlinger
SurfaceFlinger::instantiate();
}
// On the simulator, audioflinger et al don't get started the
// same way as on the device, and we need to start them here
if (!proc->supportsProcesses()) {
// Start the AudioFlinger
AudioFlinger::instantiate();
// Start the media playback service
MediaPlayerService::instantiate();
// Start the camera service
CameraService::instantiate();
// Start the audio policy service
AudioPolicyService::instantiate();
}
// And now start the Android runtime. We have to do this bit
// of nastiness because the Android runtime initialization requires
// some of the core system services to already be started.
// All other servers should just start the Android runtime at
// the beginning of their processes's main(), before calling
// the init function.
LOGI("System server: starting Android runtime./n");
AndroidRuntime* runtime = AndroidRuntime::getRuntime();
LOGI("System server: starting Android services./n");
runtime->callStatic("com/android/server/SystemServer", "init2");
// If running in our own process, just go into the thread
// pool. Otherwise, call the initialization finished
// func to let this process continue its initilization.
if (proc->supportsProcesses()) {
LOGI("System server: entering thread pool./n");
ProcessState::self()->startThreadPool();
IPCThreadState::self()->joinThreadPool();
LOGI("System server: exiting thread pool./n");
}
return NO_ERROR;
}
调用 init2初始化系统服务
runtime->callStatic("com/android/server/SystemServer", "init2");
SystemServer::init2 will start a new thread to
start all JAVA services as follows:
Core Services:
1.
Starting Power Manager
2.
Creating Activity Manager
3.
Starting Telephony Registry
4.
Starting Package Manager
5.
Set Activity Manager Service
as System Process
6.
Starting Context Manager
7.
Starting System Context
Providers
8.
Starting Battery
Service
9.
Starting Alarm Manager
10.
Starting Sensor Service
11.
Starting Window Manager
12.
Starting Bluetooth Service
13.
Starting Mount Service
Other services
1.
Starting Status Bar Service
2.
Starting Hardware Service
3.
Starting NetStat Service
4.
Starting Connectivity Service
5.
Starting Notification Manager
6.
Starting DeviceStorageMonitor
Service
7.
Starting Location Manager
8.
Starting Search Service
9.
Starting Clipboard Service
10.
Starting Checkin Service
11.
Starting Wallpaper Service
12.
Starting Audio Service
13.
Starting HeadsetObserver
14.
Starting AdbSettingsObserver
Finally SystemServer::init2 will call
ActivityManagerService.systemReady to launch the first activity by senting
Intent.CATEGORY_HOME intent
.
There is another way to start system server,
which is through a program named system_server whose source is
device/servers/system/system_main.cpp. It also calls system_init to start
system services. So there is a question: why does Android have two methods to
start system services? My guess is that directly start system_server may have
synchronous problem with zygote because system_server will call JNI to start
SystemServer::init2, while at that time zygote may not start JAVA VM yet. So
Android uses another method. After zynote is initialized, fork a new process to
start system services.
分享到:
相关推荐
- Kernel:内核加载并初始化硬件驱动。 - Init:内核启动init进程,这是用户空间的第一个进程,具有root权限。 - System Server:init启动System Server进程,它是Android框架层的核心。 - Zygote:System ...
Android系统的运行环境始于Kernel启动,然后通过App_main进程初始化Android Runtime的JAVA运行环境。这里的关键角色是Zygote进程,它是Android的第一个进程,所有的Android应用都是通过Zygote的fork操作生成的子进程...
在《start_kernel分析.pdf》和《start_kernel分析2.pdf》中,可能详细讨论了`start_kernel`函数的各个阶段和内部机制,包括模块初始化、系统定时器设置、系统调用表构建等内容。这些文档可能还涵盖了如何调试KERNEL...
boot.img的结构包括kernel、ramdisk、secondstage等部分,其中还有一个称为boot header(bootheader)的部分,它是内核初始化参数表,对应于boot_img_hdr结构。这个结构中定义了多种成员变量,比如魔术字、内核大小...
`start_kernel()`函数是内核启动过程中的另一个核心环节,它的作用主要包括初始化中断处理程序、设置定时器、初始化设备驱动程序等。此外,还会进行一些系统级别的初始化工作,如设置进程调度策略等。 **代码示例**...
在Android系统中,Linux内核的启动流程是一个至关重要的环节,它决定了系统的初始化和各种服务的启动。这个过程可以分为三个主要阶段,每个阶段都包含了关键的初始化任务。以下是详细的解释: 1. **内核初始化阶段 ...
2. **内核初始化**: - `start_kernel()`:这是内核初始化的起点,它会在`/init/main.c`中被调用。 - `setup_arch()`:用于设置与硬件架构相关的参数。 - `rest_init()`:执行剩余的初始化工作。 - `init()`:...
• bootloader---初始化、从Flash读取Kernel镜像及一些必须的配置信息,引导kernel启动 • linuxkernel启动linux内核 • init进程启动 • init进程读取init.rc启动必要的daemon程序,如:adbd、...
描述中提到驱动程序会在`sys/class/timed_output`目录下创建设备节点,这通常是通过在内核模块初始化时调用`device_create()`函数实现的。这个节点是用户空间访问驱动的接口,使得Hal层可以通过读写该节点的属性来...
这一过程中涉及BIOS初始化、GRUB引导加载器的选择、内核初始化等步骤。理解这些过程有助于更好地配置和调试系统。 - **内存管理**:Linux内核采用分页机制来管理内存,通过将物理内存划分成固定大小的页面进行管理...
Bootloader是在操作系统内核运行之前执行的一段代码,它的主要作用是完成对硬件设备的基本初始化,创建并传递必要信息给操作系统内核,并负责引导和加载内核,最终调用操作系统内核。Bootloader对于嵌入式设备的启动...
使用repo工具初始化并同步Android的最新版本源代码。在创建的`android`目录下执行以下命令: ``` root@ubuntu:~# mkdir android root@ubuntu:~# cd android root@ubuntu:~/android# repo init -u ...
总结来说,Android系统的开机启动涉及从硬件层面的bootloader到软件层面的kernel、init、ServiceManager和Zygote等多个层次的初始化。这些组件共同构建了Android系统的基石,确保了系统能够正确、高效地启动并运行...
然后,在一个工作目录下,使用`repo`初始化源代码仓库: ```bash mkdir /work/android-froyo-r2 cd /work/android-froyo-r2 repo init -u git://android.git.kernel.org/platform/manifest.git -b froyo ``` 这里...
- 例如,要获取Android 1.5的源码,可以使用命令`repo init -u git://android.git.kernel.org/platform/manifest.git -b cupcake`初始化并指定分支名称为`cupcake`,之后使用`repo sync`同步源码。这种方式同样适用...
2. init目录:该目录包含了Android系统启动过程中的初始化代码和其他相关文件。这些文件负责引导系统进入不同的运行模式,设置初始环境,并启动系统服务。 3. arch目录:arch目录包含了针对特定硬件架构的代码,...
2. **Linux Kernel 初始化**: 内核被加载后,开始执行一系列的初始化操作,包括硬件驱动的加载、内存管理模块的配置等,这些操作为后续进程的运行奠定了基础。 3. **Built-in Binaries**: 内核加载完成后,会执行...
总之,编译Android 2.3源码在Ubuntu环境下需要安装必要的软件,设置环境,初始化源码仓库,下载源码,最后进行编译。整个过程可能遇到各种问题,如网络连接、文件权限或配置错误等,需要根据实际情况调整和解决。在...