m SystemUI 却看到编译系统疯狂地在“包括一大堆 mk 文件”

你问得特别好，这种情况在 MTK 平台上非常常见。 表面上你只是执行了：

m SystemUI

但结果却看到编译系统疯狂地在“包括一大堆 mk 文件”，从 Telephony 到 Dialer 再到 Bluetooth，最后甚至跑到 vendor/sz/Android.mk，看起来几乎在重编整个系统。

🧩 一、为什么会这样：m SystemUI ≠ “只编译 SystemUI”

Android 的 m 命令（或 make) 是 基于依赖关系 的构建系统。 也就是说：

你指定编译某个模块，它会先编译它所有依赖项。

举个例子：

你执行：

m SystemUI

SystemUI 的 Android.bp / Android.mk 里包含的依赖非常多，比如：

• frameworks/base/packages/SystemUI 依赖：
  • framework-res
  • libframework
  • services.jar
  • SettingsLib
  • Telephony、Bluetooth、WiFi 模块的 AIDL 接口
  • frameworks/opt/… 模块资源
  • vendor 定制的 overlay（MTK、

因此，它必须先确保所有这些依赖都编译完成。

🧱 二、为什么你看到 vendor/mediatek、vendor/ 都被编译

MTK 的 build system 定制得更重，它在 Android.mk 里常常这样写：

include $(call all-makefiles-under,$(MTK_PATH_SOURCE))

或者：

include $(call all-makefiles-under,vendor/mediatek/proprietary)

这意味着：

• 一旦你触发一个模块（哪怕只是 SystemUI）
• Make 会扫描所有 vendor 下的 mk 文件
• 把依赖的全部模块都 include 进来（即便最后没重新编译，也会“包含”）

所以你看到很多：

including vendor/mediatek/proprietary/...

其实只是 Make 在 include mk 文件时打印的日志，并不代表所有都重新编译了。

🧭 三、日志显示 “99%” 是什么意思

当你看到：

[ 99% 1363/1368] including ...

这些 “including” 是 makefile 解析阶段的统计数字。 说明现在 Make 正在解析模块依赖（而不是实际编译 .java/.so）。

这一步会很慢，因为：

• SystemUI 依赖 framework/base 中的类；
• framework/base 又依赖 framework/native；
• vendor/mediatek 里 patch 过 framework；
• 最后整个依赖树都被 include 一遍。

⚙️ 四、为什么还会看到 “_sz/Android.mk” 报错

你的日志中：

cp: bad  *.ini': No such file or directory
 i: No such file or directory

这其实是 自定义打包配置脚本 也被 include 进来了。 原因是 MTK 的 build system 末尾有一句类似：

include vendor/ z/Android.mk

所以无论你编什么模块，它都会跑过来检查 的配置文件。 这些缺失的 .ini 文件不会阻止编译（除非它们是打包关键文件），但会打印出错误提示。

✅ 五、总结一句话

💡 建议：

如果你只是想快速编译修改过的 SystemUI.apk，可以用更轻量的方式：

mmm frameworks/base/packages/SystemUI

或者：

mka SystemUI

区别：

• m 是全局编译器，会 include 所有 mk 文件（慢）
• mmm 只编译指定路径模块（快）