Android手机启动流程探究

Byadmin
on 2025-05-13 00:06:13
in 2019年世界杯

按下手机电源键后，手机会依次经历：点亮屏幕->开机动画->进入Launcher几个阶段。而Android系统具体是如何启动起来的呢？作为技术人员，我很直接地就会想到以下疑惑的问题：

启动逻辑如何？ 在机器中，启动的时候调用的文件流程步骤如何？ 对应在源码中的代码如何？对应编译生成的img文件，功能分类如何？

为了回答以上问题，依次研究之。

1.启动逻辑

1.1手机开机基本流程

按下电源键后手机到底做了些什么？我们首先解答这个问题。

大致流程图如下（MTK平台手机为例，其他平台大同小异）： 图1 手机开机基本流程图

上电：按下电源键，其实就是对电路的接通。而接通电路后就会产生脉冲，首先将激发电源管理芯片(PMU)，PMU检测到脉冲信号，产生最重要的一个东西：时钟脉冲。对于MTK平台而言，就是内部的32KHz时钟晶体模块开始工作，输出外部RTC的工作电压，为此实时时钟晶体起振。

复位：然后，PMU输出复位信号RSTON给手机CPU，CPU便开始启动系统自检程序，进行自检。

工作电压输出：手机完成自检后，CPU通过IIC总线控制PMU输出手机各电路的工作电压，如VDD1、VDD2、VDD3、AVDD等。

**13M晶体工作：**CPU得到工作时钟和工作电压后，便输出REF_ON信号，控制13M电路的工作，使其产生13MHz时钟，一路给CPU提供工作主时钟，另一路给射频主芯片提供基准频率源。

**调用开机程序：**CPU自检完成，并得到工作电压和主时钟后，便通过IIC总线校准PMU输出的各路工作电压，校准完成后便输出片选信号和地址信号给FLASH，调用开机程序，实现开机。

建立通信连接：手机开机后，CPU从FLASH中调用射频参数，通过广播控制信道（BCCH）接收小区信号强度，如果手机内有SIM卡或UIM卡，手机便将卡中的相关信息发射给临近的基站，并接收来自基站的信息，从而与对应的网络实现连接，即通常所说的搜网。

待机：搜网完成后，手机便处于等待状态，期间手机还会通过慢速辅助控制信道（SACCH）周期性地与基站交换一些信息，如信号强度、频率同步、接收质量和接收电平等。

1.2Android软件系统启动流程

不难看出，软件系统启动在第5步：调用开机程序。

软件系统启动流程如下图所示： 图2 Android系统启动流程图

init进程的启动： Init属于用户级进程，在内核启动（载入内存，初始化所有设备驱动和数据结构）结束后运行，接着根据init.rc和init.XXX.rc脚本文件建立ServiceManager以及Zygote等基本服务；创建完毕后，init进程并不会退出，而是转为property service功能；

ServiceManager与Zygote奠定了android的基础。Zygote进程建立起来，才会建立Android的运行空间。

Zygote 的建立过程： 首先Zygote在init.rc的描述： Service zygote/system/bin/app_process-Xzygote/system/bin –zygote –start-server

所以Zygote从main（…）@frameworks\base\cmds\app_main.cpp开始

建立Java runtime ：runtime.start（…）；

建立虚拟机

通过main（…）@com.android.interal.os.ZyoteInit,建立真正的zygote；

接着登记listen端口（都是以socket通信方式）：resisterZygoteSocket（） 接着startSystemServer（），进入zygote服务框架

建立好后的Zygote通过socket通信，接收ActivityManagerService的请求 fork应用程序。

SystemServer的建立：在建立Zygote中startSystemServer在Zygote上forck了一个com.android.server.SystemServer，于是SystemServer就建立了，在init2（）中建立一个线程来new service来建立Android需要的服务 和Add service把这些服务 到 ServiceManager（service_list）中。

在SystemService的启动完Android所有服务后调用（XXX.systemReady（））来通知所有服务系统准备就绪，Home就是在这个ActivityManager. systemReady（）通知过程中建立的 这样 Android系统就启动结束了。具体的细节，将在后面代码分析中进行描述。

2.启动时调用手机文件流程

先查看下手机中到底有哪些文件。

首先通过adb连接进入手机：

adb shell

查看手机根目录下文件情况：

ls

结果返回如下，发现文件挺多：

shell@android:/ $ ls

acct

advanced_meta_init.rc

boot.ver

cache

config

custpack

d

data

default.prop

dev

emmc@android

emmc@cache

emmc@custpack

emmc@ebr1

emmc@mobile_info

emmc@protect_f

emmc@protect_s

emmc@sec_ro

emmc@usrdata

etc

factory_init.project.rc

factory_init.rc

fstab

init

init.aee.customer.rc

init.charging.rc

init.goldfish.rc

init.modem.rc

init.project.rc

init.protect.rc

init.rc

init.ssd_nomuser.rc

init.trace.rc

init.usb.rc

init.xlog.rc

meta_init.modem.rc

meta_init.project.rc

meta_init.rc

mnt

mobile_info

proc

protect_f

protect_s

recovery.ver

res

root

sbin

sdcard

storage

sys

system

ueventd.goldfish.rc

ueventd.rc

vendor

shell@android:/ $

好多文件，搜索了一下，没有直接对这些文件进行解释的资料，这部分内容待学习Android系统内核书籍后再添加。

但是，通过之前的流程图，我们需要知道的是 —— Android的从Linux启动主要分为四个过程：

1、 init进程的启动； 2、 native进程启动； 3、 system service，android服务启动； 4、 Home的启动

而init进程的启动，首先要加载的是根目录下的init.rc和init.XXX.rc文件。 而system service在/system/bin/servicemanager下。

3.源码路径和分析

3.1主要源码路径

先总述一下主要源码路径：

platform\system\core\init

platform\frameworks\base\cmds\servicemanager\

platform\frameworks\base\cmds\app_process\

platform\frameworks\base\preloaded-classes

platform\dalvik\vm\native\

3.2系统启动源码分析

Android系统在启动时首先会启动Linux系统，引导加载Linux Kernel并启动init进程。Init进程是一个由内核启动的用户级进程，是Android系统的第一个进程。该进程的相关代码在platform\system\core\init\init.c。在main函数中，有如下代码：

open_devnull_stdio();

log_init();

INFO("reading config file\n");

init_parse_config_file("/init.rc");

/* pull the kernel commandline and ramdisk properties file in */

import_kernel_cmdline(0);

get_hardware_name(hardware, &revision);

snprintf(tmp, sizeof(tmp), "/init.%s.rc", hardware);

init_parse_config_file(tmp);

这里会加载解析init.rc和init.hardware.rc两个初始化脚本。*.rc文件定义了在init进程中需要启动哪些进程服务和执行哪些动作。其详细说明参见platform\system\core\init\reademe.txt。init.rc见如下定义：

service servicemanager /system/bin/servicemanager

user system

critical

onrestart restart zygote

onrestart restart media

service vold /system/bin/vold

socket vold stream 0660 root mount

ioprio be 2

service netd /system/bin/netd

socket netd stream 0660 root system

socket dnsproxyd stream 0660 root inet

service debuggerd /system/bin/debuggerd

service ril-daemon /system/bin/rild

socket rild stream 660 root radio

socket rild-debug stream 660 radio system

user root

group radio cache inet misc audio sdcard_rw

service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server

socket zygote stream 666

onrestart write /sys/android_power/request_state wake

onrestart write /sys/power/state on

onrestart restart media

onrestart restart netd

service drm /system/bin/drmserver

user drm

group system root inet

具体解析过程见platform\system\core\init\Init_parser.c。解析所得服务添加到service_list中，动作添加到action_list中。

接下来在main函数中执行动作和启动进程服务：

execute_one_command();

restart_processes();

通常init过程需要创建一些系统文件夹并启动USB守护进程、Android Debug Bridge守护进程、Debug守护进程、ServiceManager进程、Zygote进程等。

<1>ServiceManager进程

ServiceManager进程是所有服务的管理器。由init.rc对ServiceManager的描述service servicemanager /system/bin/servicemanager可知servicemanager进程从platform\frameworks\base\cmd\servicemanager\Service_manager.cpp启动。在main函数中有如下代码：

int main(int argc, char **argv)

{

struct binder_state *bs;

void *svcmgr = BINDER_SERVICE_MANAGER;

bs = binder_open(128*1024);

if (binder_become_context_manager(bs)) {

LOGE("cannot become context manager (%s)\n", strerror(errno));

return -1;

}

svcmgr_handle = svcmgr;

binder_loop(bs, svcmgr_handler);

return 0;

}

首先调用binder_open()打开Binder设备(/dev/binder)，调用binder_become_context_manager()把当前进程设置为ServiceManager。ServiceManager本身就是一个服务。

int binder_become_context_manager(struct binder_state *bs)

{

return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);

}

最后binder_loop()进入循环状态，并设置svcmgr_handler回调函数等待添加、查询、获取服务等请求。

<2> Zygote进程

Zygote进程用于产生其他进程。由init.rc对zygote的描述service zygot /system/bin/app_process可知zygote进程从platform\frameworks\base\cmds\app_process\App_main.cpp启动。在main函数中有如下代码：

if (0 == strcmp("--zygote", arg)) {

bool startSystemServer = (i < argc) ?

strcmp(argv[i], "--start-system-server") == 0 : false;

setArgv0(argv0, "zygote");

set_process_name("zygote");

runtime.start("com.android.internal.os.ZygoteInit",

startSystemServer);

} else {

set_process_name(argv0);

runtime.mClassName = arg;

// Remainder of args get passed to startup class main()

runtime.mArgC = argc-i;

runtime.mArgV = argv+i;

LOGV("App process is starting with pid=%d, class=%s.\n",

getpid(), runtime.getClassName());

runtime.start();

}

首先创建AppRuntime，即AndroidRuntime，建立了一个Dalvik虚拟机。通过这个runtime传递com.android.internal.os.ZygoteInit参数，从而由Dalvik虚拟机运行ZygoteInit.java的main()，开始创建Zygote进程。在其main()中，如下所示：

int binder_become_context_manager(struct binder_state *bs)

{

return ioctl(bs->fd, BINDER_SET_CONTEXT_MGR, 0);

}

if (0 == strcmp("--zygote", arg)) {

bool startSystemServer = (i < argc) ?

strcmp(argv[i], "--start-system-server") == 0 : false;

setArgv0(argv0, "zygote");

set_process_name("zygote");

runtime.start("com.android.internal.os.ZygoteInit",

startSystemServer);

} else {

set_process_name(argv0);

runtime.mClassName = arg;

// Remainder of args get passed to startup class main()

runtime.mArgC = argc-i;

runtime.mArgV = argv+i;

LOGV("App process is starting with pid=%d, class=%s.\n",

getpid(), runtime.getClassName());

runtime.start();

}

registerZygoteSocket();

EventLog.writeEvent(LOG_BOOT_PROGRESS_PRELOAD_START,

SystemClock.uptimeMillis());

preloadClasses();

//cacheRegisterMaps();

preloadResources();

EventLog.writeEvent(LOG_BOOT_PROGRESS_PRELOAD_END,

SystemClock.uptimeMillis());

// Finish profiling the zygote initialization.

SamplingProfilerIntegration.writeZygoteSnapshot();

// Do an initial gc to clean up after startup

gc();

// If requested, start system server directly from Zygote

if (argv.length != 2) {

throw new RuntimeException(argv[0] + USAGE_STRING);

}

if (argv[1].equals("true")) {

startSystemServer();

} else if (!argv[1].equals("false")) {

throw new RuntimeException(argv[0] + USAGE_STRING);

}

首先通过registerZygoteSocket()登记端口，接着preloadClasses()装载相关类。这里大概要装载1000多个类，具体装载类见platform\frameworks\base\preloaded-classes。这个文件有WritePreloadedClassFile类自动生成。分析该类的main函数，有如下一段筛选类的代码：

// Preload classes that were loaded by at least 2 processes. Hopefully,

// the memory associated with these classes will be shared.

for (LoadedClass loadedClass : root.loadedClasses.values()) {

Set names = loadedClass.processNames();

if (!Policy.isPreloadable(loadedClass)) {

continue;

}

if (names.size() >= MIN_PROCESSES ||

(loadedClass.medianTimeMicros() > MIN_LOAD_TIME_MICROS && names.size() > 1)) {

toPreload.add(loadedClass);

}

}

int initialSize = toPreload.size();

System.out.println(initialSize

+ " classses were loaded by more than one app.");

// Preload eligable classes from applications (not long-running

// services).

for (Proc proc : root.processes.values()) {

if (proc.fromZygote() && !Policy.isService(proc.name)) {

for (Operation operation : proc.operations) {

LoadedClass loadedClass = operation.loadedClass;

if (shouldPreload(loadedClass)) {

toPreload.add(loadedClass);

}

}

}

}

其中MIN_LOAD_TIME_MICROS等于1250，当类的装载时间大于1.25ms，则需要预装载。

Policy.isPreloadable()定义如下：

/**Reports if the given class should be preloaded. */

public static boolean isPreloadable(LoadedClass clazz) {

return clazz.systemClass && !EXCLUDED_CLASSES.contains(clazz.name);

}

其中EXCLUDED_CLASSES如下定义：

/**Reports if the given class should be preloaded. */

public static boolean isPreloadable(LoadedClass clazz) {

return clazz.systemClass && !EXCLUDED_CLASSES.contains(clazz.name);

}

/**

* Classes which we shouldn't load from the Zygote.

*/

private static final Set EXCLUDED_CLASSES

= new HashSet(Arrays.asList(

// Binders

"android.app.AlarmManager",

"android.app.SearchManager",

"android.os.FileObserver",

"com.android.server.PackageManagerService$AppDirObserver",

// Threads

"android.os.AsyncTask",

"android.pim.ContactsAsyncHelper",

"java.lang.ProcessManager"

));

这几个Binders和Thread是不会被预加载的。

另外还有一些application需要装载，要求满足条件proc.fromZygote()且不是属于常驻内存的服务。SERVICES定义如下：

/**

* Long running services. These are restricted in their contribution to the

* preloader because their launch time is less critical.

*/

// TODO: Generate this automatically from package manager.

private static final Set SERVICES = new HashSet(Arrays.asList(

"system_server",

"com.google.process.content",

"android.process.media",

"com.android.bluetooth",

"com.android.calendar",

"com.android.inputmethod.latin",

"com.android.phone",

"com.google.android.apps.maps.FriendService", // pre froyo

"com.google.android.apps.maps:FriendService", // froyo

"com.google.android.apps.maps.LocationFriendService",

"com.google.android.deskclock",

"com.google.process.gapps",

"android.tts"

));

preloaded-classes是在下载源码的时候生成，WritePreloadedClassFile类并没有被用到，但可以通过这个类了解Android系统对预加载类的默认要求，参考修改preloaded-classes文件，减少开机初始化时要预加载的类，提高开机速度。

最后来通过startSystemServer()启动SystemServer进程。见如下代码：

/* Hardcoded command line to start the system server */

String args[] = {

"--setuid=1000",

"--setgid=1000",

"--setgroups=1001,1002,1003,1004,1005,1006,1007,1008,1009,1010,1018,3001,3002,3003",

"--capabilities=130104352,130104352",

"--runtime-init",

"--nice-name=system_server",

"com.android.server.SystemServer",

};

ZygoteConnection.Arguments parsedArgs = null;

int pid;

try {

parsedArgs = new ZygoteConnection.Arguments(args);

/*

* Enable debugging of the system process if *either* the command line flags

* indicate it should be debuggable or the ro.debuggable system property

* is set to "1"

*/

int debugFlags = parsedArgs.debugFlags;

if ("1".equals(SystemProperties.get("ro.debuggable")))

debugFlags |= Zygote.DEBUG_ENABLE_DEBUGGER;

/* Request to fork the system server process */

pid = Zygote.forkSystemServer(

parsedArgs.uid, parsedArgs.gid,

parsedArgs.gids, debugFlags, null,

parsedArgs.permittedCapabilities,

parsedArgs.effectiveCapabilities)

Zygote包装了Linux的fork。forkSystemServer()调用forkAndSpecialize()，最终穿过虚拟机调用platform\dalvik\vm\native\dalvik_system_Zygote.c中Dalvik_dalvik_system_Zygote_forkAndSpecialize()。由dalvik完成fork新的进程。

main()最后会调用runSelectLoopMode()，进入while循环，由peers创建新的进程。

<3> SystemService进程

SystemService用于创建init.rc定义的服务之外的所有服务。在main()的最后有如下代码：

// The system server has to run all of the time, so it needs to be

// as efficient as possible with its memory usage.

VMRuntime.getRuntime().setTargetHeapUtilization(0.8f);

System.loadLibrary("android_servers");

init1(args);

Init1()是在native空间实现的，用于启动native空间的服务，其实现在com_android_server_SystemServer.cpp中的android_server_SystemServer_init1()：

static void android_server_SystemServer_init1(JNIEnv* env, jobject clazz)

{

system_init();

}

而system_init()服务初始化创建native层的各个服务：

// Start the sensor service

SensorService::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();

}

最后通过如下代码:

LOGI("System server: starting Android services.\n");

runtime->callStatic("com/android/server/SystemServer", "init2");

回到SystemServer.java，调用init2()：

public static final void init2() {

Slog.i(TAG, "Entered the Android system server!");

Thread thr = new ServerThread();

thr.setName("android.server.ServerThread");

thr.start();

}

Init2启动一个线程，专门用来启动java空间的所有服务。如下代码所示启动部分服务：

Slog.i(TAG, "Content Manager");

ContentService.main(context,

factoryTest == SystemServer.FACTORY_TEST_LOW_LEVEL);

Slog.i(TAG, "System Content Providers");

ActivityManagerService.installSystemProviders();

Slog.i(TAG, "Battery Service");

battery = new BatteryService(context);

ServiceManager.addService("battery", battery);

Slog.i(TAG, "Lights Service");

lights = new LightsService(context);

Slog.i(TAG, "Vibrator Service");

ServiceManager.addService("vibrator", new VibratorService(context));

// only initialize the power service after we have started the

// lights service, content providers and the battery service.

power.init(context, lights, ActivityManagerService.getDefault(), battery);

Slog.i(TAG, "Alarm Manager");

AlarmManagerService alarm = new AlarmManagerService(context);

ServiceManager.addService(Context.ALARM_SERVICE, alarm);

并且把这些服务添加到ServiceManager中，以便管理和进程间通讯。 在该线程后半部分，ActivityManagerService会等待AppWidget、WallPaper、IMM等systemReady后调用自身的systemReady()。

((ActivityManagerService)ServiceManager.getService("activity"))

.setWindowManager(wm);

// Skip Bluetooth if we have an emulator kernel

// TODO: Use a more reliable check to see if this product should

// support Bluetooth - see bug 988521

if (SystemProperties.get("ro.kernel.qemu").equals("1")) {

Slog.i(TAG, "Registering null Bluetooth Service (emulator)");

ServiceManager.addService(BluetoothAdapter.BLUETOOTH_SERVICE, null);

} else if (factoryTest == SystemServer.FACTORY_TEST_LOW_LEVEL) {

Slog.i(TAG, "Registering null Bluetooth Service (factory test)");

ServiceManager.addService(BluetoothAdapter.BLUETOOTH_SERVICE, null);

} else {

Slog.i(TAG, "Bluetooth Service");

bluetooth = new BluetoothService(context);

ServiceManager.addService(BluetoothAdapter.BLUETOOTH_SERVICE, bluetooth);

bluetooth.initAfterRegistration();

bluetoothA2dp = new BluetoothA2dpService(context, bluetooth);

ServiceManager.addService(BluetoothA2dpService.BLUETOOTH_A2DP_SERVICE,

bluetoothA2dp);

int bluetoothOn = Settings.Secure.getInt(mContentResolver,

Settings.Secure.BLUETOOTH_ON, 0);

if (bluetoothOn > 0) {

bluetooth.enable();

}

}

而在ActivityManagerService的systemReady()最后会执行如下代码：

mMainStack.resumeTopActivityLocked(null);

由于Activity管理栈为空，因此启动Launcher。

// Find the first activity that is not finishing.

ActivityRecord next = topRunningActivityLocked(null);

// Remember how we'll process this pause/resume situation, and ensure

// that the state is reset however we wind up proceeding.

final boolean userLeaving = mUserLeaving;

mUserLeaving = false;

if (next == null) {

// There are no more activities! Let's just start up the

// Launcher...

if (mMainStack) {

return mService.startHomeActivityLocked();

}

}

在startHomeActivityLocked()中创建一个带Category为CATEGORY_HOME的Intent，由此去启动相应Activity，即Launcher。

Intent intent = new Intent(

mTopAction,

mTopData != null ? Uri.parse(mTopData) : null);

intent.setComponent(mTopComponent);

if (mFactoryTest != SystemServer.FACTORY_TEST_LOW_LEVEL) {

intent.addCategory(Intent.CATEGORY_HOME);

}

这样，Android系统便启动起来进入到待机界面。

4.与启动相关的编译生成文件

编译完成后，在out目录下的项目文件夹下，将生成如下图所示文件： 图3 Android系统编译out目录结构图

我们用flashtool或者telweb工具进行刷机的时候，都是将其中的img文件烧入手机。

通过上图，整理出img后缀的文件和作用（可能有描述玩准确的地方，望交流指正）如下：

boot.img 开机引导的映像 cache.img 缓存映像 custpack.img 定制的内容映像 mobile_info.img 移动设备相关信息映像 ramdisk.img内存盘的根文件系统映像 ramdisk-recovery.img 内存盘根文件系统备份映像 recovery.img 系统备份映像 secro.img 签名映像 system.img 系统文件映像 userdata.img 用户数据映像

其中，boot.img和开机引导有关，我们启动的时候一定会用到。而我们之前讲述非常多的init.rc文件，则在ramdisk.img中。

这部分不去太深入了，个人觉得要深入就需要对Android编译原理进行更多地研究了。大家有兴趣和时间精力的可以去研究一下，应该不难理解，但是需要一个熟悉和知晓的过程。

参考文献：

1.《MTK手机开机过程》http://blog.csdn.net/archerm/article/details/5783528 2.《Qualcomm手机开机全过程大揭密》http://blog.csdn.net/duanlove/article/details/17332641 3.《Android开机启动流程初探》http://blog.csdn.net/xqz123456/article/details/39100719

eyelike@2014-11-05