Android 系统层扫盲 03：第一次看 AOSP 源码目录，frameworks、system、packages、hardware 都是干什么的？

上一篇我们已经搞清楚了：

复制代码

Git
↓
管理一个仓库

Repo
↓
管理一组 Git 仓库

Manifest
↓
描述这一组仓库

当我们真正执行：

复制代码

repo sync

把 AOSP 源码拉下来以后，会遇到下一个非常现实的问题：

这么大一堆源码，我到底该看哪里？

第一次打开 AOSP 根目录，经常会看到类似：

复制代码

aosp/
├── art/
├── bionic/
├── bootable/
├── build/
├── device/
├── external/
├── frameworks/
├── hardware/
├── packages/
├── system/
├── tools/
├── vendor/
└── ...

对于一直做 Android App 的开发者来说，很容易产生一种感觉：

这到底都是啥？

这一篇不研究具体源码。

我们只做一件事：

先给 AOSP 源码目录建立一张地图。

以后看到一个类、一个模块、一个系统问题，至少知道大概应该去哪个区域找。

一、先建立一个最重要的认识

AOSP 根目录并不是按照：

复制代码

Java
Kotlin
C++
XML

这种编程语言划分的。

它更多是按照：

复制代码

系统职责
模块
平台组件
设备
构建系统
运行时
硬件接口

来组织。

所以你第一次看 AOSP 时，不要想着：

Java 代码在哪？

C++ 代码在哪？

更应该问：

我要看的东西属于 Android 系统的哪一部分？

例如：

复制代码

ActivityManagerService

属于 Framework/System Service。

那就往：

复制代码

frameworks/

方向找。

如果你研究：

复制代码

init

它更偏系统底层。

那可能就会进入：

复制代码

system/

如果研究：

复制代码

Settings

这种系统应用，就可能进入：

复制代码

packages/

所以：

先判断模块，再找目录。

这比死记目录重要得多。

二、第一阶段最值得认识哪些目录？

AOSP 根目录很多。

但扫盲阶段其实不用全学。

我建议先认识这几个：

复制代码

frameworks/
packages/
system/
hardware/
device/
build/
art/
bionic/
external/
vendor/

可以先粗暴地记成：

复制代码

frameworks
↓
Android Framework 核心

packages
↓
大量系统 App / 系统模块

system
↓
系统底层核心组件

hardware
↓
硬件接口 / HAL 相关

device
↓
具体设备配置

build
↓
Android 构建系统

art
↓
Android Runtime

bionic
↓
Android C 库

external
↓
外部开源项目

vendor
↓
厂商代码

目前记住这张表，就已经够用了。

下面一个一个看。

三、frameworks：Android Framework 的核心区域

对于 Android App 开发者来说：

复制代码

frameworks/

应该是以后最熟悉的目录之一。

尤其是：

复制代码

frameworks/base

Google 官方源码仓库直接把 frameworks/base 描述为：

Android framework classes and services。

也就是 Android Framework 的大量核心类和系统服务都在这里。

你以后会频繁看到：

复制代码

frameworks/base/

里面大致会出现：

复制代码

core/
services/
packages/
cmds/
libs/
media/
graphics/
...

第一阶段不用全记。

只需要先认识三个区域。

四、frameworks/base/core：App 开发者熟悉的 API 世界

例如：

复制代码

frameworks/base/core/

这里包含大量 Android Framework 核心代码。

你平时 App 开发里熟悉的：

复制代码

Activity
Context
Intent
View
Window
Handler
Looper
Binder
Parcel

很多都和这里密切相关。

以后你可能会看到类似路径：

复制代码

frameworks/base/core/java/android/app/
frameworks/base/core/java/android/content/
frameworks/base/core/java/android/os/
frameworks/base/core/java/android/view/

是不是突然熟悉起来了？

因为包名就是：

复制代码

android.app
android.content
android.os
android.view

这正是我们平时写 App 时使用的：

复制代码

import android.app.Activity
import android.content.Context
import android.os.Bundle
import android.view.View

所以你可以先形成一个非常重要的认识：

*我们 App 里天天调用的很多 android. API，本身就能在 AOSP Framework 源码里找到。**

五、frameworks/base/services：系统服务的大本营之一

再看：

复制代码

frameworks/base/services/

这里对以后 Framework 学习非常重要。

因为我们后面会学习大量：

复制代码

AMS
ATMS
WMS
PMS
PowerManagerService
InputManagerService
...

这些 Android 核心系统服务。

很多系统服务代码就在：

复制代码

frameworks/base/services/

下面。

例如以后可能会进入：

复制代码

frameworks/base/services/core/java/com/android/server/

看到大量：

复制代码

xxxService

类。

所以可以简单记：

复制代码

frameworks/base/core
↓
Framework API

frameworks/base/services
↓
Framework 背后的大量 System Service

这两个关系非常重要。

六、这其实对应我们之前讲的两层

例如 App 写：

复制代码

getSystemService(...)

或者：

复制代码

startActivity(...)

表面是在使用：

复制代码

Framework API

这些代码很多在：

复制代码

frameworks/base/core

而背后真正执行系统级管理工作的 Service，则可能位于：

复制代码

frameworks/base/services

所以以后你会慢慢形成：

复制代码

App
 ↓
frameworks/base/core
 ↓
Binder
 ↓
frameworks/base/services

这种感觉。

当然这只是极度简化的理解。

第一阶段够用了。

七、frameworks/base/packages：SystemUI 也在这里

这里有一个很容易误解的点。

前面我们说：

复制代码

packages/

里面有系统 App。

但：

复制代码

frameworks/base/packages/

里面同样也存在重要系统组件。

最典型的就是：

复制代码

frameworks/base/packages/SystemUI

当前 AOSP 源码中，SystemUI 仍然位于 frameworks/base/packages/SystemUI。它负责状态栏、通知区域、系统导航等大量系统 UI，官方源码中的描述非常形象：

"Everything you see in Android that's not an app"。

同时 SystemUI 是一个独立于 system_server 的常驻进程。

所以以后如果你做：

复制代码

状态栏
导航栏
锁屏
通知面板
Quick Settings

很可能会接触：

复制代码

SystemUI

八、所以 frameworks 先这样记

先压缩成：

复制代码

frameworks/base
│
├── core
│    ↓
│  Framework API
│
├── services
│    ↓
│  System Services
│
└── packages
     ↓
   SystemUI 等系统组件

第一阶段能理解这个已经非常够用了。

九、packages：大量系统 App 和模块

接下来：

复制代码

packages/

这个名字对 App 开发者也比较好理解：

Android 系统自带的各种 Package。

例如经典的：

复制代码

packages/apps/Settings

就是：

复制代码

设置 App

Google 官方 AOSP 仓库中也可以直接看到：

复制代码

platform/packages/apps/Settings

这个独立 Git 项目。

甚至打开 Settings 源码以后，你还能看到：

复制代码

bluetooth
display
location
applications
deviceinfo
notification
wifi
...

这些我们手机设置里非常熟悉的功能模块。

十、Android 系统里面其实也有很多"App"

这个概念一定要建立起来。

我们平时说：

复制代码

Android App

很容易只想到：

复制代码

微信
支付宝
自己的业务 App

其实 Android 系统本身也包含很多 APK / App 形态的组件。

例如：

复制代码

Settings
Launcher
部分系统工具
系统配置界面

它们本质上也可能：

复制代码

有 AndroidManifest.xml
有 Activity
有 Service
有资源文件

只是它们：

属于系统源码的一部分。

例如 packages/apps/Settings 本身就是一个系统应用源码项目。

所以以后不要觉得：

系统层里面怎么还能看到 AndroidManifest.xml？

完全正常。

因为：

复制代码

AOSP

里面本来就包含很多系统 App。

十一、frameworks 和 packages 怎么区分？

第一阶段可以粗略这么理解：

复制代码

frameworks
↓
Android 平台能力 / Framework / System Service


packages
↓
很多建立在这些平台能力之上的系统应用和模块

例如：

复制代码

ActivityManagerService

不是普通 App 功能。

它属于 Android 核心 Framework/System Service。

所以去：

复制代码

frameworks/

而：

复制代码

Settings

更像一个真正的 Android 系统应用。

所以在：

复制代码

packages/apps/Settings

十二、system：Android 更底层的系统核心组件

再往下看：

复制代码

system/

这里开始逐渐远离普通 App 开发。

例如：

复制代码

system/core

官方源码仓库对 platform/system/core 的描述是：

minimal bootable environment。

也就是 Android 基础启动和系统环境相关的核心区域之一。

以后可能会在这里接触到：

复制代码

init
adb
log
fs_mgr
libutils
libprocessgroup
...

不同 Android 版本的具体组织会变化，但整体理解可以先保持：

system 更偏 Android 系统底层基础组件。

十三、frameworks 和 system 的感觉有什么区别？

非常粗略地类比：

复制代码

frameworks
↓
更靠近 Android Framework / Java 世界

system
↓
更靠近 Android 系统基础设施 / Native / Linux 世界

例如：

复制代码

Activity
Context
AMS
WMS

你会更多想到：

复制代码

frameworks

而：

复制代码

init
adb
文件系统挂载
底层系统工具

则会更多想到：

复制代码

system

当然边界绝对不是这么简单。

这里只是帮助第一阶段建立方向感。

十四、hardware：硬件抽象相关

接下来：

复制代码

hardware/

看到这个名字，基本就知道开始往硬件方向靠了。

例如：

复制代码

hardware/interfaces

就是 AOSP 中非常重要的硬件接口项目。

Google 官方当前源码中依然存在：

复制代码

platform/hardware/interfaces

这个独立项目。

以后我们学习：

复制代码

Camera
Audio
Sensor
Bluetooth
Power
Health
USB

等硬件能力时，经常会碰到：

复制代码

HAL

也就是：

复制代码

Hardware Abstraction Layer

硬件抽象层。

第一阶段可以理解：

复制代码

Framework
    ↓
hardware / HAL
    ↓
厂商硬件实现
    ↓
Driver

十五、hardware 不是"驱动源码目录"

这个一定不要混。

很多人看到：

复制代码

hardware/

就容易理解成：

Linux Driver 都在这里。

不是。

HAL 和 Linux Driver 是不同层级。

极度简化：

复制代码

Android Framework
       ↓
      HAL
       ↓
Linux Kernel Driver
       ↓
    Hardware

所以：

复制代码

hardware/

主要不要理解成：

复制代码

Linux 内核驱动全集

而应该先理解：

Android 平台与硬件实现之间的重要接口区域。

真正 Kernel Driver 是另外一层。

十六、device：具体设备适配

再看：

复制代码

device/

它解决的问题更加具体：

Android 到底要运行在哪一台设备上？

例如：

复制代码

手机
平板
车机
电视
开发板
虚拟设备

它们：

复制代码

CPU 不一样
屏幕不一样
分区不一样
硬件不一样
启动配置不一样

所以需要：

复制代码

设备相关配置

这就是：

复制代码

device/

存在的重要原因。

比如官方 AOSP 构建文档中可以看到设备目标相关配置会放在具体 device/... 路径，例如某些 Cuttlefish 或 Automotive 目标都会从设备目录加载配置。

所以先记：

复制代码

hardware
↓
偏硬件接口

device
↓
偏具体设备适配

十七、hardware 和 device 也不要混

可以用一个很粗的例子：

假设 Android 支持 Camera。

HAL 接口关注：

复制代码

Android 上层应该怎么和 Camera 硬件能力交互？

这更接近：

复制代码

hardware

而某一台具体设备：

复制代码

这台机器是什么 Camera？
Board 配置是什么？
产品怎么构建？

这些更接近：

复制代码

device

所以：

复制代码

hardware
=
"接口怎么定义"


device
=
"这台具体设备怎么配"

先这么理解。

十八、build：Android 是怎么编译出来的

普通 Android App 开发时，我们非常熟悉：

复制代码

Gradle
build.gradle.kts
AGP

但是：

AOSP 不是靠普通 Android App 的 Gradle 构建体系来完成整套系统编译。

AOSP 自己有系统级构建体系。

所以会看到：

复制代码

build/

其中一个非常重要的目录就是：

复制代码

build/soong

Soong 是当前 Android 使用的重要构建系统之一，它主要读取：

复制代码

Android.bp

这类构建描述文件。Google 的 Soong 官方仓库也明确说明，Soong 是 Android 的构建系统之一，Android.bp 描述其构建模块。

以后你看 AOSP 源码，会经常看到：

复制代码

Android.bp

不要懵。

你可以暂时把它理解成：

AOSP 模块的构建配置。

有点类似你 App 开发时看到：

复制代码

build.gradle.kts

时的感觉。

当然两者不是同一个构建系统。

十九、以后可能会看到这样的文件

比如某个目录：

复制代码

xxx/
├── Android.bp
├── src/
├── include/
└── ...

你就可以产生这种意识：

复制代码

Android.bp
↓
告诉 AOSP 构建系统
↓
这个模块叫什么
包含哪些源码
依赖什么库
最后构建成什么

现在不用学 Soong 语法。

第二阶段真正开始编译 AOSP 时再学。

二十、art：Android Runtime

接下来这个目录：

复制代码

art/

对应：

复制代码

Android Runtime

也就是我们经常听到的：

复制代码

ART

官方当前依然维护独立的：

复制代码

platform/art

项目。

它涉及：

复制代码

Java/Kotlin 字节码执行
DEX
GC
JIT
AOT
Runtime

等大量内容。

我们普通 App 写：

复制代码

fun main() {
}

最终能在 Android 设备上运行，并不是 Android 自己凭空直接执行 Kotlin。

中间还有：

复制代码

编译
DEX
Runtime
ART

这一整套体系。

二十一、现在千万别碰 ART 深入

ART 是一个非常大的坑。

会涉及：

复制代码

虚拟机
编译器
GC
内存
ClassLoader
DEX
JIT
AOT
Native

这些内容。

你现在只需要知道：

复制代码

art/
↓
Android Runtime

够了。

以后真要研究：

复制代码

启动优化
GC
运行时
ClassLoader
DEX

再回来。

二十二、bionic：Android 自己的 C Library

这个目录：

复制代码

bionic/

第一次看到非常容易不知道是什么。

其实：

复制代码

Bionic

是 Android 的 C library 体系。

官方对它的描述非常直接：

bionic is Android's C library, math library, and dynamic linker.

里面包括：

复制代码

libc
libm
libdl
dynamic linker

等等。

所以可以先理解：

复制代码

Android Native 世界
      ↓
   Bionic
      ↓
C Library / 动态链接等基础能力

二十三、为什么 Android 不直接跟普通 Linux 完全一样？

因为 Android 虽然使用 Linux Kernel，但：

Android 用户空间并不等于普通 Ubuntu/Linux Desktop 用户空间。

例如 Android 使用：

复制代码

Bionic libc

而不是简单照搬很多传统 Linux 发行版使用的完整用户空间体系。

所以以后越深入 Android Native，你越会发现：

复制代码

Android
=
Linux Kernel
+
Android 自己的大量用户空间体系

这也是系统层学习里一个很重要的概念。

二十四、external：大量第三方开源代码

这个目录：

复制代码

external/

相对比较好理解。

Android 不可能所有东西全部自己从 0 写。

系统内部也会使用很多外部开源项目。

例如可能包含各种：

复制代码

压缩库
协议库
数据库相关库
图形库
工具库
第三方组件

这些外部项目经 Android 平台集成以后，会出现在：

复制代码

external/

所以可以简单理解：

复制代码

external
↓
AOSP 集成的外部开源项目

第一阶段基本不用主动进去看。

二十五、vendor：厂商代码

再说一个以后做真正 Android 系统开发经常遇到的：

复制代码

vendor/

如果只是纯 AOSP 学习环境，你对它的感觉可能还没那么明显。

但真正进入：

复制代码

手机厂商
车机厂商
机器人
智能硬件
芯片平台

项目以后：

复制代码

vendor/

会变得非常重要。

这里通常会存在：

复制代码

厂商私有实现
平台配置
HAL 实现
芯片相关代码
产品定制

等等。

比如：

复制代码

vendor/xxx/

很可能就是：

某个平台或者某个厂商自己的代码。

二十六、AOSP 和真实公司源码树会不完全一样

这个也很重要。

你以后进公司看到：

复制代码

android/
├── frameworks/
├── system/
├── vendor/
├── device/
├── hardware/
└── company/

甚至多出来：

复制代码

vendor/qcom/
vendor/mediatek/
company/
partner/
proprietary/

都很正常。

因为真实商业系统一般是：

复制代码

AOSP
+
芯片厂代码
+
硬件厂商代码
+
公司定制代码

所以：

AOSP 目录地图是基础，但真实项目一定会在上面继续扩展。

二十七、Kernel 在哪里？

这里可能会出现一个疑问：

Android 不是基于 Linux Kernel 吗？

为什么前面 AOSP 根目录图里没重点说 kernel？

因为 Android Kernel 源码和 Android Platform 源码的组织方式需要分开理解。

实际 Android 开发中 Kernel 本身也有自己的源码仓库和 Manifest/构建体系。

所以不要简单认为：

复制代码

整个 Android Kernel
=
system/ 里的一个普通目录

不是这样。

现在只需要知道整体关系：

复制代码

AOSP Platform
      ↓
Framework
Native / HAL
      ↓
Linux Kernel
      ↓
Driver
      ↓
Hardware

Kernel 我们后面扫盲阶段只理解它的位置。

不学源码。

二十八、如果以后研究 Activity，该去哪？

现在开始真正用目录地图。

例如问题：

Activity 到底是什么？

你会想到：

复制代码

Framework API

那么优先看：

复制代码

frameworks/base/core

如果继续问：

Activity 的系统调度是谁做的？

开始涉及：

复制代码

ATMS / AMS

那么方向就来到：

复制代码

frameworks/base/services

于是：

复制代码

Activity API
↓
frameworks/base/core

Activity 系统服务
↓
frameworks/base/services

你已经开始会"找路"了。

二十九、如果以后研究 Settings 呢？

例如：

Android 设置里的蓝牙页面怎么实现？

先判断：

复制代码

这是一个系统 App

那么：

复制代码

packages/apps/Settings

就是非常自然的方向。

再进去可能看到：

复制代码

bluetooth/

模块。

这时候你和普通 Android App 开发的距离其实并不远。

因为里面一样会出现：

复制代码

Activity
Fragment
资源
Manifest
业务代码

三十、如果以后研究开机 init 呢？

先判断：

复制代码

init

不是普通 App。

不是 Framework API。

它属于：

复制代码

Android 系统启动基础设施

所以方向就会偏：

复制代码

system/

例如：

复制代码

system/core

这就是目录地图的价值：

还没开始搜源码，你已经知道大概往哪里走。

三十一、如果以后研究 Camera HAL 呢？

先判断：

复制代码

Camera
↓
硬件能力
↓
HAL

所以方向会进入：

复制代码

hardware/

再往下才可能继续进入：

复制代码

vendor
driver
kernel

而不是一上来就在：

复制代码

frameworks/base

里面乱搜。

三十二、App 开发者最值得先关注哪三个目录？

如果你只是像现在这样：

带着学一点系统层。

那我甚至建议：

第一阶段重点只记：

复制代码

frameworks/
packages/
system/

三个。

因为它们离你最近。

第一名：frameworks

以后绝大多数 Framework 扫盲内容都会碰。

例如：

复制代码

Activity
AMS
WMS
Binder API
SystemServer

第二名：packages

因为这里还能看到很多你熟悉的 App 形态代码。

例如：

复制代码

Settings

非常适合 App 开发者过渡。

第三名：system

开始帮助你逐渐建立：

复制代码

Android 不只是 Java Framework

这个意识。

下面还有：

复制代码

init
Native
系统工具
Linux

三十三、其他目录目前只是"知道名字"

你现在可以把深度分成三个等级。

一级：需要有基本感觉

复制代码

frameworks
packages
system

二级：知道作用

复制代码

hardware
device
build
art
bionic

三级：暂时看到不慌就行

复制代码

external
vendor
tools
prebuilts
bootable
development
test
...

不要背。

更不要打开 AOSP 根目录后，从第一个文件夹开始顺序学习。

那是最容易把自己学崩的方法。

三十四、prebuilts 又是什么？

顺便提一个经常会看到的：

复制代码

prebuilts/

从名字就可以猜：

复制代码

pre-built

即：

已经预先构建好的东西。

例如：

复制代码

工具链
编译器
SDK 相关组件
预编译工具

等。

AOSP 构建系统不可能什么东西都每次从源码重新构建。

所以存在大量：

复制代码

prebuilt

内容。

现在看到：

复制代码

prebuilts/

知道：

预编译工具/依赖。

够了。

三十五、bootable 又是什么？

以后可能看到：

复制代码

bootable/

顾名思义：

复制代码

boot

与设备启动相关。

例如：

复制代码

bootloader 相关组件
recovery

等内容可能出现在相关区域。

现在也不要深入。

因为一旦进入：

复制代码

Bootloader
Recovery
分区
刷机
启动镜像

马上又是一套非常大的知识体系。

扫盲阶段先放着。

三十六、AOSP 目录和 Git 仓库不是一一对应的"一级目录"

这里再把第二篇的 Repo 串回来。

你看到：

复制代码

frameworks/

不要认为：

frameworks 就是一个 Git 仓库。

并不是。

例如：

复制代码

frameworks/base

本身就是一个 Git project。

官方 AOSP Repo 文档也明确说明：Android 的 Repo 工作区由多个 Git project 组成，每个 project 对应源码树里的特定目录。

所以可能是：

复制代码

frameworks/
├── base
│    ↓
│   Git A
│
├── native
│    ↓
│   Git B
│
└── av
     ↓
    Git C

所以：

复制代码

目录结构

和：

复制代码

Git 仓库结构

是两个不同维度。

Repo 把它们最终组合成了一棵：

复制代码

完整 AOSP 源码树

三十七、现在把 Repo、Manifest、源码目录再串一次

复制代码

Manifest
    ↓
Repo
    ↓
很多 Git 仓库

Repo 同步完成以后：

复制代码

多个 Git 仓库
     ↓
按照 Manifest 的 path
     ↓
组合成本地目录树

最终你看到：

复制代码

AOSP/
├── frameworks/
├── packages/
├── system/
├── hardware/
├── device/
└── ...

所以这棵目录树并不是：

一个大 Git clone 出来的。

而是：

Repo 把大量 Git 仓库按照 Manifest 拼成了一棵完整源码树。

现在第二篇和第三篇就彻底连起来了。

三十八、给 App 开发者的一张 AOSP 地图

最后把这一篇压缩成一张图：

复制代码

AOSP
│
├── frameworks/
│      ↓
│   Android Framework
│   API / System Services / SystemUI
│
├── packages/
│      ↓
│   Settings 等系统 App / 模块
│
├── system/
│      ↓
│   Android 系统底层基础组件
│
├── hardware/
│      ↓
│   HAL / 硬件接口
│
├── device/
│      ↓
│   具体设备适配
│
├── build/
│      ↓
│   AOSP 构建体系
│
├── art/
│      ↓
│   Android Runtime
│
├── bionic/
│      ↓
│   Android C Library
│
├── external/
│      ↓
│   外部开源代码
│
└── vendor/
       ↓
    厂商相关代码

三十九、现阶段千万不要做什么？

看到这些目录之后，不要突然开始：

复制代码

今天读 frameworks/base
明天读 system/core
后天研究 ART
然后学 HAL
再研究 Kernel

这会彻底失控。

你现在只需要形成这种条件反射：

复制代码

Framework 问题
→ frameworks


系统 App
→ packages


系统底层
→ system


HAL
→ hardware


设备适配
→ device


系统编译
→ build


Runtime
→ art


C Library
→ bionic

够了。

四十、一句话总结

第一次看 AOSP 源码，不要把它理解成：

一大堆完全看不懂的文件夹。

应该把它理解成：

Android 操作系统不同职责模块的地图。

对于 App 开发者来说，第一阶段最重要的三个入口是：

复制代码

frameworks
packages
system

其中：

复制代码

frameworks
↓
Android Framework / System Service


packages
↓
系统应用


system
↓
系统底层基础组件

其他目录暂时建立名字和职责对应关系即可。

学到这里，我们已经完成了：

复制代码

第一篇
AOSP 是什么

↓

第二篇
AOSP 这么多 Git 仓库怎么管理

↓

第三篇
这些仓库最终组成的源码树怎么看

到这里，AOSP 这座"大楼"我们已经知道：

它是什么、怎么组织、各个区域大概在哪里。

下一篇就正式开始研究 Android 系统本身：

《Android 系统层扫盲 04：Android 系统到底分几层？从 App 一路看到 Linux Kernel》

下一篇会把：

复制代码

App
Framework
System Services
ART
Native
HAL
Kernel
Hardware

真正串成一张完整的 Android 系统架构图。

这张图一旦建立起来，后面的 Zygote、SystemServer、Binder、AMS、HAL 才会真正有位置可以放。