第1 章 搭建Android 源码工作环境
1.1 Android 系统架构
1.2 搭建开发环境
1.2.1 下载源码
//http://source.android.com/source/downloading.html。
1.2.2 编译源码
1. 部署JDK
2. 编译源码
1.2.3 利用Eclipse 调试system_process
1. 配置Eclipse
2. 使用Coffee Bytes Java 插件
3. 导入Android 源码
4. 创建并运行模拟器
5. 调试system_process
第2 章 深入理解Java Binder 和MessageQueue
2.1 概述
2.2 Java 层中的Binder 架构分析//建议先阅读读卷I 的“第6 章深入理解Binder”。
2.2.1 Binder 架构总览:
1)系统定义了一个IBinder 接口类以及DeathRecipient 接口
2)Binder 类和BinderProxy 类分别实现了IBinder ❑ 接口。其中，Binder 类作为服务端的Bn 的代表，而BinderProxy 作为客户端的Bp 的代表。
3)系统中还定义了一个BinderInternal 类。该类是一个仅供Binder 架构使用的类。它内部有一个GcWatcher 类，该类专门用于处理和Binder 架构相关的垃圾回收
4)Java 层同样提供一个用于承载通信数据的Parcel 类
2.2.2 初始化Java 层Binder 框架
frameworks/base/core/jni/android_util_Binder.cpp
(1) Binder类的初始化.
(2) BinderInternal类的初始化
(3) BinderProxy类的初始化
主要是注册一些class 的JNI,全局对象变量.
2.2.3 addService实列分析//ActivityManagerService
(1) 在SM 注册服务:
BinderInternal.getContextObject
1:通过JNI 创建BpProxy,与ServiceManager联系.
2:转化成java层的class BinderProxy obj.
3:通过asinterface传给 class ServiceManagerProxy类的remote=BinderProxy
(2) addService函数分析://即 调用BinderProxy. addService
BinderProxy. addService是native transact函数.
调用target是JAVA层BinderProxy 创建的BpBinder
(3) Binder,JavaBBinderHolder和JavaBBinder
1:Binder的mobject 指向JavaBBinderHolder对象
2: JavaBBinderHolder的mBinder指向JavaBBinder
3: JavaBBinder的mobject指向Binder 对象.
通过ServiceManagerProxy->addService中的data->writestrongBinder(Service)中的ibinderforJavaObject中JavaBBinderholder->get
4: ActivityManagerService响应请求流程//JavaBBinder的业务函数.
虚线表示子类重载实现.Q:响应的指令从哪里来?
2.2.4 Java 层Binder 架构总结
2.3 心系两界的MessageQueue//卷I“第5 章深入理解常见类
2.3.1 MessageQueue 的创建:
MessageQueue.java::MessageQueue
通过JNI调用Native中的 new MessageQueue
2.3.2 Java层投递Message:
MessageQueue.java::enqueueMessage()
nativeWake 控制是否唤醒
2.3.3 MessageQueue 提取消息:
MessageQueue.java::next()
通过JNI调用Native中nativePollOnce
2.3.4 nativePollOnce 函数分析//实际就是一个多路复用IO epoll
1: 计算真正等待的时间
2:调用 epoll_wait
3:处理文件句柄,或fd 发生的事情
4:调用native Message处理函数,处理response数组中callback函数.
2.3.5 添加监控请求:
2.3.6 处理监控请求:
nativePollOnce中:
3:处理文件句柄,或fd 发生的事情
4:调用native Message处理函数,处理response数组中callback函数.
2.3.6 native层sendMessage:
2.4 MessageQueue 总结
2.4.1 消息处理的大家族合照
(1): Java 层提供了Looper 类和MessageQueue 类❑ ，其中Looper 类提供循环处理消息的机制，MessageQueue 类提供一个消息队 列，以及插入、删除和提取消息的函数接口。另外，Handler 也是在Java 层常用的与消息处理相关的类。
(2): MessageQueue 内部通过mPtr 变量保存一个Native 层的NativeMessageQueue ❑ 对象,mMessages 保存来自Java 层的Message 消 息。
(3): NativeMessageQueue 保存一个native 的Looper 对象， 该Looper 从ALooper 派生，提供pollOnce 和addFd 等函数
(4): Java 层有Message 类和Handler 类， 而Native 层对应也有Message 类和Message-Handler 抽象类。
在编码时，一般使用的是MessageHandler 的派生类WeakMessage-Handler 类
2.4.2 MessageQueue 处理流程总结
(1): MessageQueue 支持Native/Java 的Message
(2): MessageQueue 代表是NativeMessageQueue ,MessageHander来处理Message,addfd 来添加Request
(3): 先处理Native的Message,后处理Native的Request,再处理Java的Message
2.5 本章小结
第3 章 深入理解SystemServer
3.1 概述
3.2 SystemServer分析//卷I第4章 深入理解Zygote
3.3 EntropyService分析
3.4 DropBoxManagerService分析
3.4.1. DBMS构造函数的分析
3.4.2. dropbox日志文件的添加
3.4.2. DBMS和setting数据库
3.5 DiskstatusService和DevicestorageMonitorService分析
3.5.1. DiskStatusServicef分析
3.4.1. DeviceStorageManagerService分析
3.6 SamplingProfilerService分析:
3.6 ClipboardService分析:
第4章 深入理解PackageManagerService
4.1 概述
1)IPackageManager接口定义服务端和客户端通信的业务函数,还定义内部类stub,该类从Binder派生并实现IPackageManager接口.
2)Packagemanagerservice继承自IPackageManager.stub类,作为 PackageManagerservice服务端.
3)Stub 类定义一个类Proxy,成员mRemote作为PackageManagerservice客户端.
4)IpackageManager接口类定义了许多业务函数,
5)ApplicationpackageManager继承IpackageManager
4.2 初识packageManagerService
4.3 PKMS的main函数分析
4.3.1 扫描并解析XML文件,并将其中的信息保存到特定的数据结构(Setting类)中.
(1)Setting.类,
1.shareduserSetting派生GrantedPermissions,其中Packages,保存申明sharedUserID 的package权限的设置信息.
2.mUserIds,mOtherUserIDs,其目的是以UID为索引快速sharedUserSetting 对象.
(2)AndroidManifest.xml 中sharedUserID ,相同的值share彼此数据,赋予进程对应的权限
(3) XML文件扫描:
1.通过readPermission从X)从./system/etc/permission 读取*.xml权限.转换成对应的数据结构
/data/system/下三个.xlm文件
packages.xm描述系统安装的package 信息,
package-stopped-backup.xlm强制停止运行的package的信息.
package.list,应用级别的package的信息
2.readLPw函数
4.3.2 扫描APK文件,
(1)didDexOpt 变量,控制系统库的优化
(2)扫描系统Package :
通过liunx inotify 机制监听文件夹是否有变化.
scanDirlI函数中call packageParser 类分析.APK建立package类对象数据结构(图4-6),流程请参考图4-8,得到图4-9 共有数据结构
4.3.3 整理4.3.2 的信息,将信息保存到文件中.
4.4 APK Installation 分析
4.4.1 adb install分析:
第一步:#adb install XXX.apk,直接是通过adb 命令(commandline.c),调用install_app,call do_sync_push 把apk copy到对应的位置.再call pm_command
第二步:pm实际是通过shell 调用脚本,用app_process起pm 进程.pm进程通过Binder客户端调用PKMS
第三步:PKMS通过sendmessage 给mHandler处理
第四部:mHandler处理INIT_copy和MSC_BOUND,调用HandlerParam,startcopy installArgs,不同安装行为call 不同的HandlerParam的子类.如Installparams,MoveParames,
measureparams,intallargs ,的Fileinstallars,Sdinstallargs.
第五步:handleStartcopy 通过IBinder call defaultContainerService
第六步:最后call hanleReturnCode
4.4.5 verification 的工作主要installParams中Handlestartcopy中
4.5 queryIntentActivities分析
4.5.1 Intent/Intentfilter
4.5.2 Activity信息管理.
(1)mActivities 为activityintentResolverl类型,保存系统所有与activity相关的信息.
(2)从apk中解析得到的所有和activity相关的信息,都有packageParser.activity来保存.
(3)其他mSchemeToFilter,mActionfilter,mTypedActionToFilter,mFilter,mWildTypeToFitler,mTpyeFilter,mBaseTypeToFilter.
4.5.2 Intent 匹配信息查询.
(1)queryIntentActivities 查询.
4.6 installd及UserMananger分析
4.6.1 installd 介绍
(1) install.java通过socket 调用installd,
(2) PKMS中用的命令:dexopt,movefiles, dofreecash.
4.6.1 UserManager 介绍
第5章 深入理解PowerManagerService
第6 章 深入理解ActivityManagerService / 184
6.1 概述
(1): 由ActivityManagerNative类派生,并实现watchdog Monitor和BatteryStatusimpl.batterycallbcak接口,而ActivityManagerNative由Binder派生,实现了IActivityManager接口.
(2): 客户端使用ActivityManager类,通过调用getDefault得到ActivityManagerproxy.与AMS通信.
6.2 初识ActivityManagerService //以system_server 调用AMS 的流程分析
6.2.1 ActivityManagerService的main函数分析
(1): 创建一个带消息处理AThread,构造函数AMS.
其中AMS 构造函数主要
a:创建BSS,USS,mProcessstatus,mProcessStateThread线程统计系统的运行状况.
b:赋值CompatModePackages,configuration
(2): 调用ActivityThread.systemMain ,构造ActivityThread函数.//system_server 是一个特殊的应用进程
a:通过ActivityThread.attach()true/false来区分,是系统线程/和应用进程
b:引出Instrumentation类,application 类context类.
c: ContextImpl与其他类之间的关系如下图:
(3): 调用at.getSystemContext.得到system context
(4): 调用ActivityManagerService.startRuning()
总结:ActivityManagerService的main函数主要得到两个对象ActivityThread,contextImpl
其中的关键变量Activity中几个hashMap
6.2.2 ActivityManagerService 的setSystemProcess的分析
(1): ActivityThread 的installSystemApplication函数.
通过loadapk 第四个参数 info 传入到context.init(),将context与systemapplication即framework-res.apk绑定.
(2): ProcessRecord 和IApplicationThread.
1: IApplicationThread
Q:AMS 怎样与应用进程交互
A:如下图,通过Activitythread中mAppThread Binder通信实现,其中IApplicationThread Bn(服务端)在应该程序端实现,(通过extend ApplicationthreadNative)
2 通过newProcessRecordLocked创建ProcessRecord 类,
其中几个关键的成员变量是:
info保存Applicationinfo,
thread保存IApplicationthread与进程交互.
AMS通过mPidSelfLocked和mProcessName 来操作ProcessRecord.
总结:1: 增加一些服务.2.把system_server进程加入AMS 管理.
6.2.3 InstallSystemProvider函数分析.
(1): generateApplicationproviderLocked分析.
通过PKMS查询provider,而AMS通过mProviderByClass,ProcessRecord通过pubprovider操作ContentproviderRecord来维护.
(2): Activitythread 中installSystemProvider分析.
1: installProvider分析:在Activitythread安装provider,最后得到如下数据结构:
其中ProviderClientRecord是Activity thread中 provider的记录,mName 是contentprovider的authority
2: publishContentprovider
通过PID 找到ProcessRecord,通过其pubProvider找到ContentProviderRecord
以componetName/authority为key 保存到Content provider到AMS中.
(3): 建立SettingProvider的检测.
6.2.4 SystemReady函数分析.
(1): 第一阶段:发送处理与PRE_BOOT_COMPLETED广播相关的事情.主要和系统升级有关系.
(2): 第二阶段:杀死在AMS未启动前已经启动的应用进程,从Setting数据库中获取配置信息.
(3)第三阶段: 调用goingCallback run函数.启动persistent apk.和桌面,
6.3 StartActivity分析
6.3.1 am 介绍
usage: am [subcommand] [options]
usage: am start [-D] [-W] [-P <FILE>] [--start-profiler <FILE>]
[--R COUNT] [-S] [--opengl-trace]
[--user <USER_ID> | current] <INTENT>
am startservice [--user <USER_ID> | current] <INTENT>
am force-stop [--user <USER_ID> | all | current] <PACKAGE>
am kill [--user <USER_ID> | all | current] <PACKAGE>
am kill-all
am broadcast [--user <USER_ID> | all | current] <INTENT>
am instrument [-r] [-e <NAME> <VALUE>] [-p <FILE>] [-w]
[--user <USER_ID> | current]
[--no-window-animation] <COMPONENT>
am profile start [--user <USER_ID> current] <PROCESS> <FILE>
am profile stop [--user <USER_ID> current] [<PROCESS>]
am dumpheap [--user <USER_ID> current] [-n] <PROCESS> <FILE>
am set-debug-app [-w] [--persistent] <PACKAGE>
am clear-debug-app
am monitor [--gdb <port>]
am screen-compat [on|off] <PACKAGE>
am display-size [reset|WxH]
am display-density [reset|DENSITY]
am to-uri [INTENT]
am to-intent-uri [INTENT]
am switch-user <USER_ID>
am stop-user <USER_ID>
6.3.2 前半程图:从am 启动一个Activity分析
6.3.2.1 AMS的startActivityAndWait 分析.
(1): 基础知识的准备:
1: Activitystack 管理activity和 task.
>一件事情称为一个task,一个task可以细分很多子步骤即Activity.
>activity由ActivityRecord表示,task由TaskRecord 表示.ActivityRecord的task指向Activity所在task.
2:activitystack.java中常用操作ActivityRecord的函数.
>topRunningActivityLocked
>topRunningNonDelayActivityLocked
>findActivitylocked
>findTaskLocked
3 launch mode 控制Activity与Task的方式:standard/singletop/singletask/singleinstance
(2): Activitystack 中startActivityAndWait分析
主要做的事情:
1 :前期准备工作,通过PKMS查询该Intent的Activityinfo,处理FLAG_CANT_SAVE_STATE,的process,获取call pid /uid
2 : call startActivityLocked
3: 后期,处理返回值.
6.3.2.2 startActivityLocked分析.
(1): 处理sourceRecord,resultRecord
(2): 处理APP switch
(3): 调用startActivityUncheckedLocked 处理Activity
6.3.2.3 startActivityUncheckedLocked 分析
(1): 为新的activity创建一个task,即,是否设置FLAG_ACTIVITY_NEW_TASK
(2): 在mHistory找到一个合适的task.
(3): 调用startActivityLocked.即call resumeTopActivitylocked
6.3.2.4resumeTopActivitylocked 分析
(1): 如果mResumeActivity 不为空,pause Activity,再重新启动.
(2): 调用startspecificActivityLocked
6.3.2.5 startspecificActivityLocked 分析
(1):调用startProcessLocked
6.3.2.6 startProcessLocked分析
(1) :处理后台进程FLAG_FROM_BACKGROUND
(2): 处理mBadProcesses
(3): 调用startProcessLocked
6.3.2.7另外一个startProcessLocked分析
(1) 向Zygote发送不带任何信息消息,启动一个字进程.
(2) 发送超时处理信息.
6.3.3 后半程图:从Activitythread运行Activity分析
6.3.3.1 Activitythread main函数分析
attach函数主要是把Application与thread 绑定在一起.主要call attachApplicationLocked
6.3.3.2 attachApplicationLocked 分析
(1): 设置进程ProcessRecord 对象的成员变量,
(2) :撤销PROC_START_TIMEOUT_MSG
(3):调用thread.bindApplication
(4): 启动应用进程Activity(mMainStack.realStartActivityLocked),Service,等组件.
6.3.3.3 Application thread的bindApplication分析//Activity的 create分析
(1):Activity thread接受AMS 的指令后,封装成一个数据结构发送 BIND_APPLICATION 消息
(2) Activity thread 接到 BIND_APPLICATION消息后 call handleBindApplication
(3) 创建Application对象,安装Contentprovider,调用Application的onCreate
6.3.3.4 Activity stack realStartActivityLocked 分析//Activity的 start分析
(1):调用Activity与应用进程的交互scheduleLaunchActivity:
向Activity thread 发送LAUNCH_ACTIVITY消息,
即call HandleLauchActivity;
1:以java 反射机制通过performLaunchActivity创建Activity
2: handleResumeActivity
new Idler();call ActivityIdle 中的ActivityIdleInternal
(2):调用completeResumeLocked
AMS 给10s ,10s后AMS 与应用进程需要交互.
6.3.3.5 ActivityIdleInternal 分析
1: 被暂停的Activity处于finish状态,call finishCurrentActivityLocked
2: 否则,call stopActivityLocked
6.3.3.6 startPausingLocked 分析// Activity的 pause分析
1: 主要call schedulePauseActivity 通过发Message 最终call handlePauseActivity
2: 设置超时时间 500ms
->handlePauseActivity 分析
1: 实现performPauseActivity
2:告诉 AMS Pauseed. ActivityPaused
->AMS ActivityPaused分析
1: 设置paused 标识
2: call completePauseLocked
6.3.3.7 stopActivityLocked 分析// Activity的 stop分析
1: 设置paused 标识
2: call scheduleStopActivity 发送 STOP_ACTIVITY_SHOW/STOP_ACTIVITY_HIDE call handleStopActivity
->handleStopActivity
1: call performStopActivityInner
6.4 Broadcast和broadcastReceiver分析
Q: 什么是java反射机制.
A:
broadcast 发送的方式:(1) 普通模式 Sendbroadcast,(2) 串行模式,SendOrdedBroadcast,(3) sticky 模式.sendstickyBroadcast
6.4.1 registerReceiver流程分析.
ContextImpl.java 中 registerReceiver
1: 第一部分IIntentReceiver 准备:
2: 在AMS registerReceiver
(1) 第一步准备stick 和filter,建立mRegisterdReceivers, mReceiverResolver.
(2)为每一个满足IntentFilter的sticky的Intent创建一个BroadcastRecord对象,并保存在mParllelBroadcasts中,等待调度向AMS 发送广播.
6.4.2 SendBroadcast流程分析
ContextImpl.java 中 SendBroadcast-->AMS中BroadcastIntent-->BroadcastIntentlocked-->sheduleBroadcastLocked.
1:BroadcastIntentlocked
第一部分: 处理一份特殊Broadcast.
第二部分: 查询满足条件的动态广播接受者及静态广播接受者,非order 尽快发送出去. 非order的Broadcast都被保存在mParallelBroadcast
中.
第三部分:动态注册者,静态注册者都合并到Receivers中,把Broadcast保存在mOrderBroadcast中,
6.4.3 Broadcast_Intent_msg消息处理函数.
6.4.4 应用程序处理broadcast 分析:
6.4.5 广播处理总结:
6.5 StartService分析:
6.5.1 Service知识介绍:
1: 响应Client的请求方式:
(1) 借道Intent来,传递请求.server在OnStartCommand接到Intent.并处理.
(2) 借助调用BinderService和Service建立Binder关系得到Bp 端.
6.5.2 StartService的流程图
6.6 AMS 中的进程管理:
6.6.1 Linux进程管理介绍
(1): 设置调度的优先级
int setpriority(int which,int who init prio)
(2): 设置调度策略
init setscheduler(pit_t pid,int policy const struct sched_param *param)
(3):调整进程OOM_adj值(out of memeroy adjust).
主要设置/sys/module/lowmemeroykiller/parameters/minfree 和/sys/module/lowmemeroykiller/parameters/adj
6.6.2 Android进程管理介绍
1: 应用进程的分类: forground类,visable类,Service类,background类,empty类
2: Process.java
setThreadPriority()
setThreadgroup()
setProcessgroup()
setOomAdj()
3:Processlist类,主要定义不同状态下oom_adj值.
ProcessRecord,定义的变量用来进程管理.
6.6.3 AMS 进程管理函数分析
attachApplicationLocked中
1: updateLruProcessLocked函数分析//根据Lru值调用app 在mLruProcess数组中.
2: updateOomAdjLocked函数分析
4: computeOomAdjLocked 分析
6.7 APP的 crash 处理
6.7.1 应用测试的crash处理
zygoteInit--->commonInit--->setdefaultUncaughtexceptionHandler-->handleApplicationCrash
6.7.2 AMS的handleApplicationCrash
handleApplicationCrash--->crashApplication--->makeappCrashingLocked--->handleappCrashLocked
6.7.3 AppdeathRecipient中BinderDied
BinderDied-->appDiedLocked-->HandleappDiedLocked-->cleanupApplicationRecordLocked-->killServiceLocked
(1): cleanupApplicationRecordLocked分析
第一部分: killServiceLocked
第二部分: 处理Content provider
第三部分: 处理Receiver
第四部分: 处理Backup 信息
6.8 本章学习指导
6.9 本章小结
第7章 深入理解ContentProvider
第8章 深入理解ContentServer 和AccountManagerService