Android 开机启动流程
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
a) 建立Java Runtime，建立虚拟机
b) 建立Socket接收ActivityManangerService的请求，用于Fork应用程序
c) 启动System Server
5. 系统服务system server
1) 源码：frameworks/base/services/java/com/android/server/SystemServer.java
2) 说明：被zygote启动，通过System Manager管理android的服务（这里的服务指frameworks/base/services下的服务，如卫星定位服务，剪切板服务等）
6. 桌面launcher
1) 源码：ActivityManagerService.java为入口，packages/apps/launcher*实现
2) 说明：系统启动成功后SystemServer使用xxx.systemReady()通知各个服务，系统已经就绪，桌面程序Home就是在ActivityManagerService.systemReady()通知的过程中建立的，最终调用()启launcher
7. 解锁
1) 源码：
frameworks/policies/base/phone/com/android/internal/policy/impl/*lock*
2) 说明：系统启动成功后SystemServer调用wm.systemReady()通知WindowManagerService，进而调用PhoneWindowManager，最终通过LockPatternKeyguardView显示解锁界面，跟踪代码可以看到解锁界面并不是一个Activity，这是只是向特定层上绘图，其代码了存放在特殊的位置
8. 开机自启动的第三方应用程序
1) 源码：
frameworks/base/services/java/com/android/server/am/ActivityManagerService.java
2) 说明：系统启动成功后SystemServer调用ActivityManagerNative.getDefault().systemReady()通知ActivityManager启动成功，ActivityManager会通过置变量mBooting，通知它的另一线程，该线程会发送广播android.intent.action.BOOT_COMPLETED以告知已注册的第三方程序在开机时自动启动。
9. 总结
综上所述，系统层次关于启动最核心的部分是zygote(即app_process)和system server，zygote 它负责最基本的虚拟机的建立，以支持各个应用程序的启动，而system server用于管理android后台服务，启动步骤及顺序。
10. 参考
https://www.sodocs.net/doc/493544194.html,/basonjiang_sz/category/648399.aspx
Android 启动过程详解
Android从Linux系统启动有4个步骤；
(1) init进程启动
(2) Native服务启动
(3) System Server，Android服务启动
(4) Home启动
总体启动框架图如：
第一步：initial进程(system/core/init)
init进程，它是一个由内核启动的用户级进程。内核自行启动（已经被载入内存，开始运行，并已初始化所有的设备驱动程序和数据结构等）之后，就通过启动一个用户级程序init
的方式，完成引导进程。init始终是第一个进程.
Init.rc
Init.marvell.rc
Init进程一起来就根据init.rc和init.xxx.rc脚本文件建立了几个基本的服务：
servicemanamger
zygote
。。。
最后Init并不退出，而是担当起property service的功能。
1.1脚本文件
init@System/Core/Init
Init.c：parse_config_file(Init.rc)
@parse_config_file(Init.marvel.rc)
解析脚本文件：Init.rc和Init.xxxx.rc(硬件平台相关)
Init.rc是Android自己规定的初始化脚本(Android Init Language, System/Core/Init/readme.txt) 该脚本包含四个类型的声明：
Actions
Commands
Services
Options.
1.2 服务启动机制
我们来看看Init是这样解析.rc文件开启服务的。
（1）打开.rc文件，解析文件内容@ system/core/init/init.c
将service信息放置到service_list中。@ system/core/init parser.c
（2）restart_service()@ system/core/init/init.c
service_start
execve(…).建立service进程。
第二步Zygote
Servicemanager和zygote进程就奠定了Android的基础。Zygote这个进程起来才会建立起真正的Android运行空间，初始化建立的Service都是Navtive service.在.rc脚本文件中zygote 的描述：
service zygote /system/bin/app_process -Xzygote /system/bin --zygote --start-system-server
所以Zygote从main(…)@frameworks/base/cmds/app_main.cpp开始。
(1) main(…)@frameworks/base/cmds/app_main.cpp
建立Java Runtime
runtime.start("com.android.internal.os.ZygoteInit", startSystemServer);
(2) runtime.start@AndroidRuntime.cpp
建立虚拟机
运行：com.android.internal.os.ZygoteInit：main函数。
（3）main()@com.android.internal.os.ZygoteInit//正真的Zygote。
registerZygoteSocket();//登记Listen端口
startSystemServer();
进入Zygote服务框架。
经过这几个步骤，Zygote就建立好了，利用Socket通讯，接收ActivityManangerService的请求，Fork应用程序。
第三步System Server
startSystemServer@com.android.internal.os.ZygoteInit在Zygote上fork了一个进程: com.android.server.SystemServer.于是SystemServer@(SystemServer.java）就建立了。Android的所有服务循环框架都是建立SystemServer@(SystemServer.java）上。在SystemServer.java中看不到循环结构，只是可以看到建立了init2的实现函数，建立了一大堆服务，并AddService到service Manager。
main() @ com/android/server/SystemServer
{
init1();
}
Init1()是在Native空间实现的（com_andoird_server_systemServer.cpp）。我们一看这个函数就知道了，init1->system_init() @System_init.cpp
在system_init()我们看到了循环闭合管理框架。
{
Call "com/android/server/SystemServer", "init2"
…..
ProcessState::self()->startThreadPool();
IPCThreadState::self()->joinThreadPool();
}
init2()@SystemServer.java中建立了Android中所有要用到的服务。
这个init2（）建立了一个线程，来New Service和AddService来建立服务
第三步Home启动
在ServerThread@SystemServer.java后半段，我们可以看到系统在启动完所有的Android服务后，做了这样一些动作：
（1）使用xxx.systemReady()通知各个服务，系统已经就绪。
(2) 特别对于ActivityManagerService.systemReady(回调)
Widget.wallpaper,imm(输入法)等ready通知。
Home就是在ActivityManagerService.systemReady()通知的过程中建立的。下面是ActivityManagerService.systemReady()的伪代码：
systemReady()@ActivityManagerService.java
resumeTopActivityLocked()
startHomeActivityLocked();//如果是第一个则启动HomeActivity。
startActivityLocked（。。。）CA TEGORY_HOME
Android Booting:
init is the first process after kernel started. The corresponding source code lies in: device/system/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 indefinite loop to wait for device/property set/child process exit events. For example, if an SD card is plugined, 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 crashed, 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 device/system/rootdir/init.rc. We can take a loot at the file format(device/system/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 occurs which matches an action's trigger, 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
...
Services
Services are programs which init launches and (optionally) restarts when they exit. Services take the form of:
service
...
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 device/system/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 sou rce 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 JA V A VM.
2. Register android native function for JA V A VM.
3. Call the main function in the JA V A 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 JA V A 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.
If running on simulator, instantiate AudioFlinger, MediaPlayerService and CameraService here.
Call init2 function in JA V A 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 JA V A services.
If not running on simulator, call IPCThreadState::self()->joinThreadPool() to enter into service dispatcher.
SystemServer::init2 will start a new thread to start all JA V A 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.CA TEGORY_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 JA V A VM yet. So Android uses another method. After zynote is initialized, fork a new process to start system services.
Android 启动过程
1. Boot系统初始化，具体过程参见(system\core\init\Init.c)中的main函数，这时候，手机或者模拟器出现的画面是一个console，显示―ANDROID‖msg。
2. 初始化成功后，就开始mounting系统，具体参见(system\core\mountd\Mountd.c) 中的main 函数。
3．接下来运行ndroidRuntime，并开始启动java虚拟机dalvikvm。
4. Java虚拟机启动成功后，开始系统初始化。系统初始的第一步是用JNI方式实现的，对应java代码为(frameworks\base\services\java\com\android\server\SystemServer.java) init1（Native）函数，对应的JNI C++代码为(frameworks\base\core\jni\server\com_android_server_SystemServer.cpp)，而实现的C++代码为(frameworks\base\cmds\system_server\library\ System_init.cpp) 中的system_init（）函数。
5. system_init调用SurfaceFlinger，SurfaceFlinger的readyToRun()函数用BootAnimation来实现开机动画，这时候手机或者模拟器显示是一副背景图加一个动态的小机器人。
6. 系统初始化的第二步，将启动ServerThread进程，参见SystemServer.init2()。ServerThread 将启动各种系统服务，如Power Manager、Activity Manager等等，具体参见ServerThread的run函数，ServerThread同在SystemServer.java中。
7.这之后的事，应该就是进入系统了。（这部分没有调查过）。
对Android启动过程的进一步研究
对于关注Android底层的朋友来说，其具体的启动过程应该是比较吸引我们的。但是很多启动文件什么的，都得adb push到host上来看，挺不方便的，都怪Android自带的Toolbox太简略了。所以在深入了解Android的启动流程之前，我们来把Busybox安装到Android上去，这样，就有很多工具供我们使用了。
首先去busybox主页下载最新版本的源代码，然后用arm的交叉编译器编译出busybox 的可执行程序，编译的时候需要注意一些设置选项，例如
Build Options —>
Build BusyBox as a static binary (no shared libs) 这个要选上，因上这样子编译出来的busyBox才是可以独立运行的。
│Do you want to build BusyBox with a Cross Compiler? ││
││(/HOME/toolchains/gcc-4.0.2-glibc-2.3.5/arm-9tdmi-linux-gnu/bin/arm-9tdmi-linux-gnu│这是交叉编译器的路径，要根据具体的情况来设置。
Installation Options —>
Don’t use /usr
这样子编译出来的busybox才不会安装到你主机的/usr目录下。一定要选上。
busybox的功能选项根据需要自选,但是不要太贪心.
OK，这里就不纠缠于编译busybox的东西了，网上资料无数。接下来，我们把busybox 安装到模拟器上去。先在模拟器上随便建一个busybox的文件夹，然后进入busybox可执行文件目录，使用命令
adb push busybox.asc /data/busybox/busybox
然后进入adb shell，chmod 777 ./busybox，就可以直接使用了。但现在还是不方便，总不能每用一个命令就输一次busybox吧?所以，我们可以先用./busybox --install将程序都安装到当前目录下，然后把当前目录添加到PA TH变量中即可。暂时使用export来添加吧，如果想永久添加，往下看。
好了，准备工作完成，开始研究的工作了。既然是研究启动过程，那当然是先看看init.rc 文件。去etc目录打开它，分析一下内容，首先是对env的定义，也就是全局环境变量的定义，接下来的建立和初始化里面的内容目前还不清楚什么意思，紧接着就是系统启动时运行的初始进程信息，这个比较有意思，包括了usbd-config和qemu，qemu自不用说，而usbd-config作为初始启动的进程，应该就是和上一篇文章猜的一样，用来调试或者usb通信的。往下看，是在初始启动进程完成之后开始启动的服务进程，这些进程如果因故退出，会自动重启。这里面包括了console控制台，adbd监护进程，usbd监护进程，debuggerd监护进程等.除去这些守护进程，能引起我们注意的，是runtime和zygote。这两个进程似乎掌管着其他进程以及应用程序的启动。
现在，来让我们做一个实验吧，将自动调用的启动过程变成手动，看看启动流程具体是什么样的。想达到这个目的，首先就是要修改init.rc文件，当然不是在模拟器的console中改，一是不能改，二是你改了也没用，下次加载就会给你覆盖了。所以，我们要从原始镜像ramdisk.img入手了。从2.6标准Linux内核开始，initrd.img都采用cpio压缩，猜测ramdisk.img 也一样，需要使用gunzip解压缩，然后再使用cpio解包。好，进入tools/lib/images目录下，先用file命令看看ramdisk.img的类型，没错，系统提示
ramdisk.img: gzip compressed data, from Unix
很好，然后将ramdisk.img复制一份到任何其他目录下，将其名称改为ramdisk.img.gz，并使用命令
gunzip ramdisk.img.gz
然后新建一个文件夹，叫ramdisk吧，进入，输入命令
cpio -i -F ../ramdisk.img
这下，你就能看见并操作ramdisk里面的内容了。当然你也可以直接在外面进行操作，但是还是建议把cpio解压缩出来的内容全部集中在一个文件夹里面，因为一会我们还要将其压缩成新的ramdisk.img。
OK，现在开始修改步骤吧。用任何一款编辑器打开init.rc，首先在PA TH那里加上你的Busybox安装路径，然后注释内容，我们要手工启动他们。
# zygote {
# exec /system/bin/app_process
# args {
# 0 -Xzygote
# 1 /system/bin
# 2 –zygote
# }
# autostart 1
# }# runtime {
# exec /system/bin/runtime
# autostart 1
# }
在这里需要注意，不要同时把两者都注释了，注释某一个，再试验手工启动它，如果两者同时注释我这里有问题，无法启动。
好，接下来，使用下列命令重新打包成镜像
cpio -i -t -F ../ramdisk.img > list
cpio -o -H newc -O lk.img < list
当前目录下生成的lk.img就是我们的新镜像了。使用自己的镜像启动emulator;
emulator -console -ramdisk lk.img
如果我们注释的是zygote，那么在#后输入
app_process -Xzygote /system/bin –zygote
手工启动，命令行中输出的信息是
Prepping: /system/app/AlarmProvider.apk:/system/app/Browser.apk:/system/app/ Calendar.apk:/system/app/Camera.apk:/system/app/Contacts.apk:
/system/app/Development.apk:/system/app/GDataFeedsProvider.apk:/system/app/
Gmail.apk:/system/app/GmailProvider.apk:/system/app/GoogleApps.apk:
/system/app/GoogleAppsProvider.apk:/system/app/Home.apk:/system/app/ImProvider.apk: /system/app/Maps.apk:/system/app/MediaPickerActivity.apk:
/system/app/MediaProvider.apk:/system/app/Phone.apk:/system/app/PimProvider.apk:/system/ app/ApiDemos.apk:/system/app/SettingsProvider.apk:
/system/app/Sms.apk:/system/app/SyncProvider.apk:/system/app/TelephonyProvider.apk:
/system/app/XmppService.apk:/system/app/Y ouTube.apk
File not found: /system/app/AlarmProvider.apk
File not found: /system/app/Calendar.apk
File not found: /system/app/Camera.apk
File not found: /system/app/GDataFeedsProvider.apk
File not found: /system/app/Gmail.apk
File not found: /system/app/GmailProvider.apk
File not found: /system/app/MediaPickerActivity.apk
File not found: /system/app/PimProvider.apk
File not found: /system/app/ApiDemos.apk
File not found: /system/app/Sms.apk
File not found: /system/app/SyncProvider.apk
File not found: /system/app/Y ouTube.apk
Prep complete
嘿嘿，从File not found的信息中可以看到一些Google可能会即将推出的应用，比如Gmail什么的。当然，这些都是Java框架的启动信息，我们以后还要借助其他工具来进行进一步探索。
如果我们注释的是runtime，那么输出信息是：
+++ post-zygote
老实说，没有明白这是啥意思，呵呵，吃饭时间到了，懒得看了。
好了，今天就说到这，基本的方法就是这样，有兴趣的朋友可以进一步深入研究。
android系统开机启动流程分析
一，系统引导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.
分析Android 开机启动慢的原因
开机启动花了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;
Android 开机启动流程
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,这是只是向特定层上绘图,其代码了存放在特殊的位置
基于MT6752的 android 系统启动流程分析报告
基于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内核启动+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开机动画及声音制作专业 班级 学号 姓名 完成日期 2017年月日
课程设计任务书 设计题目:Android开机动画与声音制作 设计内容与要求： 修改Android开机动画和声音的是建立自定义Android系统的入门课程和基本功。Android系统的开机动画需要修改和设定bootanimation.zip文件，修改开机声音需要自定义OGG文件并导入系统指定位置。 题目的基本要求如下： 1. 寻找并下载合适的开机视频； 2. 将视频转换成连续的PNG图像文件； 3. 修改desc.txt文件并打包bootanimation.zip文件； 4. 获取合适的开机声音并利用格式工厂工具转换为OGG格式； 5. 通过adb shell指令，进入控制板系统内并修改android系统文件只读属性； 6. 点击开发板的“复位”进行复位，重启开发板查看修改结果。 指导教师： 年6月日 课程设计评语 成绩： 指导教师：_______________ 年月日
目录 第1章概述 (2) 1.1 Android应用平台简介 (2) 1.2 RK2928开发板介绍 (2) 第2章 Android开机动画及声音制作 (5) 2.1 基本操作流程 (5) 2.2 开机动画的制作与添加 (6) 2.3 开机声音的制作与添加 (11) 2.4 开机动画及声音结果 (12) 第3章心得体会 (13)
第1章概述 1.1 Android应用平台简介 Android一词的本义指“机器人”，同时也是Google于2007年11月5日宣布的基于Linux平台的开源手机操作系统的名称，该平台由操作系统、中间件、用户界面和应用软件组成。Android是一种基于Linux的自由及开放源代码的操作系统，主要使用于移动设备，如智能手机和平板电脑，由Google公司和开放手机联盟领导及开发。尚未有统一中文名称，中国大陆地区较多人使用“安卓”或“安致”。Android操作系统最初由Andy Rubin开发，主要支持手机。2005年8月由Google收购注资。2007年11月，Google与84家硬件制造商、软件开发商及电信营运商组建开放手机联盟共同研发改良Android系统。随后Google以Apache开源许可证的授权方式，发布了Android的源代码。第一部Android智能手机发布于2008年10月。Android逐渐扩展到平板电脑及其他领域上，如电视、数码相机、游戏机等。2011年第一季度，Android在全球的市场份额首次超过塞班系统，跃居全球第一。2013年的第四季度，Android平台手机的全球市场份额已经达到78.1%。 1.2 RK2928开发板介绍 图1-1 实验板外观 作为RK292系列里较为高级的芯片之一，RK2928提供了比较不错的性能。较RK2926，RK2928集成了HDMI 1.4a控制器及GPS基带的支持，为300元价
Android开机启动流程样本
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系统启动过程 首先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
RK系统启动流程
RK29机型之Android系统启动流程 分类：瑞芯微RK 2012-02-12 14:50 4439人阅读评论(0) 收藏举报/******************************************************************************************** * author：conowen@大钟 * E-mail：conowen@https://www.sodocs.net/doc/493544194.html, * https://www.sodocs.net/doc/493544194.html,/conowen * 注：本文为原创，仅作为学习交流使用，转载请标明作者及出处。 ********************************************************************************************/ 第一步：系统引导bootloader，即RK29xxLoaderXXX.bin文件 加电后，CPU将先执行 bootloader程序，然后bootloader首先会读寄存器地址base + APP_DATA1的内容，根据这个地址的值决定是否进入recovery模式或者其它模式。bootloader还会读取MISC分区第一块的内容，决定进入recovery模式还是升级基带Baseband Processor（BP）或做其它事情 而上述寄存器与分区的值是有按键触发或者软件触发的。 a) 开机按reset+返回键，系统进入recovery模式，加载recovery.img，recovery.img 包含内核，基本的文件系统，用于工程模式的烧写 b) 开机按Power，正常启动系统，加载boot.img，boot.img包含内核，基本文件系统，用于正常启动机器（以下只分析正常启动的情况） 第二步：启动内核kernel 1) 源码：kernel/* 2) 说明：kernel由bootloader加载 第三步：文件系统(rootfs)及应用初始化（init） 1) 源码：system/core/init/* 2) 配置文件：system/rootdir/init.rc， 3) 说明：init是一个由内核启动的用户级进程，它按照init.rc中的设置执行：启动服务（这里的服务指linux底层服务，如adbd提供adb支持，vold提供SD卡挂载等），执行 命令和按其中的配置语句执行相应功能 第四步：重要的后台程序zygote 1) 源码：frameworks/base/cmds/app_main.cpp等 2) 说明：zygote是一个在init.rc中被指定启动的服务，该服务对应的命令是 /system/bin/app_process a) 建立Java Runtime，建立虚拟机
Android SystemBar启动流程分析
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(); … }
AndroidL系统启动及加载流程分析
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进程注册服务中，该服务启动时主要功能是初始化整个显
BOOTCHART ANDROID文档(开机慢)
BootChart在Android中的应用 1简介 Bootchart是一个能对GNU/Linux boot过程进行性能分析并把结果直观化的工具。它在boot过程中搜集资源利用情况及进程信息然后以PNG,SVG或EPS格式来显示结果。BootChart包含数据收集工具和图像产生工具，数据收集工具在原始的BootChart中是独立的shell程序，但在Android中，数据收集工具被集成到了init程序中。 2BootChart使用步骤概述 ?在主机上安装BootChart ?建立有BootChart支持的init文件 ?安装init到系统镜像 ?使能启动时的BootChart功能 ?收集系统产生的数据 ?根据产生的数据生成图表 ?结果分析 以下部分将对这些步骤进行详细描述(环境：Ubuntu9.04,Android1.6)。 3详细说明 ?在主机上安装BootChart $sudo apt-get install bootchart 注：由于BootChart是用Java语言实现，所以要求其所运行的主机安装Java包。 ?创建支持BootChart功能的‘init’文件 Andoid系统中运行的第一个程序是'init',其所在的目录为Andoid文件系统的根目录下(即/)。'init'是一个由内核启动的用户级进程，主要是对系统进行初始化和根据init.rc与init.xxx.rc文件建立几个基本的服务。 创建'init'时对BootChart的数据收集功能是可选的，默认的'init'是不支持BootChart 的数据收集功能的。要想在Andoid中应用BootChart，必须创建支持BootChart数据收集功能的'init'。 $cd~/myandroid $export INIT_BOOTCHART=true #vim system/core/init/Android.mk 20ifeq($(strip$(INIT_BOOTCHART)),true) 21LOCAL_SRC_FILES+=bootchart.c
android开机启动流程简单分析
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 编译启动过程分析
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 Service如何开机自启动以及自启动失败原因
Android Service如何开机自启动以及自启动失败原因 本文主要介绍Android Service如何开机自启动、自启动失败的原因、adb命令发送 BOOT_COMPLETED。 应用程序是否可以在安装后自启动，没有ui的纯service应用如何启动？ 1、Android应用如何开机自启动 (1)、在AndroidManifest.xml中注册 AndroidManifest.xml中注册BOOT_COMPLETED Action注意不仅要添加 android.intent.action.BOOT_COMPLETED对应的action，还需要添加对应的uses-permission (2)、Receiver接收广播进行处理 public class BootBroadcastReceiver extends BroadcastReceiver { public static final String TAG = "BootBroadcastReceiver"; @Override public void onReceive(Context context, Intent intent) { String action = intent.getAction().toString(); if (action.equals(Intent.ACTION_BOOT_COMPLETED)) { // u can start your service here Toast.makeText(context, "boot completed action has got", Toast.LENGTH_LONG).show(); return; } } } 2、自启动失败的原因 接收不到BOOT_COMPLETED广播可能的原因 (1)、BOOT_COMPLETED对应的action和uses-permission没有一起添加 (2)、应用安装到了sd卡内，安装在sd卡内的应用是收不到BOOT_COMPLETED广播的 (3)、系统开启了Fast Boot模式，这种模式下系统启动并不会发送BOOT_COMPLETED广播 (4)、应用程序安装后重来没有启动过，这种情况下应用程序接收不到任何广播，包括 BOOT_COMPLETED、ACTION_PACKAGE_ADDED、CONNECTIVITY_ACTION等等。 Android3.1之后，系统为了加强了安全性控制，应用程序安装后或是(设置)应用管理中被强制关闭后处于stopped状态，在这种状态下接收不到任何广播，除非广播带有 FLAG_INCLUDE_STOPPED_PACKAGES标志，而默认所有系统广播都是 FLAG_EXCLUDE_STOPPED_PACKAGES的，所以就没法通过系统广播自启动了。所以Android3.1之后 (1)、应用程序无法在安装后自己启动 (2)、没有ui的程序必须通过其他应用激活才能启动，如它的Activity、Service、Content Provider被其他应用调用。 存在一种例外，就是应用程序被adb push you.apk /system/app/下是会自动启动的，不处于stopped状态。
android开机过程
一、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：的错误。
Android系统启动升级流程
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系统的开机画面显示过程分析
- Android开机启动流程
- android启动优化
- 基于MT6752的 android 系统启动流程分析报告
- Android Service如何开机自启动以及自启动失败原因
- Android系统完整的启动过程
- Android系统Activity窗口启动过程
- android开机启动流程说明
- RK系统启动流程
- android开机过程
- Android系统默认Home应用程序(Launcher)的启动过程源代码分析
- android 开机logo制作详细步骤
- 分析Android 开机启动慢的原因
- 安卓系统快速开机的方法及设备的制作技术
- Android系统启动过程详解
- linux内核启动Android系统启动过程详解
- android系统启动过程(1)
- 安卓系统启动流程
- Android开机启动流程样本
- Android 开机启动流程