简介MT6799开发板的Android源码编译资料面向嵌入式开发者和系统移植人员讲解在Ubuntu 16.04下下载、解压并编译Android Nougat 7.0及4.4源码的方法覆盖虚拟机软件源替换、共享文件夹配置、VMware Tools与依赖工具安装等前置工作。资源仅1个docx文档压缩包895KB但内容完整包含从备份源列表、安装OpenJDK 8到执行lunch和make -j4 systemimage的实操步骤并整理了三类典型编译报错的排查建议如TAREGT_BRM_PLATFORM未定义、ninja子命令失败、fork内存不足等。文档对每个报错都给出原因说明和解决思路适合刚接触MT6799源码编译的开发者依照流程操作减少环境配置和排错耗时已有633人学习下载。1. Android 源码编译连环报错从 TAREGT_BRM_PLATFORM 到 fork 内存不足的完整排错在 Ubuntu 16.04 上编译 MT6799 开发板的 Android Nougat 7.0 源码一路会踩到三个高频率报错TAREGT_BRM_PLATFORM is undefined、ninja: build stopped: subcommand failed、fatal: fork: Cannot allocate memory。这三个报错单看任何一个都让人头大叠加起来更是劝退新手——它们分别对应编译系统配置、JACK 工具内存参数、虚拟机物理资源三个层面错一个后面全跟着报错。这份文档把整个编译流程和三次踩坑都记录下来了适合正在编译 Android 7.0 及类似平台源码、被这几个报错卡住的开发者照着每一步操作能少走很多弯路。2. 环境配置换源、共享文件夹、虚拟机硬件哪一步错后面全报错2.1 Ubuntu 换国内镜像源备份、追加、更新三步走漏掉 deb-src 后期装依赖会翻车编译 Android 源码前第一步是让apt-get能快速、稳定地拉取依赖包。默认的 Ubuntu 官方源在国内访问速度不稳定所以文档里先把/etc/apt/sources.list备份再修改换成国内镜像源。很多人会跳过备份直接改一旦改错连恢复的后悔药都没有所以我建议严格照做sudo cp /etc/apt/sources.list /etc/apt/sources.list.backup sudo gedit /etc/apt/sources.list备份命令把当前源列表复制成.backup后缀文件gedit打开后在文件末尾追加镜像源配置。这里有个关键点很多人以为只要把deb行加上就行但 Android 编译过程中某些依赖需要源码包deb-src行不能省。文档里追加的内容同时包含deb和deb-src覆盖 main、restricted、universe、multiverse 四个组件并且区分了 xenial、xenial-updates、xenial-backports、xenial-security 这几个发行版仓库。sudo apt-get update这条命令执行后系统会重新读取源列表并建立索引。如果源列表写错这里会直接报错比如Unable to locate package或者 GPG 签名问题。换源后必须执行这一步否则后面apt-get install装的还是旧索引里的包。提示如果你用的不是 Ubuntu 16.04 Xenial千万不要照搬文档里的 xenial 仓库行否则会提示 Release 文件不存在改成你自己系统版本代号比如 bionic、focal即可。2.2 VMware Tools 与共享文件夹压缩包必须拷进 Linux 解压直接放在共享目录会出怪问题虚拟机装好后主机和虚拟机之间传文件靠的是共享文件夹功能。文档里特别强调了一句话“一定要把压缩文件从共享文件复制到 linux 环境下解压”这句话是血泪经验不是随口一说。共享文件夹本质上是 VMware 提供的一个映射目录文件系统行为和本地磁盘不完全一致直接在 /mnt/hgfs/ 下解压源码包容易出现解压中断、文件权限错乱、符号链接失效等诡异问题。安装 VMware Tools虚拟机增强工具的流程如下tar zxvf VMwareTools-10.1.15-6627299.tar.gz cd vmware-tools-distrib/ sudo ./vmware-install.pltar zxvf解压工具包-z指定 gzip 压缩格式-x解压-v显示过程-f指定文件名。进入vmware-tools-distrib目录后执行安装脚本过程中会问你 YES/NO 和安装路径一路输入 Y 并回车接受默认路径即可。安装完成后重启虚拟机共享文件夹才会挂在 /mnt/hgfs/ 下。注意如果执行cd /mnt/hgfs/提示目录不存在先确认增强工具装好、共享文件夹已在虚拟机设置里添加并且登录用户有权限访问。文档里没提的是某些发行版还需要手动执行sudo mount -t vmhgfs .host:/ /mnt/hgfs来挂载。2.3 虚拟机硬件配置与源码解压300G 磁盘、16G 内存、cat 管道解压多段包MT6799 的 Android Nougat 7.0 源码解压后体量很大文档给出的虚拟机配置是硬盘 300G、内存 16G、处理器 2 核 2 线程。这个配置不是随便写的——编译过程中源码、中间产物、out 目录加起来占用轻松超过 100G内存 16G 是避免后期fork: Cannot allocate memory的基础条件后面会专门讲。硬盘 300G 这个要求容易被忽略。很多人虚拟机只分 80G编译到一半磁盘满了ninja直接报错退出而且这种失败的中间文件特别占空间删起来也麻烦。源码从共享文件夹拷到 Linux 环境后文档用了这样的解压命令cat MT6799_Android_Nougat_7.0.tar.bz2.* | tar jvxf -这里用cat把分段压缩包合并成完整流再通过管道传给tar。j表示 bzip2 压缩格式v显示解压过程f -表示从标准输入读取数据。如果你把这段命令理解成“解压第一个包就行”那就错了——分卷压缩必须合并后统一解压只解压单个分卷大概率报unexpected end of file。解压后文档还执行了 md5 校验md5sum -c MT6799_Android_Nougat_7.0.tar.bz2.md5这里有个坑文档里写的是“这里报错没关系后面只要编译正常功能没问题就行”。实际我的经历是md5 校验失败通常意味着某个分卷在拷贝和解压过程中损坏最稳妥的做法是重新从主机拷贝损坏的分卷。磁盘 IO 不稳定、共享文件夹传输中断都可能导致校验失败忽略它继续编译有可能在某个模块编译时报出完全无法定位的奇怪错误。建议先确认是校验文件本身格式问题比如 md5 校验文件里缺少对应分卷条目还是真的有分卷损坏分清楚再决定是否跳过。3. TAREGT_BRM_PLATFORM is undefinedvendor.mk 没被正确引入的完整修复思路3.1 报错现场Android.mk 第 4 行直接中断编译编译执行到一半终端输出这样一条信息vendor/amt/libs/hwcomposer.mt6799.1.5.0/Android.mk:4: *** TAREGT_BRM_PLATFORM is undefined. Please make sure the device-vendor.mk is correctly included.这个报错的特点是它出现在编译早期甚至可能连make的进度条都还没跑起来就中断了。注意报错信息里 TAREGT_BRM_PLATFORM 这个变量名本身还拼错了应该是 TARGET但这不影响排错方向——错误的核心是某个硬件抽象层模块的 Android.mk 里引用了一个未定义的平台变量而这个变量本来应该由 device-vendor.mk 定义。触发条件是平台宏变量没有从设备配置链传过来。MT6799 这类项目设备相关的 mk 文件通常包含 device 目录和 vendor 目录的配置链配置链断了或者没有被正确 include任何依赖 TARGET_BRM_PLATFORM 的模块都会报这个错误。3.2 根因分析配置链断裂、依赖工具缺失、源列表不完整三选一这类报错的根因不能只看 Android.mk 本身。它只是表象下面至少有三层可能第一层是 device-vendor.mk 没有被正确 include。Android 编译系统通过lunch选择的产品配置来决定包含哪些 mk 文件如果你选的 lunch target 对应的 device 配置里没有 include vendor 的 mk或者 vendor 目录下的配置文件缺失、路径写错就会导致平台变量永远是 undefined。文档里提示“请检查 device-vendor.mk 是否被包含”就是指引你去核对产品配置链。第二层是编译依赖的工具链不完整。缺失某些系统库或工具时编译系统在解析模块依赖的阶段可能走不到正确路径报出一些看似无关的宏未定义错误。文档里列了一长串依赖安装命令包括 build-essential、bison、flex、gperf、libxml2-utils、g-multilib、gcc-multilib 这些就是为了排除这一层。第三层是源码解压不完整。如果分卷包有损坏而你在 md5 校验失败时选择了忽略某些目录缺失配置链走到一半断掉也会出现这个报错。这能解释为什么文档最后说“把源文件全部删除、重新解压、重新安装配置”才是万不得已的根治方案。3.3 解决步骤依赖补齐 jack_install.sh 按平台文档重来文档给出的解决步骤可以拆成三步。第一步是升级系统包并补齐依赖顺序很重要sudo apt-get upgrade sudo apt-get install openjdk-8-jdk build-essential bc flex unzip zip bison gperf curl zlib1g zlib1g-dev tofrodos libxml2-utils git sudo apt-get install g-multilib gcc-multilib lib32ncurses5-dev lib32readline-gplv2-dev lib32z1-dev bisonapt-get upgrade先把系统已有的包升级到统一版本避免某些库版本过旧导致编译工具链不兼容。第一条 install 装的是 Android 编译的基础工具第二条装的是 32 位兼容库——如果你用的是 64 位 Ubuntu编译过程中会有 32 位工具链调用缺这些库会出现/bin/bash: 没有那个文件或目录这类误导性报错。第二步是安装并运行平台提供的脚本# 将 jack_install.sh 拷贝到工程目录下执行 ./jack_install.sh这个脚本的作用是初始化 JACK 服务的运行环境。文档里提到这个脚本要放到 MTK 工程下面再运行本质上是因为 Android 编译过程依赖 JACK 服务做 Java 代码编译脚本会读取当前工程的配置来设置 JACK 的 JAR 包路径。第三步是严格按照平台 PDF 文档操作这一步无法绕过。平台厂商提供的 Basic 文档里通常会写明具体需要执行的lunchtarget 名、是否需要额外设置环境变量、以及供应商源码的放置路径。文档里举例的路径是/home/ql/MT67799/...实际传到别的机器上就无效了必须根据你自己的源码解压路径调整。3.4 兜底方案删掉全部源码重新解压这才是“治本”如果上面三步都试过报错依然存在文档给出的最终方案是把解压出来的所有源文件全部删除重新解压重新安装依赖重新做所有配置修改。这个做法看起来粗暴但在我处理过的编译环境问题里它的成功率反而最高。原因有两个一是编译系统的中间状态文件比如 out 目录、.config 缓存、JACK 的临时缓存可能有残留这些残留不会被make clean完整清除二是某些配置文件只在首次初始化时生成如果初始化时就处于缺依赖状态生成的配置天生就是残缺的。删除重来等于把整个“黑匣子”重置到初始状态。注意删除源码前先确认你的空间和拷贝来源可用否则删了之后重新拷贝又是一轮痛苦。我一般会保留分卷压缩包在共享文件夹里只删除解压出来的目录避免白忙一场。4. ninja 与 fork 报错JACK 服务内存参数和虚拟机内存不足的连环排查4.1 ninja: build stopped: subcommand failed 的定位方法这个报错是 Android 7.0 编译中出镜率最高的一个完整信息长这样ninja: build stopped: subcommand failed. build/core/ninja.mk:148: recipe for target ninja_wrapper failed make: *** [ninja_wrapper] Error 1问题的麻烦在于ninja本身只告诉你子命令失败真正失败原因在它上面的输出里。编译进程多的时候终端滚动速度快真正的错误早就被刷到上面去了。我的排查方法是先重定向输出再回看make -j4 systemimage 21 | tee build.log # 等编译失败后在 build.log 里搜 error、Error、failed grep -in error\|failed build.log | head -5021把标准错误也合并到标准输出tee build.log同时打印到屏幕和写入文件。这里的-j4是并行编译任务数按文档里的建议用 4 而不是 8 或更高等稳定了再往上调。搜索日志时优先看第一个出现的 error因为它往往是根因后面的错误可能只是连锁反应。4.2 JACK_SERVER 内存参数-Xmx4096m 加了没生效改成大写 M 才恢复ninja 报错的子任务失败很大一部分来自 JACK server 崩溃。JACK 是 Android 7.0 用于把 Java 字节码转换为 dex 的编译器它以后台服务方式运行默认最大堆内存偏小编译大型工程时容易 OOM 崩溃。文档给的做法是修改prebuilts/sdk/tools/jack-admin脚本vim prebuilts/sdk/tools/jack-admin找到这两行并修改JACK_SERVER_COMMANDjava -XX:MaxJavaStackTraceDepth-1 -Djava.io.tmpdir$TMPDIR$JACK_SERVER_VM_ARGUMENTS -Xmx4096m -cp $LAUNCHER_JAR $LAUNCHER_NAME JACK_SERVER_VM_ARGUMENTS${JACK_SERVER_VM_ARGUMENTS:-Dfile.encodingUTF-8 -XX:TieredCompilation -Xmx4096m }第一行给 JACK server 主进程追加了-Xmx4096m把最大堆内存提升到 4G第二行是在JACK_SERVER_VM_ARGUMENTS的默认值里也加上同样参数确保通过环境变量传参时生效。-Xmx4096m的m是小写表示 4096 兆字节JVM 参数不区分大小写所以4096M同样有效。文档里有个非常诡异的记录“之前用 -Xmx4096m 很好最近突然又报错了改成 -Xmx4096Mmake clobber 又好了”。这种情况我也遇到过表面看是大小写玄学实际原因多半是修改后没有重启 JACK 服务或者修改被make clobber清理掉。JACK 是常驻服务改完脚本后必须停掉旧进程再启动新进程否则新参数根本不会生效。老进程还占着旧堆内存配置你改一百遍脚本都没用。4.3 fork: Cannot allocate memorypid_max、swap、虚拟机内存三管齐下这个报错出现在编译中后期典型输出是[ 78% 48705/61945] target thumb C: .../isp_function_cam.pipechk.cpp ninja: fatal: fork: Cannot allocate memory build/core/ninja.mk:148: recipe for target ninja_wrapper failed make: *** [ninja_wrapper] Error 1fork是 Linux 创建子进程的系统调用Cannot allocate memory表面看是内存不够但实际不止一个原因。文档给了两个方向一是进程数超过系统上限二是虚拟内存确实不足。方法一针对进程数上限# 查看最大进程数限制 sysctl kernel.pid_max # 查看当前进程总数 ps -eLf | wc -l # 临时调大立竿见影 echo 1000000 /proc/sys/kernel/pid_max # 永久生效 echo kernel.pid_max1000000 /etc/sysctl.conf sysctl -ppid_max控制系统内可以存在的最大 PID 编号也就是进程总数上限。Android 编译会创建大量子进程如果默认 pid_max 是 32768编译过程中进程数冲到上限fork 就失败。ps -eLf | wc -l统计的是线程数如果这个数字接近 pid_max基本可以确定是这个问题。把 pid_max 调到 1000000 是给进程表扩容。方法二针对物理内存不足创建 swap 交换分区# 创建 1G 的 swapfilebs2048 时 count524288 约等于 1G sudo dd if/dev/zero of/swapfile bs2048 count524288 ls -lh /swapfile # 格式化为交换分区 sudo mkswap /swapfile # 启用 sudo swapon /swapfiledd用零填充生成一个 swap 文件bs是块大小count是块数两者相乘就是文件大小。要 512M 就把bs改为 1024 并保持count不变。mkswap格式化swapon启用。这只是临时生效重启会失效需要写入/etc/fstab我在避坑章里会专门提。方法三是把虚拟机内存调到 16G。文档里特别提到“查看虚拟机内存分配只有 6G 左右关闭虚拟机内存调整到 16G编译正常”。这一步要在虚拟机关机状态下修改否则可能无法调整。内存从 6G 调到 16G 看起来幅度很大但 Android 7.0 编译时单是 JACK server 就占 4G 堆内存再加编译进程和系统本身6G 确实捉襟见肘。提示不要同时把 pid_max 调大和 swap 开满先确认是进程数问题还是内存问题。我习惯先跑free -m看可用内存再跑ps -eLf | wc -l对比 pid_max哪个接近瓶颈先处理哪个。4.4 重启 JACK 服务的三步操作make clobber 不能省修改完 jack-admin 脚本后文档给出了固定三步make clobber ./prebuilts/sdk/tools/jack-admin stop-server ./prebuilts/sdk/tools/jack-admin start-servermake clobber相当于深度的make clean删除所有以前编译操作的已有输出包括 out 目录下大量中间产物。文档提示“第一步很重要有时候提示添加了参数实际上没加进去没成功一定记得弄第一步”这说的就是残留编译产物会导致新参数不生效。stop-server和start-server是成对出现的缺一不可。只 stop 不 start后面 make 会重新拉起一个默认参数的 JACK只 start 不 stop旧的 JACK 进程还占着内存和端口改的参数依然无效。顺序也别反了先停再启确认进程 PID 变了再继续编译。5. 避坑四个反复折腾的编译问题与处理记录5.1 同一个虚拟机里放两份源码共用 JACK 工具导致报错现象虚拟机里同时解压了 MT6799 和另一套平台源码编译时报 JACK 相关错误且错误信息飘忽不定有时是端口冲突有时是版本不匹配。原因两个工程共用同一套 prebuilts/sdk/tools/jack-adminJACK server 是按端口和临时目录工作的。第一个工程的 JACK 服务还驻留在内存里第二个工程启动 JACK 时脚本发现端口被占用要么复用旧服务但 jar 包版本不同要么启动失败编译过程就出现各种不可名状的错误。解决删掉其中一份源码保留一份。文档里就是这么做的“报错删除了 MT6779 源码后面就好了”。如果确实需要同时保留两份至少要保证它们使用不同版本的 JACK 工具链或者每次切换工程前都执行stop-server并且用rm -rf ~/.jack*清掉 JACK 在用户目录下的缓存文件。5.2 虚拟机磁盘放在系统盘特殊目录导致权限和整理功能异常现象虚拟机文件安装在 C 盘某些目录启动或访问虚拟机磁盘时提示没有权限Windows 的碎片整理功能也对该目录不可用。原因Windows 对系统盘根目录、Program Files 目录等位置有权限管控虚拟机文件放在这些位置虚拟机进程读取时可能被 UAC 拦截。碎片整理功能只对普通目录开放系统保护目录不参与。解决把虚拟机安装目录改到普通目录文档里的例子是C:\Download。重装虚拟机前先备份配置或者用虚拟机软件的“移动”功能迁移不要直接剪切否则虚拟磁盘路径引用会断。迁移后确认新目录所在磁盘剩余空间至少是虚拟机硬盘大小的 1.5 倍。5.3 swap 文件创建后没有开机自动挂载重启编译又复现内存不足现象编译中创建了 swap 文件当时swapon启用后编译正常但虚拟机重启后再编译又报fork: Cannot allocate memory。原因swapon只对当前会话生效重启后交换分区不会自动挂载。文档里没有写开机挂载步骤这是常识性遗漏。解决编辑/etc/fstab在末尾加上一行echo /swapfile none swap sw 0 0 /etc/fstab写完后用swapon -s查看当前 swap 设备重启后再次用free -m验证 swap 总容量是否包含刚才添加的文件。这一步不补后面每次重启都得手动swapon而且很容易忘记。5.4 make -j 并行度过高内存瞬间被吃满导致 ninja 崩溃现象一开始用make -j8甚至make -j16编译任务管理器显示内存吃满然后 ninja 报子任务失败或Cannot allocate memory。原因-j后面数字代表并行任务数数字越大同时编译的模块越多内存消耗也越大。16G 内存跑-j8在 Android 7.0 环境下已经很勉强-j16基本必爆。文档里推荐-j4做主编译参数不是性能差而是稳。解决把并行度降到 4先跑通一次完整编译之后再尝试-j8并观察内存余量。我更推荐的做法是编译前开一个终端跑watch -n 1 free -m实时盯着内存变化发现 available 低于 2G 就 CtrlC 停掉降并行度重新来。6. 快速定位同一报错第二次遇到时先查这三处再动手编译报错最怕的是病急乱投医。第二次遇到同一报错我的做法是先按“报错关键字 → 首要检查项 → 验证命令”这个顺序走一遍避免反复重编译浪费时间。报错特征首要检查项验证命令TAREGT_BRM_PLATFORM is undefineddevice-vendor.mk 是否被 includegrep -r device-vendor device/ vendor/ --include*.mkninja: build stopped: subcommand failed翻 build.log 里第一个 errorgrep -in error build.logfork: Cannot allocate memory可用内存与进程数上限free -m、sysctl kernel.pid_max、ps -eLfJACK 相关异常JACK 进程状态与运行参数./prebuilts/sdk/tools/jack-admin list-server定位技巧第一条把所有输出写进日志文件再 grep而不是人眼盯着终端滚屏。我每次开始编译必带21 | tee build.log没有例外。定位技巧第二条先用free -m和sysctl kernel.pid_max做硬件体检再用jack-admin list-server确认 JACK 服务状态这两个检查五分钟内能完成能过滤掉一半的报错。硬件和工具链本身没问题再去翻配置文件和 mk 包含链。定位技巧第三条改任何脚本或配置后用make clobber清掉旧产物再重启 JACK这是处理 Android 7.0 编译“改了没生效”类问题的万金油。我见过太多人只改了参数不清缓存花几个小时排查最后发现改的东西根本没被用上。从那次被 fork 报错卡了整整两天、最后靠重装依赖才解决之后我给自己定了个规矩每次编译之前固定花五分钟走一遍硬件检查、JACK 状态检查、日志重定向三步确认环境没有暗病才开始干活。这个习惯帮我省掉的排查时间远比那五分钟多得多。希望这篇整理能让你避开我踩过的坑编译一次过稳定不报错。本文还有配套的精品资源点击获取