[原]Android核心分析之AMS
2015-2-27阅读661 评论0
ActivityManagerService 简称AMS，是Android内核的核心功能之一，在系统启动SystemServer 时启动此服务。
android 框架：
Activity Manager的组成主要分为以下几个部分：
1.服务代理：由ActivityManagerProxy实现，用于与Server端提供的系统服务进行进程间通信
2.服务中枢：ActivityManagerNative继承自Binder并实现IActivityManager，它提供了服务接口和Binder接口的相互转化功能，并在内部存储服务代理对像，并提供了getDefault方法返回服务代理
3.Client：由ActivityManager封装一部分服务接口供Client调用。ActivityManager内部通过调用ActivityManagerNative的getDefault方法，可以得到一个ActivityManagerProxy对像的引用，进而通过该代理对像调用远程服务的方法
4.Server:由ActivityManagerService实现，提供Server端的系统服务
框架图：
AMS提供的功能主要包括以下几个方面：
１。对于Android四大组件（activity service broadcast content provider）的管理，包括启动，生命周期管理等
2.进程OOM adj以级LRU weight管理
AMS主要代码位于：
frameworks\base\core\java\android\app
frameworks\base\services\java\com\android\server\am
主要目录结构如下：
AMS服务启动是系统启动的init2阶段，由SystemServer启动的Java系统服务之一，启动代码位于\frameworks\base\services\java\com\android\server\SystemServer.java中
AMS服务在系统启动阶段的主要工作：
1.调用main方法启动AMS服务 context = ActivityManagerService.main(factoryTest);
2.调用SetSystemProcess方法ActivityManagerService。setSystemProcess();
3.调用installSystemProviders方法ActivityManagerService.installSystemProviders();
4.调用SystemReady方法 ActivityManagerService.self().systemReady
main方法介绍：
启动AThread线程，创建ActivityManagerService
创建完毕后，调用ActivityThread的systemMain方法创建ActivityThread对像
调用ActivityThread对像的getSystemContext方法创建Context对像，初始化ActivityStack 调用AMS的startRunning方法
public static final Context main(int factoryTest) {
AThread thr = new AThread();
thr.start();
synchronized (thr) {
while (thr.mService == null) {
try {
thr.wait();
} catch (InterruptedException e) {
}
}
}
ActivityManagerService m = thr.mService;
mSelf = m;
ActivityThread at = ActivityThread.systemMain();
mSystemThread = at;
Context context = at.getSystemContext();
context.setTheme(android.R.style.Theme_Holo);
m.mContext = context;
m.mFactoryTest = factoryTest;
m.mIntentFirewall = new IntentFirewall(m.new IntentFirewallInterface());
// CHANGED BY MARS BEGIN
m.mStackSupervisor = new com.marvell.security.MrvlActivityStackSupervisor(m, context, thr.mLooper);
// CHANGEd BY MARS END
m.mBatteryStatsService.publish(context);
m.mUsageStatsService.publish(context);
m.mAppOpsService.publish(context);
synchronized (thr) {
thr.mReady = true;
thr.notifyAll();
}
m.startRunning(null, null, null, null);
return context;
}
setSystemProcess介绍
?注册服务。首先将ActivityManagerService注册到ServiceManager中，其次将几个与系统性能调试相关的服务注册到ServiceManager。
?查询并处理ApplicationInfo。首先调用PackageManagerService的接口，查询包名为android 的应用程序的ApplicationInfo信息，对应于framework-res.apk。然后以该信息为参数调用ActivityThread上的installSystemApplicationInfo方法。
?创建并处理ProcessRecord。调用ActivityManagerService上的newProcessRecordLocked，创建一个ProcessRecord类型的对象，并保存该对象的信息。
public static void setSystemProcess() {
try {
ActivityManagerService m = mSelf;
ServiceManager.addService(Context.ACTIVITY_SERVICE, m, true);
ServiceManager.addService(ProcessStats.SERVICE_NAME, m.mProcessStats);
ServiceManager.addService("meminfo", new MemBinder(m));
ServiceManager.addService("gfxinfo", new GraphicsBinder(m));
ServiceManager.addService("dbinfo", new DbBinder(m));
if (MONITOR_CPU_USAGE) {
ServiceManager.addService("cpuinfo", new CpuBinder(m));
}
ServiceManager.addService("permission", new PermissionController(m));
ApplicationInfo info =
mSelf.mContext.getPackageManager().getApplicationInfo(
"android", STOCK_PM_FLAGS);
mSystemThread.installSystemApplicationInfo(info);
synchronized (mSelf) {
ProcessRecord app = mSelf.newProcessRecordLocked(info,
info.processName, false);
app.persistent = true;
app.pid = MY_PID;
app.maxAdj = ProcessList.SYSTEM_ADJ;
app.makeActive(mSystemThread.getApplicationThread(),
mSelf.mProcessStats);
mSelf.mProcessNames.put(app.processName, app.uid, app);
synchronized (mSelf.mPidsSelfLocked) {
mSelf.mPidsSelfLocked.put(app.pid, app);
}
mSelf.updateLruProcessLocked(app, false, null);
mSelf.updateOomAdjLocked();
}
} catch (https://www.doczj.com/doc/0318704978.html,NotFoundException e) {
throw new RuntimeException(
"Unable to find android system package", e);
}
}
installSystemProviders介绍
?调用generateApplicationProvidersLocked查询Content Provider
?调用ActivityThread.installSystemProviders安装Content Provider
generateApplicationProvidersLocked首先从PackageManagerService中查询运行在system 进程中且UID为SYSTEM_UID的Content Provider的信息，只有SettingsProvider满足此种条
件，第二步installSystemProviders就是安装上述查询出来的SettingsProvider
public static final void installSystemProviders() {
List
synchronized (mSelf) {
ProcessRecord app = mSelf.mProcessNames.get("system", Process.SYSTEM_UID);
providers = mSelf.generateApplicationProvidersLocked(app);
if (providers != null) {
for (int i=providers.size()-1; i>=0; i--) {
ProviderInfo pi = (ProviderInfo)providers.get(i);
if ((pi.applicationInfo.flags&ApplicationInfo.FLAG_SYSTEM) == 0) {
Slog.w(TAG, "Not installing system proc provider " + https://www.doczj.com/doc/0318704978.html,
+ ": not system .apk");
providers.remove(i);
}
}
}
}
if (providers != null) {
mSystemThread.installSystemProviders(providers);
}
mSelf.mCoreSettingsObserver = new CoreSettingsObserver(mSelf);
mSelf.mUsageStatsService.monitorPackages();
}
SystemReady介绍
?发送处理ACTION_PRE_BOOT_COMPLETED广播
?清理提前启动的非persistent进程
?读取Settings配置
?调用goingCallback的run函数启动SystemUI，执行其他系统服务的systemReady方法，启动软件Watchdog。
?启动persistent应用和Home应用，发送ACTION_BOOT_COMPLETED广播。
启动Activity的方法主要有以下的几种:
1.startActvity
2. startActivityForResult
这些方法都是通过Binder机制的Client端，调用Server端的ActivityManagerService的startActivity系列方法，最终启动指定的activity
Activity启动流程图：
Activity启动模式有四种：
?standard
?singleTop
?singleTask
?singleInstance
为什么需要广播
广播是操作系统framework层对观察者模式(observer)最常用的实现方式
一个软件系统常常要求在某一个对象的状态发生变化的时候，某些其它的对象做出相应的
改变。做到这一点的设计方案有很多，但是为了使系统能够易于复用，应该选择低耦合度的设计方案。减少对象之间的耦合有利于系统的复用，但是同时设计师需要使这些低耦合度的对象之间能够维持行动的协调一致，保证高度的协作。观察者模式是满足这一要求的各种设计方案中最重要的一种。
广播发送的api有：
?sendBroadcast
?sendOrderBroadcast
?sendStickyBroadcast
?
监听广播的方式有：
?动态注册使用registerReceiver方式
?静态注册在AndroidManifest.xml中定义BroadcastReceiver类并实现
广播有哪几种
广播有无序广播、有序广播和粘性广播，其中粘性广播需要有BROADCAST_STICKY权限
Service是什么
Service是Android系统的组件之一，和Activity，Broadcast，Conent Provider并称Android 四大组件，Service是不可见的，是没有界面的，是在后台运行的，Service一般处理比较耗时以及长时间运行的操作
Service的启动有两种方式：
1. startService主要用于启动一个服务执行后台任务，不进行通信，停止服务使用stopService
2. bindService该方法启动的服务可以获得该service的状态，停止服务使用unbindService
Service的重启机制：
onStartCommand(Intent,int,int)方法,这个方法return一个int值,return 的值有四种:
START_STICKY：如果service进程被kill掉，保留service的状态为开始状态，但不保留递送的intent对象。随后系统会尝试重新创建service，由于服务状态为开始状态，所以创建服务后一定会调用onStartCommand(Intent,int,int)方法。如果在此期间没有任何启动命令被传递到service，那么参数Intent将为null。
START_NOT_STICKY：“非粘性的”。使用这个返回值时，如果在执行完onStartCommand后，服务被异常kill掉，系统不会自动重启该服务。
START_REDELIVER_INTENT：重传Intent。使用这个返回值时，如果在执行完onStartCommand 后，服务被异常kill掉，系统会自动重启该服务，并将Intent的值传入。
START_STICKY_COMPATIBILITY：START_STICKY的兼容版本，但不保证服务被kill后一定能重启。Android的四种数据存储方式
?SharedPreference
一个xml文件，常用于存储较简单的参数设置
?SQLite
SQLite是一个轻量级的数据库，支持基本SQL语法，是常被采用的一种数据存储方式?File
文件（I/O）存储方法，常用于存储大数量的数据
?Content Provider
Android系统中能实现所有应用程序共享的一种数据存储方式
Content Provider的设计思路
?安全性考虑
?独立性考虑
?封装性考虑
?跨进程考虑
Content Provider的发布是在应用进程启动时发布的，具体代码可见ActivityThread.java AMS负责记录provider的调度端信息，并对其进行管理
Android为了提升当用户再次进入应用时的速度，采取了进程活动停止后不结束该进程的策略，将这些进程都保留在内存中，直到系统需要更多的内存为止。AMS为内存管理提供了OOM adj机制。
OOM adj(Out Of Memory adjustment)是内存不足状态的调整级别，系统根据进程运行时占有内存和CPU等情况为每个进程计算一个adj值，该值的取值范围为-17到+15，adj值越大的进程越容易被杀死，可以通过
cat /proc/
命令查看指定进程的OOM adj值，为方便管理，android在框架层定义了13个级别
后台隐藏的应用进程，运行于该进程的Activity是不可见的，杀死该进程不会对用户体验有较大的影响，其adj取值为9～15
static intHIDDEN_APP_MAX_ADJ = 15;
static intHIDDEN_APP_MIN_ADJ = 9;
前一个应用程序所在进程adj
static intPREVIOUS_APP_ADJ = 7;
运行Home的应用程序进程
static intHOME_APP_ADJ = 6;
不可见，但运行了用户可以感知的组件的应用程序进程，例如说在后台运行的音乐播放器 static intPERCEPTIBLE_APP_ADJ = 2;
运行了可见Activity，但是并不在前台显示的应用程序进程
static intVISIBLE_APP_ADJ = 1;
当前前台正在运行的应用程序所在的进程
static intFOREGROUND_APP_ADJ = 0;
系统persistent进程，例如说phone、incallui等
static final intPERSISTENT_PROC_ADJ = -12;
system进程
static final intSYSTEM_ADJ = -16;
Android借鉴了Linux进程管理机制，提供了自己的实现Low Memory Killer。LMK其源码在kernel/drivers/staging/android/lowmemorykiller.c
文件中，其中OOM adj等级由/sys/module/lowmemorykiller/parameters/adj指定，
最小内存阈值由/sys/module/lowmemorykiller/parameters/minfree指定
上述两个取值可以通过下列两个命令获取
cat /sys/module/lowmemorykiller/parameters/adj
cat /sys/module/lowmemorykiller/parameters/minfree
LMK机制其选择进程杀死的原则是：
?OOM adj越大的进程越容易被杀死
?相同adj的进程，占用内存越大的越容易被杀死
?未达到最小内存阈值的最大值时，不会选择进程杀死
LRU(Least Recently Used)是最近最少使用的意思，LRU weight用于衡量最近最少使用的权重，是Anroid进程管理的核心概念之一。
Android应用进程启动后都会在AMS的成员变量中保存ProcessRecord信息，用于调度应用程序组件。此外，mLruProcess以LRU顺序存储了当前运行的应用程序进程信息，其第一个元素便是最近最少使用的进程对应的ProcessRecord，用于管理应用程序进程。
以下三种情况发生时可以更新mLruProcess：
?应用程序异常退出：调用handleAppDiedLocked更新mLruProcesses
?显式“杀死”指定进程：调用ActivityManagerService显式“杀死”进程时更新
?启动和调度应用程序四大组件：调用updateLruProcessLocked更新
应用可以通过以下api获取进程信息：
?getRunningTasks获取系统正在运行的任务
?getRunningAppProcesses获取系统里正在运行的进程
?killBac kgroundProcesses(String packageName)立即杀掉给定包名的进程，释放进程占用的资源(内存等)
?getMemoryInfo (MemoryInfooutInfo) 获取系统可用内存信息，数据封装在outInfo对象上?getProcessMemoryInfo(int[] pids) 获取每个进程ID(集合)占用的内存大小(集合), pid和MemoryInfo是一一对应的
getRunningServices获取系统正在运行的服务的信息
一，系统引导bootloader 加电，cpu执行bootloader程序，正常启动系统，加载boot.img【其中包含内核。还有ramdisk】 二，内核kernel bootloader加载kernel，kernel自解压，初始化，载入built-in驱动程序，完成启动。 内核启动后会创建若干内核线程，在后装入并执行程序/sbin/init/,载入init process，切换至用户空间（user-space） 内核zImage解压缩 head.S【这是ARM-Linux运行的第一个文件，这些代码是一个比较独立的代码包裹器。其作用就是解压Linux内核，并将PC指针跳到内核（vmlinux）的第一条指令】首先初始化自解压相关环境（内存等），调用decompress_kernel进行解压，解压后调用start_kernel启动内核【start_kernel是任何版本linux内核的通用初始化函数，它会初始化很多东西，输出linux版本信息，设置体系结构相关的环境，页表结构初始化，设置系 统自陷入口，初始化系统IRQ，初始化核心调度器等等】，最后调用rest_init【rest_init 会调用kernel_init启动init进程（缺省是/init）。然后执行schedule开始任务调度。这个init是由android的./system/core/init下的代码编译出来的，由此进入了android的代码】。 三，Init进程启动 【init是kernel启动的第一个进程，init启动以后，整个android系统就起来了】 init进程启动后，根据init.rc 和init.
Androiｄ的开机流程 1. 系统引导ｂｏotloader 1) 源码：bootable／bootｌｏａdｅr/* 2) 说明：加电后,CPＵ将先执行bootｌoadｅｒ程序,此处有三种选择 ａ) 开机按Camｅra+Power启动到fａsｔｂｏot,即命令或SD卡烧写模式，不加载内核及文件系统，此处可以进行工厂模式的烧写 b) 开机按Home＋Power启动到reｃｏｖery模式，加载rｅcovｅrｙ.ｉｍg，reｃｏvery.i ｍg包含内核，基本的文件系统，用于工程模式的烧写 ｃ) 开机按Power,正常启动系统,加载booｔ.iｍg，ｂooｔ.ｉｍg包含内核，基本文件系统，用于正常启动手机(以下只分析正常启动的情况) 2. 内核keｒnel 1) 源码：ｋerｎel／* 2) 说明:keｒnel由ｂooｔloａder加载 3. 文件系统及应用inｉｔ 1) 源码：syｓtem／ｃoｒe/ｉnit/＊ 2) 配置文件：ｓｙstem/ｒoｏtdir/ｉnit.rｃ, 3) 说明：iｎｉｔ是一个由内核启动的用户级进程,它按照init．ｒｃ中的设置执行:启动服务(这里的服务指ｌｉnｕx底层服务，如adbd提供aｄb支持，vｏlｄ提供SD卡挂载等)，执行命令和按其中的配置语句执行相应功能 4. 重要的后台程序zygote 1）源码：frameworks/ｂaｓｅ/cｍdｓ/ａｐp_main.ｃｐp等 2) 说明：ｚyｇｏｔe是一个在ｉnｉt.ｒc中被指定启动的服务,该服务对应的命令是/ｓystｅm/bin/app_ｐrocess a）建立Java Runtimｅ,建立虚拟机 b) 建立Sｏcket接收ActivitｙMaｎａngerService的请求,用于Fork应用程序 c) 启动System Ｓerｖｅr ５. 系统服务system sｅrｖer 1）源码：ｆrameｗorkｓ/baｓe/seｒvices/jaｖa/com/andrｏid/seｒｖer/SystemSｅrver.jav ａ 2) 说明：被zｙgoｔe启动,通过SｙsｔｅｍMａｎager管理androiｄ的服务（这里的服务指ｆramｅwoｒkｓ/base/servｉces下的服务,如卫星定位服务,剪切板服务等) 6. 桌面launcheｒ 1）源码：AcｔivityＭanaｇeｒService.java为入口，packaｇｅs/apps/launcher*实现 2) 说明：系统启动成功后ＳystｅmＳervｅr使用xxx．systeｍＲeady()通知各个服务,系统已经就绪，桌面程序Home就是在ActiｖityＭanａgerService．systｅmRｅady()通知的过程中建立的,最终调用（)启launcｈeｒ 7. 解锁 1) 源码: ｆraｍeworkｓ/poｌicies/ｂase/pｈonｅ/coｍ/andrｏiｄ/ｉｎteｒnal/ｐolｉcy/ｉmpl/＊loｃk* 2) 说明：系统启动成功后SystemSｅrｖer调用ｗｍ.sｙｓteｍRｅady()通知ＷindｏwＭａnageｒService,进而调用PhonｅＷｉｎdowManａger，最终通过LockＰaｔternKeｙgｕaｒｄＶiew显示解锁界面，跟踪代码可以看到解锁界面并不是一个Ａctivity,这是只是向特定层上绘图,其代码了存放在特殊的位置
开机启动花了40多秒，正常开机只需要28秒就能开机起来。 内核的启动我没有去分析，另一个同事分析的。我主要是分析从SystemServer启来到开机动画结束显示解锁界面的这段时间，也就是开机动画的第三个动画开始到结束这段时间，这是个比较耗时阶段，一般都在17秒左右(见过牛B的手机，只需5秒)。 SystemServer分两步执行：init1和init2。init1主要是初始化native的服务，代码在sy stem_init.cpp的system_init，初始化了SurfaceFlinger和SensorService这两个native的服务。init2启动的是java的服务，比如ActivityManagerService、WindowManagerService、PackageManagerService等，在这个过程中PackageManagerService用的时间最长，因为PackageManagerService会去扫描特定目录下的jar包和apk文件。 在开机时间需要40多秒的时，从Log上可以看到，从SurfaceFlinger初始化到动画结束，要27秒左右的时间,即从SurfaceFlinger::init的LOGI("SurfaceFlinger is starting")这句Log到void SurfaceFlinger::bootFinished()的LOGI("Boot is finished (%ld ms)", long(ns 2ms(duration)) )，需要27秒左右的时间，这显然是太长了，但到底是慢在哪了呢？应该在个中间的点，二分一下，于是想到了以启动服务前后作为分隔：是服务启动慢了，还是在服务启动后的这段时间慢？以ActivityManagerService的Slog.i(TAG, "System now ready")的这句Log为分割点，对比了一下，在从SurfaceFlinger is starting到System now read y多了7秒左右的时间，这说明SystemServer在init1和init2过程中启动慢了，通过排查，发现在init1启动的时候，花了7秒多的时间，也就是system_init的LOGI("Entered system _init()")到LOGI("System server: starting Android runtime.\n")这段时间用了7秒多，而正常情况是400毫秒便可以初始化完，通过添加Log看到，在SensorService启动时，用了比较长的时间。 不断的添加Log发现，在启动SensorService时候，关闭设备文件变慢了，每次关闭一个/dev/input/下的设备文件需要100ms左右，而SensorService有60~70次的关闭文件，大概有7s左右的时间。 调用流程是: frameworks/base/cmds/system_server/library/system_init.cpp: system_init->SensorServi ce::instantiate frameworks/native/services/sensorservice/SensorService.cpp: void SensorService::onFi rstRef()->SensorDevice& dev(SensorDevice::getInstance()) hardware/libsensors/SensorDevice.cpp: SensorDevice::SensorDevice()->sensors_open hardware/libsensors/sensors.cpp: open_sensors->sensors_poll_context_t sensors_poll_context_t执行打开每个传感器设备时，遍历/dev/input/目录下的设备文件，以匹配当前需要打开的设备，遍历文件是在 hardware/libsensors/SensorBase.cpp的openInput下实现，如果打开的设备文件不是正在打开的设备文件，会执行下面语句的else部分： if (!strcmp(name, inputName)) { strcpy(input_name, filename); break;
基于MT6752的Android系统启动流程分析报告 1、Bootloader引导 (2) 2、Linux内核启动 (23) 3、Android系统启动 (23) 报告人： 日期：2016.09.03
对于Android整个启动过程来说，基本可以划分成三个阶段：Bootloader引导、Linux kernel启动、Android启动。但根据芯片架构和平台的不同，在启动的Bootloader阶段会有所差异。 本文以MTK的MT6752平台为例，分析一下基于该平台的Android系统启动流程。 1、Bootloader引导 1.1、Bootloader基本介绍 BootLoader是在操作系统运行之前运行的一段程序，它可以将系统的软硬件环境带到一个合适状态，为运行操作系统做好准备，目的就是引导linux操作系统及Android框架(framework)。 它的主要功能包括设置处理器和内存的频率、调试信息端口、可引导的存储设备等等。在可执行环境创建好之后，接下来把software装载到内存并执行。除了装载software，一个外部工具也能和bootloader握手(handshake)，可指示设备进入不同的操作模式，比如USB下载模式和META模式。就算没有外部工具的握手，通过外部任何组合或是客户自定义按键，bootloader也能够进入这些模式。 由于不同处理器芯片厂商对arm core的封装差异比较大，所以不同的arm处理器，对于上电引导都是由特定处理器芯片厂商自己开发的程序，这个上电引导程序通常比较简单，会初始化硬件，提供下载模式等，然后才会加载通常的bootloader。 下面是几个arm平台的bootloader方案： marvell(pxa935) : bootROM + OBM + BLOB informax(im9815) : bootROM + barbox + U-boot mediatek(mt6517) : bootROM + pre-loader + U-boot broadcom(bcm2157) : bootROM + boot1/boot2 + U-boot 而对MT6752平台，MTK对bootloader引导方案又进行了调整，它将bootloader分为以下两个部分： (1) 第1部分bootloader，是MTK内部(in-house)的pre-loader，这部分依赖平台。 (2) 第2部分bootloader，是LK（little kernel的缩写，作用同常见的u-boot差不多），这部分依赖操作系统，负责引导linux操作系统和Android框架。 1.2、bootloader的工作流程 1.2.1 bootloader正常的启动流程 先来看启动流程图：
linux内核启动+Android系统启动过程详解 第一部分：汇编部分 Linux启动之 linux-rk3288-tchip/kernel/arch/arm/boot/compressed/ head.S分析这段代码是linux boot后执行的第一个程序，完成的主要工作是解压内核，然后跳转到相关执行地址。这部分代码在做驱动开发时不需要改动，但分析其执行流程对是理解android的第一步 开头有一段宏定义这是gnu arm汇编的宏定义。关于GUN 的汇编和其他编译器，在指令语法上有很大差别，具体可查询相关GUN汇编语法了解 另外此段代码必须不能包括重定位部分。因为这时一开始必须要立即运行的。所谓重定位，比如当编译时某个文件用到外部符号是用动态链接库的方式，那么该文件生成的目标文件将包含重定位信息，在加载时需要重定位该符号，否则执行时将因找不到地址而出错 #ifdef DEBUG//开始是调试用，主要是一些打印输出函数，不用关心 #if defined(CONFIG_DEBUG_ICEDCC)
……具体代码略 #endif 宏定义结束之后定义了一个段， .section ".start", #alloc, #execinstr 这个段的段名是 .start，#alloc表示Section contains allocated data, #execinstr表示Section contains executable instructions. 生成最终映像时，这段代码会放在最开头 .align start: .type start,#function /*.type指定start这个符号是函数类型*/ .rept 8 mov r0, r0 //将此命令重复8次，相当于nop，这里是为中断向量保存空间 .endr b 1f .word 0x016f2818 @ Magic numbers to help the loader
Android的开机流程 1. 系统引导bootloader 1) 源码: bootable/bootloader/* 2) 说明: 加电后, CPU将先执行bootloader程序, 此处有三种选择 a) 开机按Camera+Power启动到fastboot, 即命令或SD卡烧写模式, 不加载内核及文件系统, 此处能够进行工厂模式的烧写 b) 开机按Home+Power启动到recovery模式, 加载recovery.img, recovery.img包含内核, 基本的文件系统, 用于工程模式的烧写 c) 开机按Power, 正常启动系统, 加载boot.img, boot.img包含内核, 基本文件系统, 用于正常启动手机( 以下只分析正常启动的情况) 2. 内核kernel 1) 源码: kernel/* 2) 说明: kernel由bootloader加载 3. 文件系统及应用init 1) 源码: system/core/init/* 2) 配置文件: system/rootdir/init.rc, 3) 说明: init是一个由内核启动的用户级进程, 它按照init.rc中的设置执行: 启动服务( 这里的服务指linux底层服务, 如adbd提供adb支持, vold提供SD卡挂载等) , 执行命令和按其中的配置语句执行相应功能 4. 重要的后台程序zygote 1) 源码: frameworks/base/cmds/app_main.cpp等 2) 说明: zygote是一个在init.rc中被指定启动的服务, 该服务对应的命令是/system/bin/app_process
Android系统启动过程详解 Android系统启动过程 首先Android框架架构图：（来自网上，我觉得这张图看起来很清晰） Linux内核启动之后就到Android Init进程，进而启动Android相关的服务和应用。 启动的过程如下图所示：（图片来自网上，后面有地址）
下面将从Android4.0源码中，和网络达人对此的总结中，对此过程加以学习了解和总结， 以下学习过程中代码片段中均有省略不完整，请参照源码。
一Init进程的启动 init进程，它是一个由内核启动的用户级进程。内核自行启动（已经被载入内存，开始运行， 并已初始化所有的设备驱动程序和数据结构等）之后，就通过启动一个用户级程序init的方式，完成引导进程。init始终是第一个进程。 启动过程就是代码init.c中main函数执行过程：system\core\init\init. c 在函数中执行了：文件夹建立，挂载，rc文件解析，属性设置，启动服务，执行动作，socket监听…… 下面看两个重要的过程：rc文件解析和服务启动。 1 rc文件解析 .rc文件是Android使用的初始化脚本文件（System/Core/Init/readm e.txt中有描述： four broad classes of statements which are Actions, Commands, Services, and Options.） 其中Command 就是系统支持的一系列命令，如：export，hostname，mkdir，mount，等等，其中一部分是linux 命令， 还有一些是android 添加的，如：class_start
Android SystemBar启动流程分析 SystemBars的服务被start时，最终会调用该类的onNoService()方法。 @Override public void start() { if (DEBUG) Log.d(TAG, "start"); ServiceMonitor mServiceMonitor = new ServiceMonitor(TAG, DEBUG, mContext, Settings.Secure.BAR_SERVICE_COMPONENT, this); mServiceMonitor.start(); // will call onNoService if no remote service is found } @Override public void onNoService() { if (DEBUG) Log.d(TAG, "onNoService"); createStatusBarFromConfig(); // fallback to using an in-process implementation } private void createStatusBarFromConfig() { … mStatusBar = (BaseStatusBar) cls.newInstance(); … mStatusBar.start(); } BaseStatusBar是一个抽象类，故调用其子类的PhoneStatusBar的start 函数。 @Override public void start() { … super.start(); … } 子类的start又调用了父类的start public void start() { … createAndAddWindows(); … }
Android L系统启动及加载流程分析 1、概述 Android L的启动可以分为几个步骤：Linux内核启动、init进程启动、native系统服务及java系统服务启动、Home启动，主要过程如下图： 图1 整个启动流程跟4.4及之前的版本相差不多，只是有个别不同之处，本文我们主要分析Linux内核启动之后的过程。
2、启动过程分析 2.1 init进程启动 当系统内核加载完成之后，会启动init守护进程，它是内核启动的第一个用户级进程，是Android的一个进程，进程号为1，init进程启动后执行入口函数main()，主要操作为： 图2 AndroidL上将selinux的安全等级提高了，设为了enforcing模式，4.4上是permissive模式。 解析rc脚本文件，即init.rc脚本，该文件是Android初始化脚本，定义了一系列的动作和执行这些动作的时间阶段e aryl-init、init、early-boot、boot、post-fs等阶段。init进程main 函数中会根据这些阶段进行解析执行。AndroidL上为了流程更清晰，增加了charger（充电开机）、ffbm（工厂模式）、以及late-init阶段，实际上这些阶段是对其他阶段的组合执行，比如late-init：
2.2 ServiceManager的启动 servicemanager的启动就是init进程通过init.rc脚本启动的： 源码在frameworks/native/cmds/servicemanager/service_manager.c中，servicemanager是服务管理器，它本身也是一个服务(handle=0)，通过binder调用，为native和Java系统服务提供注册和查询服务的，即某个服务启动后，需要将自己注册到servicemanager中，供其他服务或者应用查询使用。AndroidL上servicemanger中在处理注册和查询动作之前添加了selinux安全检测相关的处理。 2.3 SurfaceFinger、MediaServer进程启动 Android4.4以前，surfacefinger的启动根据属性system_init.startsurfaceflinger，决定是通过init.rc启动还是systemserver进程启动，之后的版本包括AndoridL都是通过init.rc启动的： 启动后会向servicemanager进程注册服务中，该服务启动时主要功能是初始化整个显
android开机启动流程简单分析 android启动 当引导程序启动Linux内核后，会加载各种驱动和数据结构，当有了驱动以后，开始启动Android系统同时会加载用户级别的第一个进程init（system\core\init\init.cpp）代码如下： int main(int argc, char** argv) { ..... //创建文件夹，挂载 // Get the basic filesystem setup we need put together in the initramdisk // on / and then we'll let the rc file figure out the rest. if (is_first_stage) { mount("tmpfs", "/dev", "tmpfs", MS_NOSUID, "mode=0755"); mkdir("/dev/pts", 0755); mkdir("/dev/socket", 0755); mount("devpts", "/dev/pts", "devpts", 0, NULL); #define MAKE_STR(x) __STRING(x) mount("proc", "/proc", "proc", 0, "hidepid=2,gid=" MAKE_STR(AID_READPROC)); mount("sysfs", "/sys", "sysfs", 0, NULL); } ..... //打印日志，设置log的级别 klog_init(); klog_set_level(KLOG_NOTICE_LEVEL); ..... Parser& parser = Parser::GetInstance(); parser.AddSectionParser("service",std::make_unique
Android ninja编译启动过程分析 ---make是如何转换到到ninja编译的 １．首先你的得对make的工作机制有个大概的了解： 运行的命令在要编译的目录下运行make,或者make target_name a.分析处理保存阶段(没有实际编译动作):它首先对当前目录下的Makefile文件的做一次扫描，语法分析，还有处理，主要是变量的保存，目标依赖列表生成,目标下的action列表的生成，然后记住 b.然后按记住的目标执行action列表动作(有实际编译动作). 编译启动的入口方式还是运行make： ２开始make-jxxx方式进入.....(xxx是本机cpu的数量) make开始做进行第一次扫描.... 目前USE_NINJA还是没有定义，估计以后很久很久才能启用的了！ BUILDING_WITH_NINJA开始也是没定义的 看make扫描入口文件: Makefile: include build/core/main.mk 在build/core/main.mk: 在ninia之前都有include help.mk和config.mk 97include$(BUILD_SYSTEM)/help.mk 98 99#Set up various standard variables based on configuration 100#and host information. 101include$(BUILD_SYSTEM)/config.mk 说明make help//显示make帮助make config//当前显示配置 103relaunch_with_ninja:= 104ifneq($(USE_NINJA),false) 105ifndef BUILDING_WITH_NINJA<==第二次扫描不会到这里了 106relaunch_with_ninja:=true 107endif 108endif 116ifeq($(relaunch_with_ninja),true)<===第一次扫描入这里了 117#Mark this is a ninja build. 118$(shell mkdir-p$(OUT_DIR)&&touch$(OUT_DIR)/ninja_build) 119include build/core/ninja.mk//---进入ninja.mk 第一次扫描到此为止就结束掉了，因为在当前ifeq else endif后面没有代码了 120else#///!relaunch_with_ninja<===第二次扫描入这里了
一、Android开机启动流程简介 1、OS-level： 由bootloader载入linux kernel后kernel开始初始化, 并载入built-in 的驱动程序。Kernel完成开机后，载入init process，切换至user-space。 Init进程是第一个在user-space启动的进程。 2、Android-level： 由init process读取init.rc，Native 服务启动，并启动重要的外部程序，例如：servicemanager、Zygote以及System Server等。 由 init process 根据硬件类型读取init.xxx.rc。由init.xxx.rc加载init.xxx.sh。 由 init.xxx.sh 加载特定的硬件驱动。如hi_tuner.ko、hi_demux.ko等。 3、Zygote-Mode： Zygote 启动完SystemServer 后，进入Zygote Mode，在Socket 等候命令。 随后，使用者将看到一个桌面环境（Home Screen）。桌面环境由一个名为[Launcher]的应用程序负责提供。 本文档重点研究Android-level中的启动流程。 启动流程如下图所示：
二、init process流程分析 init进程简介 init进程是第一个在user-space启动的进程。由内核启动参数[init]传递给内核，如果该项没有设置，内核会按 /etc/init,/bin/init,/sbin/init,/bin/sh的顺序进行尝试,如果都有的都没找到，内核会抛出 kernel panic：的错误。
A n d r o i d系统启动升级 流程 TTA standardization office【TTA 5AB- TTAK 08- TTA 2C】
摘要 本文首先介绍了Android系统更新要用到的一些概念：硬件、三种模式及相互之间的通信。然后介绍了Android系统的启动和升级流程。 概述 通常，Android系统的升级包名称为update.zip。Android系统内部自带了烧写升级包的工具，我们可以手动烧写，也可以通过某些机制自动更新系统。同时，我们可以手动修改和制作升级包。本文主要阐述在Android系统升级中用到的一些概念，本文只是作为索引，并不涉及到具体的烧写工作。本文基于Android系统的版本：4.0.4。 硬件 Android系统的烧写，是非常贴近硬件的。一是，烧写是在实实在在的硬件上操作的。二则，有时在翻阅源码的时候，需要知道硬件的类型，以便找到和硬件相对应的源码。 烧写相关的硬件主要有三部分：CPU、内存和nand flash。当然，只是相对本文而言。CPU用来执行程序中的指令。内存只是在运行中，将需要运行的程序加载其中并运行，关机后即消失。nandflash用来存储程序的数据，它会一直存在。系统启动时，会将nand flash上的操作系统加载到内存，然后运行在CPU 中，对于非系统程序，按需加载到内存中运行。了解这些，有助于了解整个烧写的过程。 在板子上，可以通过下面的命令，查看CPU的信息： [plain] cat /proc/cpuinfo 通过如下命令查看内存的信息： [plain] cat /proc/meminfo nand flash是需要分区的，每个分区中对应了Android系统烧写包中不同的image，比如：boot、system分区等。可以通过如下命令来查看nand flash 的分区情况： [plain] cat /proc/mtd # 查看分区状况 通常，nand flash包含了以下分区： 开机动画：用于在开机或者升级过程中显示在屏幕上的内容。 boot：用于Android系统的正常启动 recovery：用于Android系统进入recovery模式下，参见本文后续介绍。 misc：用于保存BCB的内容，参见本文后续介绍。
上文介绍了Android应用程序的启动过程，即应用程序默认Activity的启动过程，一般来说，这种默认Activity是在新的进程和任务中启动的；本文将继续分析在应用程序内部启动非默认Activity的过程的源代码，这种非默认Activity一般是在原来的进程和任务中启动的。 这里，我们像上一篇文章Android应用程序启动过程源代码分析一样，采用再上一篇文章Android 应用程序的Activity启动过程简要介绍和学习计划所举的例子来分析在应用程序内部启动非默认Activity的过程。 在应用程序内部启动非默认Activity的过程与在应用程序启动器Launcher中启动另外一个应用程序的默认Activity的过程大体上一致的，因此，这里不会像上文Android应用程序启动过程源代码分析一样详细分析每一个步骤，我们着重关注有差别的地方。 回忆一下Android应用程序的Activity启动过程简要介绍和学习计划一文所用的应用程序Activity，它包含两个Activity，分别是MainActivity和SubActivity，前者是应用程序的默认Activity，后者是非默认Activity。MainActivity启动起来，通过点击它界面上的按钮，便可以在应用程序内部启动SubActivity。 我们先来看一下应用程序的配置文件AndroidManifest.xml，看看这两个Activity是如何配置的：view plain 1. 2.
Android系统的开机画面显示过程分析 分类：Android2012-07-0900:561252人阅读评论(39)收藏举报 好几个月都没有更新过博客了，从今天开始，老罗将尝试对Android系统的UI实现作一个系统的分析，也算是落实之前所作出的承诺。提到Android系统的UI，我们最先接触到的便是系统在启动过程中所出现的画面了。Android系统在启动的过程中，最多可以出现三个画面，每一个画面都用来描述一个不同的启动阶段。本文将详细分析这三个开机画面的显示过程，以便可以开启我们对Android系统UI实现的分析之路。 第一个开机画面是在内核启动的过程中出现的，它是一个静态的画面。第二个开机画面是在init进程启动的过程中出现的，它也是一个静态的画面。第三个开机画面是在系统服务启动的过程中出现的，它是一个动态的画面。无论是哪一个画面，它们都是在一个称为帧缓冲区（frame buffer，简称fb）的硬件设备上进行渲染的。接下来，我们就分别分析这三个画面是如何在fb上显示的。 1.第一个开机画面的显示过程 Android系统的第一个开机画面其实是Linux内核的启动画面。在默认情况下，这个画面是不会出现的，除非我们在编译内核的时候，启用以下两个编译选项： CONFIG_FRAMEBUFFER_CONSOLE CONFIG_LOGO 第一个编译选项表示内核支持帧缓冲区控制台，它对应的配置菜单项为：Device Drivers--->Graphics support--->Console display driver support--->Framebuffer Console support。第二个编译选项表示内核在启动的过程中，需要显示LOGO，它对应的配置菜单项为：Device Drivers--->Graphics support--->Bootup logo。配置Android 内核编译选项可以参考在Ubuntu上下载、编译和安装Android最新内核源代码（Linux Kernel）一文。 帧缓冲区硬件设备在内核中有一个对应的驱动程序模块fbmem，它实现在文件kernel/goldfish/drivers/video/fbmem.c中，它的初始化函数如下所示： 1/**
Android系统完整的启动过程，从系统层次角度可分为Linux系统层、Android系统服务层、Zygote进程模型三个阶段；从开机到启动Home Launcher完成具体的任务细节可分为七个步骤，下面就从具体的细节来解读Android系统完整的初始化过程。 一、启动BootLoader Android 系统是基于Linux操作系统的，所以它最初的启动过程和Linux一样。当设备通电后首先执行BootLoader引导装载器，BootLoader是在操作系统内核运行之前运行的一段小程序。通过这段小程序初始化硬件设备、建立内存空间映射图，从而将系统的软硬件环境引导进入合适的状态，以便为最终调用操作系统内核准备好正确的运行环境。 而Linux系统启动时： 1）首先要加载BIOS的硬件信息，并获取第一个启动设备的代号 2）读取第一个启动设备的MBR的引导加载程序（lilo、grub等）的启动信息。 3）加载核心操作系统的核心信息，核心开始解压缩，并且尝试驱动所有的硬件设备。 ………… 在嵌入式系统中，通常不会有像BIOS那样的固件程序，因此整个系统的加载任务都是通过BootLoader完成的。 二、加载系统内核 Linux内核映像通常包括两部分代码，分别为实模式代码和保护模式代码。当BootLoader装载内核映像到代码段内存时，分别放置实模式代码和保护模式代码到不同的位置，然后进入实模式代码执行，实模式代码执行完成后转入保护模式代码。 实模式和保护模式的概念再次不做过多解释，读者可以自行查阅资料。 三、启动Init进程 当系统内核加载完成之后，会首先启动Init守护进程，它是内核启动的第一个用户级进程，它的进程号总是1。Init进程启动完成之后，还负责启动其他的一些重要守护进程，包括： Usbd进程（USB Daemon）：USB连接后台进程，负责管理USB连接。 adbd 进程（Android Debug Bridge Daemon）：ADB连接后台进程，负责管理ADB连接。 debuggerd 进程(Debugger Daemon) ：调试器后台进程，负责管理调试请求及调试过程。 rild进程(Radio Interface Layer Daemon)：无线接口层后台进程，负责管理无线通信服务。 四、启动Zygote进程 Init进程和一些重要的守护进程启动完成之后，系统启动Zygote 进程。Zygote 进程启动后，首先初始化一个Dalvik VM实例，然后为它加载资源与系统共享库，并开启Socket监听服务，当收到创建Dalvik VM实例请求时，会通过COW（copy on write）技术最大程度地复用自己，生成一个新的Dalvik VM实例。Dalvik VM实例的创建方法基于linux系统的fork原理。
Android系统启动流程（一）解析init 进程 前言 作为“Android框架层”这个大系列中的第一个系列，我们首先要了解的是Android系统启动流程，在这个流程中会涉及到很多重要的知识点，这个系列我们就来一一讲解它们，这一篇我们就来学习init进程。 1.init简介 init进程是Android系统中用户空间的第一个进程，作为第一个进程，它被赋予了很多极其重要的工作职责，比如创建zygote(孵化器)和属性服务等。init进程是由多个源文件共同组成的，这些文件位于源码目录system/core/init。本文将基于Android7.0源码来分析Init进程。 2.引入init进程 说到init进程，首先要提到Android系统启动流程的前几步： 1.启动电源以及系统启动 当电源按下时引导芯片代码开始从预定义的地方（固化在ROM）开始执行。加载引导程序Bootloader到RAM，然后执行。 2.引导程序Bootloader 引导程序是在Android操作系统开始运行前的一个小程序，它的主要作用是把系统OS拉起来并运行。 3.Linux内核启动 内核启动时，设置缓存、被保护存储器、计划列表，加载驱动。当内核完成系统设置，它首先在系统文件中寻找”init”文件，然后启动root进程或者系统的第一个进程。 4.init进程启动 讲到第四步就发现我们这一节要讲的init进程了。关于Android系统启动流程的所有步骤会在本系列的最后一篇做讲解。 3.init入口函数 init的入口函数为main，代码如下所示。 system/core/init/init.cpp int main(int argc, char** argv) { if (!strcmp(basename(argv[0]), "ueventd")) { return ueventd_main(argc, argv); } if (!strcmp(basename(argv[0]), "watchdogd")) { return watchdogd_main(argc, argv);