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 。 源码位

一、AMS.systemReady 桌面启动请求由 AMS 在 systemReady 里发出( frameworks/base/services/core/java/com/android/server/am/ActivityManagerService.java 第 11810 行附近)： startHomeActivityLocked 做的事分三件： 拼home intent、让 PMS 解

素材来源于“AMS 的启动过程分析”“PMS 的启动过程分析”“安装包的解析过程分析”三段视频。 一、system_server 应用进程里的 Application.onCreate 已经处于启动链后段。此时系统早已知道包名对应哪个 UID、入口 Activity 是谁、它声明了哪些 intent-filter。这些数据若到 startActivity 时才从 APK 临时读取，每次组件解析