Android系统编译源码目录详解

源码目录详解

一、核心框架与系统层相关

1. frameworks
   • 功能：Android 框架的核心代码所在地，包含了系统应用开发会涉及的各类基础框架，像四大组件（Activity、Service、BroadcastReceiver、ContentProvider ）的底层实现、系统服务（比如 WindowManagerService 等负责窗口管理 ）、资源管理框架等。做系统应用时，若要定制系统级功能（如修改系统界面交互逻辑、扩展系统服务能力 ），常需要深入这个文件夹查看和修改代码，比如调整系统应用的启动流程、自定义系统级的 UI 控件行为等。
2. system
   • 功能：存放 Android 系统核心功能相关代码和配置，包含系统基础服务（如电源管理、初始化脚本等 ）、系统应用的基础支撑部分（像系统设置、桌面 launcher 等系统应用依赖的一些底层逻辑 ）。开发系统应用时，若要对系统基础功能做适配或增强（比如优化系统待机功耗对系统应用的影响、调整系统桌面布局规则 ），会频繁接触这里的内容。
3. vendor
   • 功能：一般用于存放设备厂商定制化的代码和资源，比如芯片厂商针对自家硬件（如特定型号的 CPU、传感器 ）适配的驱动、系统级功能补丁等。如果开发的系统应用需要调用厂商特定硬件能力（如特殊摄像头的高级功能 ），或者要适配厂商定制的系统特性（如定制化的系统升级流程 ），就会用到这个文件夹里的内容。
4. kernel（及 kernel - 6.1 ）
   • 功能：存放 Linux 内核相关代码，Android 系统基于 Linux 内核构建。虽然系统应用开发不常直接修改内核代码，但了解内核提供的硬件驱动接口、进程调度机制等，对开发涉及硬件交互（如高性能传感器数据采集的系统应用 ）、系统级性能优化（如优化系统应用的进程优先级 ）的功能很有帮助，比如某些系统级的电量监控、硬件状态检测应用，需要基于内核提供的信息来开发。

二、编译、构建与开发工具链相关

1. build
   • 功能：包含 Android 系统编译构建的脚本、配置文件等，用于定义整个系统（包括系统应用 ）的编译规则、产物输出路径、依赖管理等。开发系统应用时，若要调整应用的编译参数（如优化编译选项来减小系统应用体积 ）、添加新的系统应用编译模块，或者定制系统镜像的构建流程（把自己开发的系统应用集成到最终的系统镜像里 ），就会用到这里的内容，比如修改 Android.bp（Android 构建配置文件 ，类似之前的 Android.mk ）相关的构建逻辑。
2. prebuilts
   • 功能：存放预编译的二进制文件、库等，像不同架构（如 arm、x86 ）的编译器、一些第三方预编译的系统依赖库。开发系统应用时，编译过程中会依赖这里的工具和库，比如使用预编译的编译器来编译自己开发的系统应用代码，确保编译环境的一致性，若遇到编译相关问题（如编译报错提示缺少某个预编译库 ），也需要到这里排查。
3. toolchain
   • 功能：和编译工具链紧密相关，包含用于编译 Android 系统和应用的编译器、链接器等工具的配置和部分源码（或指向相关工具的路径 ）。开发系统应用时，若要针对特定硬件架构优化编译结果（如为 arm64 架构定制编译选项 ），或者解决编译工具链相关的兼容性问题（如升级编译器版本后适配 ），会涉及到这个文件夹的内容，比如调整编译器的参数配置来提升系统应用的运行效率。
4. Android.bp
   • 功能：Android 构建系统的配置文件，用于替代传统的 Android.mk ，定义模块的编译信息，比如一个系统应用模块，要指定源码文件、依赖的库、编译输出的产物类型（是可执行文件、库还是 APK 等 ）。开发系统应用时，每个系统应用模块都需要编写对应的 Android.bp 文件，来指导编译系统生成应用的可执行文件或安装包，是构建系统应用必不可少的配置文件。
5. build.sh
   • 功能：一般是自定义的编译脚本，可能用于简化编译流程，比如整合一系列编译命令（如先设置环境变量，再调用编译工具链执行编译 ），方便开发者一键编译整个系统或特定模块（包括系统应用 ）。开发系统应用过程中，若觉得默认编译流程繁琐，可通过修改或自定义 build.sh 脚本来适配自己的开发习惯，快速编译测试自己开发的系统应用。

三、系统应用与包管理相关

1. packages
   • 功能：存放 Android 系统应用的源码，像系统自带的设置（Settings ）、电话（Telephony ）、短信（Mms ）等应用的代码都在这里。开发系统应用时，要新增或修改系统应用功能（比如给系统设置应用添加新的设置项、优化电话应用的通话逻辑 ），就直接在这个文件夹对应的应用模块里进行代码开发和调试，是系统应用开发的核心代码存放地。
2. device
   • 功能：存放设备相关的配置和适配代码，不同设备（如不同型号手机、平板 ）的特定配置（像屏幕分辨率适配、硬件外设适配参数 ）、设备树信息等在这里。开发系统应用时，若要让应用在不同设备上有合适的显示和功能表现（比如系统相机应用适配不同设备的摄像头参数 ），需要参考或修改这个文件夹里对应设备的配置文件，确保系统应用的硬件兼容性和显示正确性。

四、测试、调试与辅助工具相关

1. test
   • 功能：包含系统和应用的测试相关代码、测试用例等，用于对系统功能、系统应用进行单元测试、集成测试等。开发系统应用时，为了确保新增或修改的功能稳定可靠，需要编写测试用例（如在这个文件夹里添加针对自己开发的系统应用模块的测试代码 ），然后利用这里的测试框架来执行测试，验证应用功能是否符合预期，排查潜在的 bug 。
2. development
   • 功能：存放 Android 开发相关的辅助工具、示例代码等，比如一些系统应用开发的示例项目、调试工具的源码（像辅助查看系统日志、分析系统性能的小工具 ）。开发系统应用时，可以参考这里的示例代码学习系统应用的最佳实践，也可以利用里面的调试工具来辅助开发，比如用开发包里的性能分析工具检测自己开发的系统应用的内存占用、CPU 使用率等情况 。
3. out
   • 功能：编译系统的输出目录，编译系统或系统应用后，生成的可执行文件、APK 安装包、系统镜像等产物会存放在这里。开发系统应用时，编译完成后，可到这个文件夹下对应的产物路径找到自己开发的系统应用的 APK 文件（或其他产物 ），用于后续的安装测试（如刷入设备进行实际运行测试 ），查看编译输出的日志、产物信息等，辅助调试开发过程中遇到的问题。

五、其他关键文件 / 文件夹

1. bootstrap.bash
   • 功能：可能是用于初始化编译环境、配置开发环境变量的脚本，在开始编译系统或系统应用前，有时需要执行这类脚本，设置好编译所需的环境（如指定编译器路径、设置系统构建的基础参数 ），确保后续编译、开发工作能顺利进行，开发系统应用涉及编译流程时，可能会用到它来准备环境 。
2. mkimage.sh 等（mkimage_ab.sh 等类似脚本 ）
   • 功能：一般用于制作特定的系统镜像文件，比如制作 boot 镜像、recovery 镜像等，这些镜像里包含了系统内核、系统应用等关键部分。如果开发的系统应用需要集成到特定的镜像中（如自定义的系统 recovery 镜像里要包含自己开发的系统级恢复工具应用 ），可能需要使用这类脚本来生成包含自己应用的镜像文件，进行系统级的功能定制和集成 。
3. user.config.proto
   • 功能：可能是用于定义用户相关配置的协议文件（基于 Protocol Buffers 格式 ），如果开发的系统应用涉及到用户个性化配置（如系统设置里的用户偏好存储、多用户环境下的应用配置区分 ），可能会用到这个文件定义的配置结构，来实现配置的序列化、反序列化，让系统应用能正确读写用户配置信息 。

上述这些是安卓系统应用开发中较为常用的文件 / 文件夹，实际开发时，会频繁在 frameworks、packages、build 等核心目录间穿梭，结合编译、调试、适配等需求来使用它们 。

/frameworks及其子目录讲解

1. base

核心中的核心，系统应用开发绕不开它。

• 功能
  • 包含 四大组件（Activity/Service/BroadcastReceiver/ContentProvider） 的核心逻辑，比如 Activity 的生命周期管理、Service 的绑定 / 启动流程、ContentProvider 的跨应用数据共享机制。
  • 系统服务的基础定义（如 Context、PowerManager、WindowManager 等），几乎所有系统应用都会调用这些服务。
  • 资源管理、主题样式、布局解析等基础框架代码（比如 LayoutInflater 解析 XML 布局的逻辑）。
• 场景：
  开发系统应用时，只要涉及 界面交互、后台服务、系统权限、数据共享，都会深度依赖 base。比如定制系统设置（Settings）、系统桌面（Launcher）时，需要修改 Activity 启动逻辑、重写窗口管理（WindowManager）相关代码。

2. av

系统多媒体应用开发必用，涉及音频、视频、相机等功能。

• 功能：
  提供 音视频编解码（如 H.264、AAC）、播放 / 录制框架，以及相机驱动对接逻辑（Camera HAL 上层封装）。
  包含 MediaPlayer、MediaRecorder、Camera 等核心类的底层实现。
• 场景：
  开发系统相机（Camera）、系统音乐播放器（Music）、屏幕录制（ScreenRecorder）等应用时，需要调用 av 的接口控制硬件、处理音视频流。比如定制相机的拍照流程、优化视频编码参数。

3. hardware

系统应用对接硬件的关键层，尤其是需要深度控制硬件时。

• 功能：
  封装 硬件抽象层（HAL）接口，向上提供统一的硬件调用方式（如传感器、蓝牙、Wi-Fi、显示驱动）。
  包含 SensorManager（传感器管理）、DisplayManager（显示控制）、BluetoothManager（蓝牙服务）等核心类。
• 场景：
  开发系统级应用（如系统设置里的 “显示设置”、“传感器校准工具”）时，需要通过 hardware 调用底层硬件。比如修改屏幕分辨率、读取传感器原始数据、定制蓝牙配对逻辑。

4. native

系统应用涉及高性能计算、底层交互时必用，比如图形渲染、音视频处理。

• 功能：
  包含 C/C++ 实现的高性能模块（如图形渲染引擎、音频 DSP 处理），通过 JNI 与上层 Java 代码交互。
  涉及 OpenGL ES（图形渲染）、Skia（2D 绘图引擎）、MediaCodec（硬解码 / 编码）等底层实现。
• 场景：
  开发系统级 Launcher（需要高性能动画渲染）、系统视频编辑器（需要硬编码加速）时，需要调用 native 的 C/C++ 接口优化性能。比如重写 Launcher 的桌面动画、优化视频编码效率。

5. libs

系统应用依赖的基础库集合，虽然不直接改代码，但开发调试必看。

• 功能：
  存放 Android 框架依赖的 基础库（如 libutils、libcutils），提供内存管理、字符串处理、日志输出等基础功能。
  部分第三方库的适配代码（如 libjpeg 用于图片处理）。
• 场景：
  开发系统应用时，遇到 内存泄漏、性能瓶颈、基础工具类问题，需要到 libs 中排查底层实现。比如分析 libutils 的内存分配逻辑，优化系统应用的内存占用。

6. minikin

系统应用涉及文字渲染、排版时必用，比如系统设置、系统输入法。

• 功能：
  负责 字体渲染、文本排版、字符 shaping（如复杂语言排版：阿拉伯语、泰语），是 TextView、EditText 等控件的底层支撑。
  包含 Minikin 引擎（Android 文字渲染核心）、字体管理逻辑。
• 场景：
  开发系统级输入法（如 AOSP 输入法）、系统设置（需要复杂文字排版）、电子墨水屏适配（需要定制文字渲染）时，需要修改 minikin 调整文字显示效果。比如优化字体渲染性能、适配特殊字体格式。

7. layoutlib

开发系统应用的 UI 时高频用，涉及布局解析、预览、渲染。

• 功能：
  负责 XML 布局解析、布局预览、动态布局计算，是 LayoutInflater 的底层实现。
  包含布局渲染引擎（如 RenderNode、DisplayList），决定 UI 如何绘制到屏幕。
• 场景：
  开发系统应用的自定义控件、复杂布局（如系统设置的多面板布局）时，需要调试 layoutlib 确保布局正确渲染。比如重写系统 Launcher 的桌面布局、优化布局加载性能。

总结：高频使用优先级

1. base：所有系统应用开发的基础，必用。
2. av：多媒体类系统应用（相机、音乐、视频）必用。
3. hardware：涉及硬件控制的系统应用（显示、传感器、蓝牙）必用。
4. native：高性能计算、底层交互（图形渲染、音视频处理）必用。
5. minikin/layoutlib：系统应用 UI 开发（文字渲染、布局调试）高频用。

/build目录详解

1. 核心构建工具相关

bazel

• 功能：Google 推出的高级构建系统，在 Android 构建体系里，可用于定义复杂的编译规则、管理多语言代码（C++/Java 等）的依赖与编译流程。
  适合处理大规模、多模块项目，能加速编译（通过缓存、并行编译），若项目用 Bazel 定制系统模块编译（如特定系统服务、应用），会深度涉及。
• 场景：编译需精细控制（如定制系统级 SDK、优化编译依赖），或与 Google 生态深度协同（如集成 AOSP 最新构建流程）时，会用其编写 BUILD 规则文件。

soong

• 功能：Android 主推的构建系统（替代旧版 make 部分功能 ），基于 Blueprint 语言定义构建规则，将 .bp 文件（类似 Makefile 语法更简洁）转换为 Ninja 编译脚本，负责系统模块（如 frameworks、系统应用）的编译、依赖管理。
  几乎所有 Android 系统模块（尤其是 AOSP 原生代码）都通过 Soong 构建，是系统编译的 “中枢”。
• 场景：修改系统应用源码后编译、新增系统模块（如自定义系统服务）、调整编译参数（如优化系统镜像大小），都要写 / 改 .bp 文件，依赖 Soong 解析构建。

blueprint

• 功能：Soong 的 “语法引擎”，定义 Soong 构建规则的语法规范（即 .bp 文件怎么写、怎么解析 ），提供一套 DSL（领域特定语言）让开发者描述模块编译逻辑（如源文件、依赖库、编译选项）。
  是 Soong 能工作的基础，决定 .bp 文件如何转化为实际编译指令。
• 场景：一般不直接改其代码，但写 .bp 文件时（如给系统应用加编译依赖），遵循的语法规则由它定义，理解它能少踩构建配置的坑。

2. 传统构建兼容与辅助

make

• 功能：遗留的构建系统（Android 早期主力，现逐步被 Soong 替代，但部分老模块、第三方适配还在用 ），处理用 Android.mk 定义的编译逻辑，负责调用编译器、链接器生成可执行文件 / 库。
  一些未迁移到 Soong 的模块（如老旧硬件驱动、第三方闭源库适配），仍依赖 make 编译。
• 场景：给系统集成老驱动、适配特殊硬件（如传统外设），或维护老版本 AOSP 代码时，会接触 Android.mk 和 make 构建流程。

pesto

• 功能：相对 “小众”，是 Soong 体系里辅助优化编译的工具，可能用于特定场景加速（如增量编译优化、模块依赖分析 ），或针对某些芯片厂商定制的构建增强（如高通、联发科可能基于它做编译加速适配 ）。
  文档 / 资料少，实际是 Soong 生态的 “补充组件”，非核心但存在时会影响编译效率。
• 场景：系统编译慢、需深度优化（如全量编译耗时太长），或芯片厂商定制构建流程里，可能涉及它的配置 / 调试。

3. 构建流程控制与环境

envsetup.sh

• 功能：Android 编译环境初始化脚本！执行它（source envsetup.sh ）后，会设置编译所需环境变量（如 ANDROID_BUILD_TOP 指向源码根目录 ）、加载编译命令（如 lunch 选编译目标、m 编译模块 ），是开始编译前必执行的 “第一步”。
  所有编译工作（不管用 Soong、Bazel 还是 make ），都依赖它初始化环境。
• 场景：每次新开终端编译 Android 系统 / 应用，第一步就是 source build/envsetup.sh，然后用 lunch 选机型、m 编译，是 “编译流程起点”。

target

• 功能：存放编译目标相关配置，如不同设备（机型、芯片平台 ）的编译参数、系统镜像裁剪规则、依赖的二进制文件（如特定设备的预编译驱动 ）。
  决定编译出的系统镜像适配哪些设备、有哪些功能（如给 Pixel 手机编译和给 Generic AOSP 编译，target 配置不同 ）。
• 场景：适配新机型（如开发板、定制设备 ）、裁剪系统功能（如去掉某地区不用的系统应用）、集成设备专属驱动时，要修改 target 里的配置文件（如 device.mk 之类 ）。

4. 编译产物与清理

CleanSpec.mk

• 功能：定义 “清理编译产物” 的规则，执行 make clean 等命令时，根据这里的配置决定删哪些文件（如编译生成的 .o 文件、中间产物、最终镜像 ）。
  控制编译缓存、中间文件的清理范围，避免残留旧编译结果影响新构建。
• 场景：编译报错（怀疑是旧产物干扰）、想彻底清理构建环境（如切换编译目标机型），或定制清理策略（如保留部分缓存加速二次编译）时，会关注 / 修改它。

buildspec.mk.default

• 功能：编译配置的 “默认模板”，定义编译时可用的环境变量、默认编译选项（如编译类型是 user/eng/userdebug ），可基于它创建自定义 buildspec.mk 覆盖默认配置。
  想全局改编译参数（如默认开启调试日志、指定编译器版本 ），不用每次编译都传参数，而是改这里或基于它定制。
• 场景：做系统级编译优化（如统一开启 LTO 优化）、定制编译环境（如指定 Java 版本 ），会复制它为 buildspec.mk 再修改。

5. 工具与脚本辅助

tools

• 功能：存放构建流程用到的辅助脚本、小工具，如编译时的代码检查工具（语法校验、依赖分析 ）、生成系统镜像的脚本、构建日志分析工具等。
  是构建流程的 “润滑剂”，解决编译前后的杂项任务（如预处理代码、后处理镜像 ）。
• 场景：编译报错时，用这里的工具分析日志（如找依赖缺失）；定制系统镜像（如往 system.img 加自定义文件 ），会调用 tools 里的打包脚本。

envsetup.sh

• 功能：如前所述，初始化编译环境的核心脚本！执行后，不仅设环境变量（如 ANDROID_PRODUCT_OUT 指向输出目录 ），还加载 lunch（选编译目标 ）、m（编译模块 ）、mm（编译当前目录模块 ）等命令，让你能方便控制编译流程。
  每次开始编译工作，第一步就是 source build/envsetup.sh，是 “进入” Android 编译环境的标志。
• 场景：所有编译操作的前提，只要想编译系统模块、系统应用，都得先执行它激活环境。

6. 总结：怎么用这些目录？

• 日常开发（改系统应用、加系统功能）：高频碰 soong（写 .bp ）、envsetup.sh（初始化环境 ）、tools（辅助编译 / 调试 ），理解 Soong 构建规则（.bp 语法）就能应对大部分编译需求。
• 深度定制（改系统构建流程、适配新编译系统 ）：得啃 bazel（若对接 Google 新流程 ）、soong + blueprint（理解构建规则怎么跑 ）、make（兼容老模块 ），涉及编译系统本身的开发。
• 排障与优化（编译报错、加速构建 ）：关注 CleanSpec.mk（清理策略 ）、buildspec.mk.default（默认配置 ）、tools（日志分析 ），用它们解决环境、缓存、配置冲突问题。

整体目录总结

frameworks
	|--base：所有系统应用开发的基础
    |	|--core + services：系统应用开发的 “基石”，所有功能都依赖。
    |	|--packages：定制系统应用（如 Launcher、Settings）的直接入口。
    |	|--graphics + media：涉及 UI 渲染、音视频的系统应用必改。
    |	|--telecomm + telephony：做系统通话、网络功能定制时用。
    |	|--tests + tools：开发 + 测试流程中高频辅助。
	|--av:系统多媒体应用开发必用，涉及音频、视频、相机等功能。
	|--hardware：涉及硬件控制的系统应用（显示、传感器、蓝牙）必用。
	|--native：高性能计算、底层交互（图形渲染、音视频处理）必用。
	|--minikin/layoutlib：系统应用 UI 开发（文字渲染、布局调试）高频用。
build
	|--envsetup.sh 初始化环境
	|--tools 辅助编译/调试/日志分析
	|--make 兼容老模块
	|--bazel对接谷歌新流程
	|--CleanSpec.mk清理策略
package
	|--apps放系统的完整代码
	|--services存放系统服务应用
	|--providers存放内容提供者的实现
	|--wallpapers存放系统壁纸相关代码
	|--screensavers存放屏保功能的实现
	|--modules包含主要模块内容：WIFI、蓝牙、adb、权限管理、设备锁、媒体等
	|--inputmethod输入法框架