本文整理自 corpus 仓库中的以下三集课程： 本文源码基准为 AOSP android-6.0.0_r1。一次 ContentResolver.insert 看上去是普通的方法调用，开始数据操作前，客户端却要先取得一个 IContentProvider。这个接口可能指向本进程对象，也可能是另一个进程中 ContentProvider 的 Binder 代理。 代理的取得过程由客户端两级缓存

一次 bindService 会跨过客户端、systemserver 和 Service 进程。Java 层传出的对象先写成传输结构，Binder 驱动再为目标进程建立引用。客户端提交的是 BINDERTYPEBINDER，其中保存对象地址与 cookie；驱动为目标进程建立 binderref、分配 handle，接收方此后凭 handle 发起调用。回调返回原进程时，cookie 保存的本进程

startService 和 bindService 表面上对应两套 API，进入 Framework 后却共享了大半条启动链。两者都从调用方进程进入 ContextImpl，经 Binder 到达 system_server 中的 ActivityManagerService（下文简称 AMS），由 ActiveServices 查找或创建 ServiceRecord，再把生命周期调用投

本文依据 corpus 仓库中的四段录屏整理，内容覆盖桌面入口、前一个 Activity 的暂停、目标进程判定，以及新 Activity 的创建与显示。 上一篇《Android-Framework（十五）-进程的 fork 创建过程》已经分析 startSpecificActivityLocked 到 Zygote fork、ActivityThread.main 、attachApplic

一、启动 Activity 时，进程不存在会发生什么 ActivityStackSupervisor.startSpecificActivityLocked 以进程名和 uid 查询 ProcessRecord。记录存在且 app.thread 已绑定时，AMS 可以直接调用 realStartActivityLocked ,其余情况会进入 startProcessLocked 。 源码位

本文探讨的问题是：用户在文件管理器中点开一个 APK 后，系统怎样把它放进 /data/app、解析包信息，并把安装结果送回界面？从源码看，这条链横跨 PackageInstaller 应用进程、system_server 和 com.android.defcontainer 三个进程。 一、安装入口：点开 APK 后系统处理了什么 1.1 确认界面属于 PackageInstaller 文件管理

素材来源：sanyinchen/corpus 仓库，资料整理自哔哩哔哩 Android Binder 源码教程。 一、一次 startActivity 包含两次 Binder 通信 旧版 Android Framework 中，Activity.startActivityForResult 会经 Instrumentation.execStartActivity 触发这类调用： 这一行发生

视频素材：[01.驱动层单向通信流程回顾] App 调用 startActivity 时，代码里那个看似普通的 getDefault ，到底怎样找到另一个进程里的 ActivityManagerService（下文简称 AMS）？ 答案不是“Binder 帮我们找到了”这么简单。沿调用栈往下走，会看到一次查询如何穿过 Java、native 和驱动，再原路带回一个 handle。 而且这里其