Android核心分析（01）----讨之设计意图 (2)
Android核心分析（02）----方法论探讨之概念空间篇 (4)
Android核心分析（03）----手机之硬件形态 (7)
Android核心分析（04）----手机的软件形态 (9)
Android核心分析（05）----基本空间划分 (10)
Android核心分析（06）----IPC框架分析 (13)
Android核心分析（07）----Service深入分析 (20)
Android核心分析（08）----Android 启动过程详解 (27)
Android核心分析（09）----Zygote Service (31)
Android核心分析（10）----Android GWES之基本原理篇 (34)
Android核心分析（11）----Android GWES之消息系统 (37)
Android核心分析（12）----Android GEWS窗口管理之基本架构原理 (42)
Android核心分析（13）----Android GWES之Android窗口管理 (43)
Android核心分析（14）----Android GWES之输入系统 (50)
Android核心分析（15）----Android输入系统之输入路径详解 (53)
Android核心分析（16）----Android电话系统-概述篇 (59)
Android核心分析（17）----电话系统之rilD (62)
Android核心分析（18）----Android电话系统之RIL-Java (68)
Android核心分析（19）----电话系统之GSMCallT acker (75)
Android核心分析（20）----Android应用程序框架之无边界设计意图 (78)
Android核心分析（21）----Android应用框架之AndroidApplication (80)
Android核心分析（22）----Android应用框架之Activity (86)
Android核心分析（23）----Andoird GDI之基本原理及其总体框架 (92)
Android核心分析（24）----Android GDI之显示缓冲管理 (95)
Android核心分析（25）----Android GDI之共享缓冲区机制 (101)
Android核心分析（26）----Android GDI之SurfaceFlinger (105)
Android核心分析（27）----Android GDI SurfaceFlinger之动态结构示意图 (112)
Android核心分析（28）----Android GDI之Surface&Canvas (115)
Android核心分析（01）----讨之设计意图
为什么要研究Android，是因为它够庞大，它够复杂，他激起了我作为一个程序员的内心的渴望，渴望理解这种复杂性。我研究的对象是作为手机开发平台的Android软件系统部分，而不是Dalvik虚拟机本身。
作为一个从其他平台装接过来的程序员，要从事Andoid平台系统开发，我的关于手机平台上积累的知识已经不能满足需要了，Android为我们带来了大量的新名词，Activity，Manifest，INTENT，Service，Binder，Dalvik虚拟机，Framework，Linux，Navtive ，JNI.....。通过在源代码，在开发社区，在开发博客，甚至在招聘过程中，我不断的寻求Android是什么。经过一定时间的沉淀，我慢慢的理解到Android 不仅仅是一类手机的总称，不仅仅是一个手机开发平台，不仅仅是一个虚拟java操作系统，不仅仅是一个开发社区，一个开发标准，不仅仅是一堆代码，Android已经成了一个新的潮流。
代码多，系统复杂，纵观社区中Android的研究者，一开始从源代码分析Android就走向迷途，不断的跋山涉水，向纵深冲刺，最终脑袋堆栈不够用，迷失在开始的旅程，或者挂在半途中，鲜有通达者。我感觉到大部分的研究者总是忘记站在高山上向下望一望设计者的意图，一味的随着代码的控制流走入繁杂的谜团，陷入到复杂性的深渊。
我的研究分析是从设计者的意图出发，从抽象的甚至从哲学的高度，从最简单的系统原型开始，从设计猜想开始，而不是一开始就从代码分析展开。首先理解Android大的运行框架，主干流程，系统原型，之后再用源代码分析充实之。当然我这里的设计者意图并不是真正的Android设计者意图，而是我以为的Android设计者意图。
要理解设计者意图，就需要抽象。我们需要在哲学意义空间中去考虑系统的描述，即系统在本质上要表达什么。在逻辑空间上去考虑系统基本构成和动态结构。从现实到虚拟对象的映射去理解系统对象的组成，在从数据流的角度分析数据的产生者和消费者之间作用关系，从控制流的角度去分析对象之间的交互关系，从函数调用去分析具体的层次关系。
在系统设计上，原型是最能表达哲学空间和逻辑空间中系统本质的东西，原型是事物本质的第一层体现。我以为任何复杂的系统都一个简洁的系统原型，都有它简洁的意义。系统原型是设计者意图的第一体
现，所以我们需要从几个方向上去提炼系统原型：
（1）从系统本质和基本原理出发
（2）从分析系统数据流和控制流分析出发。
从设计者意图出发，得出系统原型，提取到大的逻辑结构和系统构成是第一步。之后我们可以从设计者的角度考虑系统猜想系统设计，为什么要这样设计，为什么要有这些构成。这样的基本原型是什么？系统的限制是什么，应用场景有哪些，有些设计的引进还是系统收敛性而为之呢。我们还可以从代码痕迹上去分析，这些概念是如何的得来的？从一定的抽象和高度去理解这些问题，遵循系统原型出发之原则，在深入分析代码的时候，就不容易陷入细节中。我们就可以随时跳出来想，这些代码在整体上载表达一个什么概念，在描绘一个什么逻辑，他要构成一个虚拟层吗？他是在管理这个硬件吗？他在虚拟这个对象吗？他在构建管理机构？还是在构建一个对象管理？空间管理，为了快速引入了什么样的复杂算法，实际上的原型算法应该是什么样的？
只有深入到这个抽象层次，我们才能很好的把握住系统的每一条线，每一个对象的意义。只用从原型出发，我们才能把握住这个系统的实质所在，在干什么？他要表达什么？设计者为什么要这样想？最终极的想法是什么？这样，代码分析就变得简单明了，读代码就变成了是在印证猜想，修正方向。
本文来自CSDN博客，转载请标明处：https://www.doczj.com/doc/0813179168.html,/maxleng/archive/2010/04/10/5471557.aspx
Android核心分析（02）----方法论探讨之概念空间篇
我们潜意识就不想用计算机的方式来思考问题，我们有自己的思维描述方式，越是接近我们思维描述方式，我们越容易接受和使用。各种计算机语言，建模工具，不外乎就是建立一个更接近人的思维方式的概念空间，再使用工具从该概念空间向另外一个概念空间映射，我称之为人性思维空间向01序列描述空间的一个映射。实现方面来看，系统就是一个翻译器，将机器性更加人性化的一种机制。大学计算机经典课“计算机体系结构”，其他的可以忘记，但是下面这个图不能忘记：
这个就是概念空间最本质的原型体现：作为观测者看到了什么？设计者给了观察者什么？给出的答案是外部特性。
（1）提供给观察者的概念空间是什么？
（2）内部特性的概念空间是什么？
概念空间所表达的东西带有两个方面的缠绕：一面是人性自由，一面是物性制约（实时响应，系统资源的限制）。所以程序实现的概念空间是人性自由与特定计算机系统物性之间有一个折中，并且根据实际系统而采取某种动态的平衡。而这种平衡将会影响到系统架构，以及设计的思想。特别在手机这样的嵌入式系统中，这种矛盾和平衡无处不在，这种折中无处不在。而对系统的选取和采用，也就接受了某个方面的折中或某中即在的，也许是看不见的标准，及这样的标准有隐式和显式的。正因为如此，不管是工具的产生，新的平台的产生，都是计算机的物性向人性靠近的一个小台阶。一个新的思想的形成随即带来的新工具，新系统框架，新的体系结构。
如果设计者站的高度足够高，那么设计者一开始就会考虑到“我该给他们一个什么样的概念空间，甚至一个什么样的理念，让他们这个概念空间去建立自己的产品”，于是设计者就会开始主动的去建立概念空间，这个概念空间要表达的实际意义，概念空间应该有哪些内容构成，考虑概念空间的完备性和封闭性，考虑概念空间的边界，考虑从哪个基础上建立这个概念空间，考虑如何与概念空间外的实体进行交互，考虑系统的资源限制条件，考虑功能性构建的合理性，考虑机器系统与人的平衡问题。
我们在学习新系统时，首先映入眼帘的就是新概念。新名词，就如现在我们面临的Android大量的新名词，在程序员的世界都是从代码实践开始的，是从写应用开始去涉及。SDK给了我们一个概念，我们就在这个概念框架下，使用SDK给我提供的函数接口，数据结构，初始化过程等，我们最初的接触到原型就是“HelloWorld”之类的DEMO程序，我们在Hello world上去使用各种不同的接口函数，对于应用程序员来讲，他说看到的系统就是系统调用接口，及其编程开发流程。实际上只要一使用这些接口，就不得不接受一系列的概念，只有在这种概念系统下，我们才能工作。但是，实际上我们却忽略了这样的概念系统的理解，只是在编程接口的这个狭窄的空间去理解系统.我们理解系统在形成理解概念的空间只是微小的一角，很少有资料来介绍这种概念系统的形成和理解，编程接口只是这个概念空间一个，对外部的一个表征。我们可以抽象起来，以接口，协议和行为，来描述系统的情况。SDK API的实质向上层提供了一个语义接口，从而在层间实现了一个转义过程，同时又成为一个功能的集合体。但是我们很少这样跳出来看，我们到底是处于一种什么样的概念空间，SDK除了调用接口外，还给了我们怎样一种整体概念？目标系统的基本构架在本质上的东西就是一个概念系统到另一个概念系统的映射。让我们大脑理解的概念系统映射到计算机能实现的概念域的一个映射。我们假定这个概念域E，机器能够理解的概念域为M，我们的软件工程要做的事情实质就是：EàM领域的一个映射过程。
为什么要在宏观上把握这些概念呢，显然有我的目的，理解概念空间是理解设计者意图的一个重要途径。设计者要想给开发者提供什么，设计者想要提供给最终用户什么。我们需要站在高处看待系统明白设计者意图。
Android的实质还是一套管理手机硬件系统的软件，这个话讲起来没有多大意义，计算机操作系统本质都是如此，Android是Google云计算计划的一部分，我们修正成：Android建立的本质就是让计算机成为我的云接入移动智能终端。作为硬件管理软件，Android提供概念空间内涵实质上泛操作系统内涵，我们的理解可以从泛操作系统概念空间映射到Android系统中去。而作为云计算的一部分的内容，我们可以云计算的概念入手去研究Andoird。
Android核心分析（03）----手机之硬件形态
本节可能与Android无关，但是Android系统现在这个阶段更多的是移动终端形态的开发平台，本节给出了Android背后的工作-Android管理的硬件是什么，Android的本质就是要管理好这些硬件部分，为用户提供一个体验更好，速度更快的智能移动终端。对手机硬件形态的认识是要让我们对手机硬件组成有个感性的认识，让程序员知道系统中的代码是管理那一部分的，即我们堆砖头的目的是什么，让思维有一个伸展。
为了对手机这类嵌入式系统有一个较为深入的了解，我制作了如下的手机硬件结构思维导图，在这张图上我们可以看到组成手机硬件的有哪些，初步了解到手机管理平台为什么要那么多的管理框架和层次，从最底层理解Android设计者的设计意图，这个思维导图其实只是示意图。
我们知道手机这种嵌入式系统，硬件架构最简单描述的描述为：
应用处理器+Modem+射频
对于应用处理器而言，对设计者最为本质的描述为输入输出，而对于移动终端设备电源管理，连接机制，多媒体又是很重要的考虑环节，而这些环节都会在软件平台上有所体现。
本文来自CSDN博客，转载标明处：https://www.doczj.com/doc/0813179168.html,/maxleng/archive/2010/04/12/5476544.aspx
Android核心分析（04）----手机的软件形态
上节我给出了手机的硬件树，本节将给出手机软件形态树。主要突出手机软件涵盖的内容。通过该思维导图，我们可以看到手机软件所涉及到的方方面面，Android所涉及到的内容也不会超过下面所示太多，这个也是Andoid系统外特性空间所要展示的，这个也是Android设计者需要考虑管理的大部分内容，通过下面的整理，我们可以让我们的思维更加贴近Android设计意图，从而更深入的了解Android中各种组成的由来，这个就是前面讲到的分析思想之一从退到源头出发，从思考最终极的问题开始。
Android核心分析（05）----基本空间划分
Google给了我们一张系统架构图，在这张图上我们可以看到Android的大体框架组成。
从上图可以看到：Android Applications，Application Framework，Dalvik Virtual Machine，Linux。如果将Android泛化，我们可以将系统划分成两部分：
但是为了研究的方便我们先看最为本质的三层，上面是Android，中间叫Dalvik虚拟机，下面叫Linux。
虽然上两层都包含在Android中，但是为了理解的方便或者从实用主义出发，我还是将虚拟机这次给
分开出来，因为我研究的对象是Android的手机系统相关部分，对于虚拟机我们不做太深入的研究。
从上面我们可以看到这个系统静态的划分成这样的三层。但是从动态运行逻辑上不是这样划分的，所以空间的划分是一个有趣的概念。我们从操作系统的角度看，Android就是一堆Linux应用的集合。从Linux 角度看到的空间划分：进程空间和内核空间。从Android的应用对应着Linux的一个个进程。
Andoid中包含一个Java虚拟机，虚拟机是运行在Linux之上的，Android构建在JVM之上，从Android 动态运行逻辑上我们需要将Android划分成Android空间和非Android空间。在Andoid系统中我们面对的是Andoid概念空间，而不是Linux进程了，在Andoid概念空间中已经没有了Lliux进程的概念，而是Service，proxy，Activity，provider等。
至于虚拟机JVM，我们只需要知道JVM是Dalvik VM（虚拟机）这是一个专为嵌入式设备打造的ＪＡＶＡ虚拟机，是一个有着自己的code-byte和格式的可以在嵌入式设备上高效运行的Java虚拟机。
为了研究的深入，我们还是需要涉及到JNI Native部分。在这个分类中我将JVM分为JVM空间和C++空间。
Android应用的开发者是工作在Android外特性概念空间的，这里没有了Linux的一点气息，Android 构建的外特性空间概念包含了：Activity，Provider，Interface，Events，Provider，Service等。至于JVM 空间和C++空间的划分是为了研究Android核心的描述而提出的，我们在做Android系统开发时，常常需要修改到JNI的Native部分。后面我将用较多的篇幅来深入阐述这个部分。
本文来自CSDN博客，转载请标明出处：https://www.doczj.com/doc/0813179168.html,/maxleng/archive/2010/04/15/5490713.aspx
Android核心分析（06）----IPC框架分析
Binder，Service，Service manager
IPC:inter-Process Communication
我首先从宏观的角度观察Binder，Service，Service Manager，并阐述各自的概念。从Linux的概念空间中，Android的设计Activity托管在不同的的进程，Service也都是托管在不同的进程，不同进程间的Activity，Service之间要交换数据属于IPC。Binder就是为了Activity通讯而设计的一个轻量级的IPC框架。
在代码分析中，我发现Android中只是把Binder理解成进程间通讯的实现，有点狭隘，而是应该站在公共对象请求代理这个高度来理解Binder，Service的概念，这样我们就会看到不一样的格局，从这个高度来理解设计意图，我们才会对Android中的一些天才想法感到惊奇。从Android的外特性概念空间中，我们看不到进程的概念，而是Activity，Service，AIDL，INTENT。一般的如果我作为设计者，在我们的根深蒂固的想法中，这些都是如下的C/S架构，客户端和服务端直接通过Binder交互数据，打开Binder 写入数据，通过Binder读取数据，通讯就可以完成了。
该注意到Android的概念中，Binder是一个很低层的概念，上面一层根本都看不到Binder，而是Activity 跟一个Service的对象直接通过方法调用，获取服务。
这个就是Android提供给我们的外特性：在Android中，要完成某个操作，所需要做的就是请求某个有能力的服务对象去完成动作，而无需知道这个通讯是怎样工作的，以及服务在哪里。所以Andoid的IPC 在本质上属于对象请求代理架构，Android的设计者用CORBA的概念将自己包装了一下，实现了一个微型的轻量级CORBA架构，这就是Andoid的IPC设计的意图所在，它并不是仅仅解决通讯，而是给出了一个架构，一种设计理念，这就是Android的闪光的地方。Android的Binder更多考虑了数据交换的便捷，并且只是解决本机的进程间的通讯，所以不像CORBA那样复杂，所以叫做轻量级。
所以要理解Android的IPC架构，就需要了解CORBA的架构。而CORBA的架构在本质上可以使用下面图来表示：
在服务端，多了一个代理器，更为抽象一点我们可以下图来表示。
分析和CORBA的大体理论架构，我给出下面的Android的对象代理结构。
在结构图中，我们可以较为清楚的把握Android的IPC包含了如下的概念：
●设备上下文（ContextObject）
设备上下文包含关于客服端，环境或者请求中没有作为参数传递个操作的上下文信息，应用程序开发者用ContextObject接口上定义的操作来创建和操作上下文。
●Android代理：这个是指代理对象
●Binder Linux内核提供的Binder通讯机制
Android的外特性空间是不需要知道服务在那里，只要通过代理对象完成请求，但是我们要探究
Android是如何实现这个架构，首先要问的是在Client端要完成云服务端的通讯，首先应该知道服务在哪里？我们首先来看看Service Manger管理了那些数据。Service Manager提供了add service，check service两个重要的方法，并且维护了一个服务列表记录登记的服务名称和句柄。
Service manager service使用0来标识自己。并且在初始化的时候，通过binder设备使用BINDER_SET_CONTEXT_MGR ioctl将自己变成了CONTEXT_MGR。Svclist中存储了服务的名字和Handle，这个Handle作为Client端发起请求时的目标地址。服务通过add_service方法将自己的名字和Binder标识handle登记在svclist中。而服务请求者，通过check_service方法，通过服务名字在service list中获取到service 相关联的Binder的标识handle，通过这个Handle作为请求包的目标地址发起请求。
我们理解了Service Manager的工作就是登记功能，现在再回到ＩＰＣ上，客服端如何建立连接的？我们首先回到通讯的本质：IPC。从一般的概念来讲，Android设计者在Linux内核中设计了一个叫做Binder 的设备文件，专门用来进行Android的数据交换。所有从数据流来看Java对象从Java的VM空间进入到C++空间进行了一次转换，并利用C++空间的函数将转换过的对象通过driver\binder设备传递到服务进程，从而完成进程间的IPC。这个过程可以用下图来表示。
这里数据流有几层转换过程。
（1）从JVM空间传到c++空间，这个是靠JNI使用ENV来完成对象的映射过程。
（2）从c++空间传入内核Binder设备，使用ProcessState类完成工作。
（3）Service从内核中Binder设备读取数据。
Android设计者需要利用面向对象的技术设计一个框架来屏蔽掉这个过程。要让上层概念空间中没有这些细节。Android设计者是怎样做的呢？我们通过c++空间代码分析，看到有如下空间概念包装(ProcessState@(ProcessState.cpp)
在ProcessState类中包含了通讯细节，利用open_binder打开Linux设备dev\binder，通过ioctrl建立的基本的通讯框架。利用上层传递下来的servicehandle来确定请求发送到那个Service。通过分析我终
于明白了Bnbinder，BpBinder的命名含义，Bn-代表Native，而Bp代表Proxy。一旦理解到这个层次，ProcessState就容易弄明白了。
下面我们看JVM概念空间中对这些概念的包装。为了通篇理解设备上下文，我们需要将Android VM 概念空间中的设备上下文和C++空间总的设备上下文连接起来进行研究。
为了在上层使用统一的接口，在JVM层面有两个东西。在Android中，为了简化管理框架，引入了ServiceManger这个服务。所有的服务都是从ServiceManager开始的，只用通过Service Manager获取到某个特定的服务标识构建代理IBinder。在Android的设计中利用Service Manager是默认的Handle为0，只要设置请求包的目标句柄为0，就是发给Service Manager这个Service的。在做服务请求时，Android 建立一个新的Service Manager Proxy。Service Manager Proxy使用ContexObject作为Binder和Service Manager Service（服务端）进行通讯。
我们看到Android代码一般的获取Service建立本地代理的用法如下：
IXXX mIxxx=IXXXInterface.Stub.asInterface(ServiceManager.getService("xxx"));
例如：使用输入法服务：
IInputMethodManager mImm=
IInputMethodManager.Stub.asInterface(ServiceManager.getService("input_method"));
这些服务代理获取过程分解如下：
（1）通过调用GetContextObject调用获取设备上下对象。注意在AndroidJVM概念空间的ContextObject只是与Service Manger Service通讯的代理Binder有对应关系。这个跟c++概念空间的GetContextObject意义是不一样的。
注意看看关键的代码
BinderInternal.getContextObject（）@BinderInteral.java
NATIVE JNI:getContextObject() @android_util_Binder.cpp
Android_util_getConextObject @android_util_Binder.cpp
ProcessState::self()->getCotextObject(0) @processState.cpp
getStrongProxyForHandle(0) @
NEW BpBinder(0)
注意ProcessState::self()->getCotextObject(0) @processtate.cpp，就是该函数在进程空间建立了ProcessState对象，打开了Binder设备dev\binder，并且传递了参数0，这个0代表了与Service Manager 这个服务绑定。
（2）通过调用ServiceManager.asInterface（ContextObject）建立一个代理ServiceManger。
mRemote= ContextObject(Binder)
这样就建立起来ServiceManagerProxy通讯框架。
（3）客户端通过调用ServiceManager的getService的方法建立一个相关的代理Binder。
ServiceMangerProxy.remote.transact(GET_SERVICE)
IBinder=ret.ReadStrongBinder() -》这个就是JVM空间的代理Binder
JNI Navite: android_os_Parcel_readStrongBinder() @android_util_binder.cpp
Parcel->readStrongBinder() @pacel.cpp
unflatten_binder @pacel.cpp
getStrongProxyForHandle(flat_handle)
NEW BpBinder(flat_handle)-》这个就是底层c++空间新建的代理Binder。
整个建立过程可以使用如下的示意图来表示：
Activity为了建立一个IPC，需要建立两个连接：访问Servicemanager Service的连接，IXXX具体XXX Service的代理对象与XXXService的连接。这两个连接对应c++空间ProcessState中BpBinder。对
IXXX的操作最后就是对BpBinder的操作。由于我们在写一个Service时，在一个Package中写了Service Native部分和Service Proxy部分，而Native和Proxy都实现相同的接口：IXXX Interface，但是一个在服务端，一个在客服端。客户端调用的方式是使用remote->transact方法向Service发出请求，而在服务端的OnTransact中则是处理这些请求。所以在Android Client空间就看到这个效果：只需要调用代理对象方法就达到了对远程服务的调用目的，实际上这个调用路径好长好长。
我们其实还一部分没有研究，就是同一个进程之间的对象传递与远程传递是区别的。同一个进程间专递服务地和对象，就没有代理BpBinder产生，而只是对象的直接应用了。应用程序并不知道数据是在同一进程间传递还是不同进程间传递，这个只有内核中的Binder知道，所以内核Binder驱动可以将Binder 对象数据类型从BINDER_TYPE_BINDER修改为BINDER_TYPE_HANDLE或者BINDER_TYPE_WEAK_HANDLE作为引用传递。
Android核心分析（07）----Service深入分析
上一章我们分析了Android IPC架构，知道了Android服务构建的一些基本理念和原理，本章我们将深入分析Android的服务。Android体系架构中三种意义上服务：
●Native服务
●Android服务
●Init空间的服务，主要是属性设置，这个ＩＰＣ是利用Ｓｏｃｋｅｔ来完成的，这个我将在另外
一章来讨论。
Navite服务，实际上就是指完全在C++空间完成的服务，主要是指系统一开始初始化，通过Init.rc脚本起来的服务，例如Service Manger service，Zygote service，Media service ，ril_demon service等。
Android服务是指在JVM空间完成的服务，虽然也要使用Navite上的框架，但是服务主体存在于Android空间。Android是二阶段初始（Init2）初始化时建立的服务。
1 Service本质结构
我们还是从Service的根本意义分析入手，服务的本质就是响应客户端请求。要提供服务，就必须建立接收请求，处理请求，应答客服端的框架。我想在Android Service设计者也会无时不刻把这个服务本质框图挂在脑海中。从程序的角度，服务一定要存在一个闭合循环框架和请求处理框架。
分析清楚服务框就必须弄清楚以下的机制及其构成。
（1）闭合循环结构放置在哪里？
（2）处理请求是如何分发和管理？
开机启动花了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;
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系统启动流程分析报告 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 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系统启动过程详解 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开机启动流程简单分析 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开机启动流程简介 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系统的开机画面显示过程分析 分类：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 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系统启动流程（一）解析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);
上文介绍了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 poweroff 流程详解 关机流程 android系统都有一个关机按键，长按这个按键系统会进行关机操作。具体实现流程如下： 在android层通过系统调用reboot（arg）调用内核中的sys_reb oot,具体流程如下： reboot——>sys_reb oot()——>kernel_power_off()——>machine_power_off()——>pm_power_off(); pm_power_off 是一个函数指针，他指向和具体硬件平台相关的关机操作函数。和sys_reboot相关的系统调用在source/kernel/sys.c中实现，然后在source/asm-arm/unistd.h中添加系统调用号。然后在source/arch/arm/kernel/entry-common.S中对sys_call_table(系统调用表)进行定义，具体的表在source/arch/arm/kernel/call.S 中实现。 Reboot流程 Linux下的关机和重启流程对于一般的桌面应用和网络服务器来说并不重要，但是在用户自己定义的嵌入式系统内核中就有一定的研究意义，通过了解Linux 关机重启的流程，我们对它可以修改和自定义，甚至以此为基础开发出全新的功能来。 1.概述 在linux下的关机和重启可能由两种行为引发，一是通过用户编程，一是系统自己产生的消息。用户和系统进行交互的方式也有两个，一个是系统调用：sys_reb oot，另一个就是apm或则acpi的设备文件，通过对其操作也可以使系统关机或者重启。 2.通过系统调用sys_reboot的重启 这个系统调用定义了一系列的MAGIC_NUMBER，在调用的开始部分首先检查MAGIC_NUMBER是否正确，只有正确才继续向下运行。在重启的时候转向分支 case LINUX_RE BOO T_CMD_RE ST ART: 首先使用notifier_call_chain向其它部分发出重启的消息，然后调用machine_restart函数完成重启。 machine_restart函数的开始部分有一段SMP相关的代码，主要完成多C PU时由一个C PU完成重启操作，其它C PU处于等待状态。之后系统根据一个变量reboot_thru_bios的内容判断重启方式，通过阅读reb oot_setu p我们可以得知，这个参数的内容是在系统启动时指定的，决定了是否利用bios，事实上是系统复位后的入口(FFFF：0000)地址的程序进行重启。在不通过bios进行重启的情况下，系统首先设定了重启标志，然后向端口0xfe写入数字0x64,这种重启的具体原理我还不大清楚，似乎是模拟了一次reset键的按下，希望大家和我讨论。在通过bios重启的情况下，系统同样先设定了重启模式，然后切换到了实模式，通过一条ljmp $0xffff,$0x0完成了重启。 3.通过系统调用sys_reboot进行关机 在系统调用的处理分支上，我们可以看到，首先同样是检查MAGIC_NUMBER，然后在case LINUX_R EBOOT_C MD_POWER_OFF的执行流程里面，又是使用notifier_call_chain发出了关闭计算机电源的消息，紧接着执行了machine_power_off 函数。我们machine_power_off函数中可以看到，如果pm_power_off这个函数指针不为空，那么系统就会通过调用这个函数进行关机。在apm已经加载的情况下(SMP除外)，实际上pm_power_off函数实际上指向了apm.c中的apm_power_off，在这个函数里系统通过apm_info结构里的值，使用切换到实模式关机，或者使用
Android usb流程分析 文档以UMS（usb mass storage）为例来分析流程，主要按照图中红线来分析（即从插入USB 开始到状态栏弹框，然后又从选择UMS功能开始往下的流程）。以前没有看过USB相关代码，网上也很少有分析usb FRAMEWORK相关的东西，文档中可能存在错误，如果发现欢迎指正。 总体框图 1.Kernel USB 流程 LINUX KERNEL GADGET 架构 Linux USB Gadget分三层架构，层次关系从上到下 一层：USB Gadget功能层。BSP/Driver开发者通常是要实现这一层，从而实现一个具体的设备驱动，如Anddroid在此层实现了adb，mtp，mass_storage等。浏览参考关注此层代码时，会发现“composite”是此层的关键字，此层中关键的数据结构是：struct usb_composite_driver。这一层的驱动文件一般为：driver/usb/gadget/android.c （android实现的）或driver/usb/gadget/serial.c（传统Linux实现的USB转串口）。 二层：USB设备层（usb core）。这一层是Linux内核开发维护者实现的，与我们没太大关系，不用我们操心，我们只关心其的一些接口就行。浏览参考关注此层时，会发现“gadget”是此层的关键字，此层的关键数据结构是：usb_gadget_driver,usb_composite_dev。 这层主要的一个驱动文件为：driver/usb/gadget/composite.c 三层：USB设备控制器驱动层。这一层主要是与CPU、CPU USB控制器有关，与硬件紧密相关，主要它和USB控制器牵扯在一起，涉及有寄存器、时钟、DMA等等。但是这一层往往是由芯片厂商去实现。我们一般仅需在板级文件中处理好所需要的USB接口即
在前面一篇文章中，我们分析了Android系统在启动时安装应用程序的过程，这些应用程序安装好之后，还需要有一个Home应用程序来负责把它们在桌面上展示出来，在Android系统中，这个默认的Home 应用程序就是Launcher了，本文将详细分析Launcher应用程序的启动过程。 Android系统的Home应用程序Launcher是由ActivityManagerService启动的，而ActivityManagerService和PackageManagerService一样，都是在开机时由SystemServer组件启动的，SystemServer组件首先是启动ePackageManagerServic，由它来负责安装系统的应用程序，具体可以参考前面一篇文章Android应用程序安装过程源代码分析，系统中的应用程序安装好了以后，SystemServer 组件接下来就要通过ActivityManagerService来启动Home应用程序Launcher了，Launcher在启动的时候便会通过PackageManagerServic把系统中已经安装好的应用程序以快捷图标的形式展示在桌面上，这样用户就可以使用这些应用程序了，整个过程如下图所示：
点击查看大图下面详细分析每一个步骤。 Step 1. SystemServer.main
这个函数定义在frameworks/base/services/java/com/android/server/SystemServer.java文件中，具体可以参考前面一篇文章Android应用程序安装过程源代码分析的Step 1。 Step 2. SystemServer.init1 这个函数是一个JNI方法，实现 在 frameworks/base/services/jni/com_android_server_SystemServer.cpp文件中，具体可以参考前面一篇文章Android应用程序安装过程源代码分析的Step 2。 Step 3. libsystem_server.system_init 函数system_init实现在libsystem_server库中，源代码位于 frameworks/base/cmds/system_server/library/system_init.cpp文件中，具体可以参考前面一篇文章Android应用程序安装过程源代码分析的Step 3。 Step 4. AndroidRuntime.callStatic 这个函数定义在frameworks/base/core/jni/AndroidRuntime.cpp文件中，具体可以参考前面一篇文章Android应用程序安装过程源代码分析的Step 4。 Step 5. SystemServer.init2 这个函数定义在frameworks/base/services/java/com/android/server/SystemServer.java文件中，具体可以参考前面一篇文章Android应用程序安装过程源代码分析的Step 5。 Step 6. ServerThread.run 这个函数定义在frameworks/base/services/java/com/android/server/SystemServer.java文件中，具体可以参考前面一篇文章Android应用程序安装过程源代码分析的Step 6。 Step 7. ActivityManagerService.main 这个函数定义在 frameworks/base/services/java/com/android/server/am/ActivityManagerServcie.java文件中： view plain 1.public final class ActivityManagerService extends ActivityManagerNative 2.implements Watchdog.Monitor, BatteryStatsImpl.BatteryCallback { 3. ...... 4. 5.public static final Context main(int factoryTest) { 6. AThread thr = new AThread(); 7. thr.start(); 8. 9.synchronized (thr) { 10.while (thr.mService == null) { 11.try { 12. thr.wait(); 13. } catch (InterruptedException e) { 14. } 15. } 16. } 17. 18. ActivityManagerService m = thr.mService; 19. mSelf = m;