简介面向Android发烧友与ROM定制初学者的Android Kitchen V0.223定制工具包由光头佬开发用批处理脚本把解压、修改、打包、签名、刷写等繁琐步骤集成到菜单式操作适合刷机玩家、ROM移植者和入门开发者。版本内置大量机型配置与插件覆盖系统分区处理、boot.img重构、APK签名、Zipalign优化、内核模块提取、恢复模式刷机、备份与还原等关键环节并支持扩展模块延展功能。资源共397个文件以txt说明、c/h源码、plugin插件、jar与apk程序为主另含busybox、zipalign等可执行工具及三星、HTC多机型适配脚本压缩包为rar格式约23.05MB。目前已有598人浏览学习。对希望深入理解Android系统分区、升级脚本与刷机原理的用户它也是一份可反复拆解的实操样本通过梳理脚本流程和内置模块还可直接复用签名、打包、解包等脚本用于个人项目。1. Android Kitchen 是什么一个厨子脚本包解决 ROM 定制的整条流水线刷过机的人应该都经历过这种场景想精简掉系统里的垃圾应用、想换个开机动画、想改一下默认音量步进结果打开 ROM 压缩包发现里面躺着一整个分区的镜像无从下手。Windows 下的 ROM 定制工具大多是图形界面的“黑匣子”你点几下按钮它背后做了什么你完全不知道出了问题也没法排查。而 Android Kitchen 这个小工具走的是另一条路——它是一套由 bash 脚本组成的“厨房”把解包、定制、重新打包这一整条流水线做成菜单式的命令行操作。V0.223 这个版本是 2013 年前后非常活跃的版本系列作者署名“光头佬”在当年的机圈里几乎是做 ROM 定制的手工派标配。这套工具适合两类人一类是想把自己手机系统里的无用应用去掉、又不想用别人做好的精简包的用户另一类是刚开始接触 ROM 制作、想搞懂 image 文件内部到底长什么样的学习者。它解决的核心问题是让不熟悉 Linux 命令的人也能通过一个交互菜单完成从 boot.img 解包到最终 zip 刷机包生成的全过程。本文会从工具原理讲到实战命令最后把我在实际使用中踩过的坑和验证方法一并列出。2. 厨房里有什么目录结构、核心脚本和它的定制理念2.1 解包后的目录像一个后厨工作台把 Android Kitchen 的压缩包在 Linux 环境里解压后你会看到一个结构非常清晰的目录树。它不像现在的图形工具那样把所有功能藏在按钮后面而是把所有中间产物按照工作区、工具区、素材区划分好。顶层目录一般是kitchen/里面有几个固定目录original、working、tools、output还有几个带数字前缀的脚本文件。这套布局从早期版本一直沿用到现在理解它之后你在任何一台机器上都能快速定位问题。cd ~/kitchen ls -FSETUP.sh main.sh menu.sh tools/ original/ working/ output/ utilities/其中的逻辑很直白original放原厂 ROM 包或者解包后的镜像文件working是解包出来的可编辑文件系统output存放重新打包出来的成品。tools目录里是 cmdtools、java、二进制处理程序这些第三方工具比如unpack_bootimg、mkbootfs这些在 Android 系统编译时也会用到的程序。脚本文件menu.sh是整个厨房的交互入口你运行它之后会看到一个数字菜单从解包、编辑、打包到生成可刷入的 zip全部通过菜单选择。这个设计的好处是新手不需要记住所有命令而熟手可以直接绕过菜单调用底层的单个脚本灵活性反而比图形工具高。2.2 为什么这套脚本方案能活这么久Android Kitchen 不是第一个做 ROM 定制的工具但它能在众多替代品里活下来核心原因是它的架构思路对路。它把“解包”和“打包”两步做成了标准化脚本中间的定制过程完全交给用户自由发挥。你在working目录里对文件系统做的任何修改不管是替换 APK 还是修改build.prop回包时都会被完整保留。这种“非侵入式定制”的理念很关键——工具只负责拆开和装回去不负责替你决策改什么因此它永远不会因为预设方案过时而失效。对比同期的 DsiXda Kitchen、Cygnus ROM Kitchen 这些分支版本Android Kitchen V0.223 的差异在于它支持更多的镜像格式和更细的打包选项。比如它对 boot.img 的 ramdisk 压缩方式支持了 gzip、lzma、lzo 等多种选择对 system.img 的挂载方式也做了兼容处理。实践中你会发现真正在定制 ROM 时拉胯的往往不是功能多少而是稳定性。很多工具解包一个几百兆的 system.img 就会卡死或者解出来的文件权限错乱而这套脚本使用标准的 Linux 工具链做底层操作只要运行环境没问题它的成功率非常高。这也是我至今仍在向身边做 ROM 的人推荐它的原因——有些老工具的价值不在于界面华丽而在于它把脏活累活都干透了。2.3 定制前必须搞清楚的镜像格式在动手解包之前你需要知道 Android 系统镜像的两种主要形式。一块是boot.img它由内核kernel和 ramdisk根文件系统拼接而成负责系统启动阶段的工作另一块是system.img它包含了整个 Android 系统目录APK、jar 包、配置全在这里。老设备上system.img常用 yaffs2 文件系统格式新一点的设备则是 ext4 的稀疏镜像sparse image。Kitchen 解包 system.img 时会自动识别文件系统类型如果是 ext4 它会尝试挂载mount而不是直接解压因为稀疏镜像必须通过挂载才能正确处理文件权限。不要小看文件权限这一步。很多人在定制 ROM 时把 APK 放进了working/system/app/回包之后刷进手机发现应用不见了或者系统反复重启十有八九是文件权限没有设置正确。Android 系统目录下的应用要求权限通常是 644目录是 755数据文件可能是 600。在 Windows 下用解压软件直接修改 zip 再回刷出来的包几乎必出问题。Kitchen 之所以值得学就是因为它强制你走 Linux 文件系统这一条正路权限和属主都按规则保留。# 查看 working/system 里一个 app 目录的权限归属 cd ~/kitchen/working/system ls -l app/drwxr-xr-x 2 root root 4096 2025-01-01 10:00 Browser -rw-r--r-- 1 root root 20480 2025-01-05 08:30 Browser.apk如果发现权限不对直接使用 chmod 和 chown 修正这是 Kitchen 工作流里最基本的操作。上面看到的root root表示文件的属主和属组系统应用必须保持这个归属厂商在定制 ROM 时也是遵循同样的规则。3. 把厨房架起来Windows 与 Linux 下的环境准备和第一份菜单3.1 Windows 下用 Cygwin 还是直接上 LinuxAndroid Kitchen 的脚本全部是 bash 写的Windows 本身没办法直接运行。常见的做法是在 Windows 上安装 Cygwin 模拟 Unix 环境或者使用微软的 WSLWindows Subsystem for Linux。我个人的建议是如果你只是偶尔定制一次用 Cygwin 够用如果你打算长期跟 ROM 打交道干脆装一个 Ubuntu 虚拟机或者直接用 WSL2后面的麻烦会少很多。Cygwin 的优势在于它的安装是一次性的不需要重启切换系统但它在处理大文件的 I/O 速度上不如原生 Linux而且在挂载镜像时偶尔会抽风。WSL2 比起 Cygwin 要顺畅不少因为它是真正的 Linux 内核。在 Windows Terminal 里安装 WSL 后直接进入 Ubuntu 发行版然后安装 Kitchen 所需的依赖即可。这里给出一份我在 Ubuntu 22.04 上测试通过的依赖清单sudo apt update sudo apt install -y openjdk-8-jdk unzip zip wget \ cpio python2 bc lzma lzop bison flex \ lib32stdc6 lib32z1默认的 Ubuntu 20.04 和 22.04 都没有预装 Java 8而 V0.223 这个年代的 ROM 定制工具链还依赖signapk.jar来给最终 zip 签名这个 jar 用新版本的 Java 运行会报UnsupportedClassVersionError。解决方案是安装 OpenJDK 8并把它设置为系统默认版本。在 22.04 上可以用下面的命令切换sudo apt install -y openjdk-8-jdk sudo update-alternatives --config java参数说明update-alternatives会列出系统中已安装的所有 Java 版本输入对应数字回车即可切换到 Java 8。这一步不是可选项因为回包后的签名是刷机包能否被 Recovery 接受的前提。有些 Recovery 校验签名很认真签名不过直接拒绝安装。3.2 Linux 原生环境把 Kitchen 解压并跑通主菜单Linux 原生环境下的准备工作要简单得多。下载 Android Kitchen V0.223 的 rar 压缩包后先要安装解压工具。很多人直接卡在这一步因为unrar不是系统默认安装的sudo apt install -y unrar mkdir -p ~/kitchen cd ~/kitchen unrar x ~/Android_Kitchen_V0.223_By_光头佬.rar chmod x *.sh ./menu.sh代码逻辑第一行安装 unrar 用于解压 rar 格式的压缩包然后创建专门的~/kitchen工作目录避免在别处解压导致后续脚本找不到相对路径第三行用chmod x给所有脚本添加可执行权限最后运行menu.sh进入交互菜单。运行后你会看到类似下面的输出 Android Kitchen 1) 设置工作目录 2) 解压 ROM 包 3) 解包 boot.img 4) 解包 system.img ...如果菜单没有正常显示先检查脚本开头的#!/bin/bash是否存在以及当前 shell 是否为 bash。Kali Linux 的默认 shell 有时候是 zsh你需要用bash menu.sh来强制运行。这一步看起来简单但确实有不少人在环境问题上翻车具体原因我会在后面的避坑章里集中解释。3.3 工作区设置与 ROM 包放置规范Kitchen 的菜单第 1 项通常用来设置工作目录。这个步骤的意义是告诉脚本“你接下来要在哪里干活”避免多个项目互相覆盖。如果你只做一个 ROM直接使用默认目录即可如果同时维护好几个设备的 ROM每个设备设置一个独立的工作目录会舒服很多。设置完目录后需要把原厂 ROM 包放置到指定位置。常见的做法是在original/目录下新建一个以 ROM 包名命名的子目录然后把 zip 或者 tar 包放进去。cd ~/kitchen/original mkdir -p my_first_rom cp /path/to/stock_rom.zip my_first_rom/ cd ~/kitchen ./menu.sh菜单里选择解压 ROM 包后Kitchen 会把 zip 里的boot.img、system.img、recovery.img等文件都提取出来放到original/my_first_rom/下。这个“解压 ROM 包”和“解包镜像”是两个不同的步骤前者是解开最外层的刷机包后者是拆开里面的镜像文件。新手经常搞混以为跑了一次就能直接在 working 目录里看到 APK其实是漏了第二步。理解这两者的关系后面才不会乱。4. 厨房开火从解包 system 镜像到改 build.prop 再回包4.1 解包 boot.img 与 ramdisk 的文件结构拿到了原厂 ROM 包接下来的正式操作从 boot.img 开始。boot.img 的结构固定为“头部信息 内核代码 ramdisk 打包文件 第二级引导”Kitchen 脚本可以帮你把它完整拆开。在菜单里选择解包 boot.img 后工具会调用unpack_bootimg将其拆成kernel文件和ramdisk目录。ramdisk 目录里边是一套完整的根文件系统包含init.rc、default.prop、ueventd.rc这些启动时需要的配置。# 解包后的 boot 目录内容示例 cd ~/kitchen/working/boot ls -ladrwxr-xr-x 3 root root 1024 2025-01-01 00:00 . drwxr-xr-x 2 root root 3072 2025-01-01 00:00 kernel drwxr-xr-x 9 root root 1024 2025-01-01 00:00 ramdisk定制 ROM 时解包 boot.img 的主要目的有三个。第一个是修改default.prop部分版本叫prop.default比如把ro.secure改成 0可以让 adb 在开机时直接获得 root 权限这是很多精简包实现预置 root 的方法之一第二个是替换开机动画相关的资源需要修改 ramdisk 内的init.rc来改变开机时的服务执行顺序第三个是如果你的设备要移植第三方内核也需要在这里替换 kernel 文件。注意改完 boot 里的任何文件后回包时都要重新打包 ramdisk否则文件不会生效。4.2 解包 system.img 时遇到 sparse 和挂载失败怎么办system.img 解包是整个定制流程里最敏感的一环。Kitchen 会先检测镜像格式如果是 ext4 的 sparse image它会尝试用simg2img工具转换成原生 ext4 镜像然后再挂载到 working 目录。这里的坑在于部分版本的 Kitchen 里simg2img是从编译工具链里复制过来的有可能与最新的 Android 系统镜像不兼容。表现症状是解包进度走到一半提示file system not recognized或者直接报告 mount 失败。遇到这种情况我一般会手动执行一次挂在当前系统下的转换。你要清楚的是Kitchen 只是一个脚本外壳底层挂载操作的成败归根结底取决于你运行它的系统是否支持对应的文件系统。Ubuntu 默认支持 ext4直接挂载没有问题如果你的系统是精简版的发行版可能需要先补装android-tools-adb和android-tools-fsutils包这两个包里包含了 Google 官方的镜像转换工具。sudo apt install -y android-tools-fsutils cd ~/kitchen/original/my_first_rom simg2img system.img system_raw.img file system_raw.img如果系统提示找不到simg2img命令说明你的发行版在软件源里没有打包这个工具。退而求其次的方法是用 Python 脚本sdat2img来处理新格式的 system.new.dat 文件不过那就是另一套流程了Kitchen V0.223 的菜单直接处理 dat 格式的能力有限后面避坑章我会单独讲到。总之手动转换的思路是让 Kitchen 少干活它解不了包你就帮它先转成它能处理的格式排查问题时要顺着这个思路走。4.3 修改 build.prop定制 ROM 最有价值的单文件操作解包完 system.img 之后你会在working/system/下看到完整的 Android 系统文件树。其中build.prop是对系统显示信息、性能参数、默认属性影响最大的单个文件。它位于working/system/build.prop里面以键值格式保存了很多运行时属性。定制 ROM 时这个文件几乎是必改的一项改之前要先备份一份原始文件给自己留个后悔药。cd ~/kitchen/working/system cp build.prop build.prop.bak vim build.prop比如把设备型号改成自己想要的名字把开机第一屏显示的版本信息改成自定义内容ro.product.modelMyCustomPhone ro.build.display.idKitchen_V0.223_2025参数说明ro.前缀开头的属性在系统启动后是只读的这些值会被系统服务读取并显示在“关于手机”界面上。修改后保存文件即可不需要额外操作。但是要注意ro.product.model这类属性影响 Google Play 的设备认证逻辑如果改成一个不存在的型号可能导致部分应用判定设备不兼容。所以我在实际定制时通常会保留原始型号只改ro.build.display.id这类不影响功能识别的字段。这个细节不算高深但确实是在踩过坑之后才明白的。4.4 精简系统应用的正确姿势与 APK 选择逻辑定制 ROM 的另一个高频需求是精简掉厂商预装的应用。在 working/system 目录里系统应用分散在app/、priv-app/、framework/这几个目录里。通用做法是先看一遍每个目录下的包名区分哪些是核心组件、哪些是厂商添加的推广应用。改动之前做一次全量备份最重要我习惯在精简前把整个 working/system 目录做一次 tar 打包放到原 ROM 旁边出错后几分钟就能还原。cd ~/kitchen/working tar -czf ~/system_backup_$(date %Y%m%d).tar.gz system/ cd system/app ls -l | head -20遇到不确定能不能删的应用我的判断标准是三条第一包名是不是com.android.*核心系统包这类不要动删了大概率开机卡 Logo第二不在app/和priv-app/里的私有框架应用不要去碰它们被其他应用引用删一个可能导致一堆应用崩溃第三如果只是自己日常使用不需要但不确定系统服务是否需要那就先停用而不是删除。精简这件事最怕的不是删多了而是你不知道为什么删多了就开不了机。保留足够多的原始信息出问题时才能快速定位是哪个包导致的重启循环。4.5 回包与签名最后一步决定成不成定制完成后的回包操作在菜单里对应“Build ROM from working folder”选项。Kitchen 会把整个 working 目录按其识别到的原始镜像格式重新封装成新的 system.img 和 boot.img然后再打包成一个可被 Recovery 刷入的 zip 文件。打包完成后输出目录里会出现custom_rom.zip或者类似命名的文件。接下来是最关键的一步签名。cd ~/kitchen/output java -jar ../tools/signapk.jar \ ../tools/testkey.x509.pem \ ../tools/testkey.pk8 \ custom_rom.zip \ custom_rom_signed.zip参数说明signapk.jar是 Android 源码里自带的签名工具接收三个参数依次为公钥证书、私钥文件和待签名 zip输出是第四个参数指定的文件名。Kitchen 里内置了测试密钥这张密钥可以用于个人刷机用途因为 Recovery 在刷入 zip 时会校验签名而默认的测试密钥可以被第三方 Recovery 直接接受。如果需要做公开发布的 ROM得替换成你自己的正式密钥否则别人刷入时如果校验严格会直接失败。5. Android Kitchen 避坑指南环境、权限、版本选择上的 4 个高发问题5.1 Cygwin 下挂载 system.img 失败进度条卡在 98%现象在 Windows 的 Cygwin 环境里解包 system.img日志滚动到将近完成时卡住或者提示mount error但同样的镜像放到 Linux 虚拟机里可以正常解包。原因Cygwin 的 mount 实现是模拟的它对 ext4 文件系统的支持不完整尤其是在处理稀疏镜像和 64 位 ext4 特性时会出现兼容性问题。Kitchen 挂载 system.img 需要真正调用 mount 系统调用而这恰好是 Cygwin 的弱项。解决不要在 Cygwin 里跑解包 system.img 这一步。把原始 ROM 的 system.img 先拷贝到 WSL 或 Linux 虚拟机中完成解包和编辑再把整个 working 目录传回 Windows。如果实在要在 Windows 里工作可以把simg2img转换和debugfs提取作为替代方案但这操作门槛比直接用 Linux 高得多。我的经验是环境不对就换环境别在 Cygwin 上死磕。5.2 回包后刷入手机开机卡在厂商 Logo现象定制好的 ROM 刷入后设备停留在品牌 Logo 界面无法进入系统adb logcat 都没有输出。原因这种情况 90% 是改动的问题不是打包的问题。常见诱发因素有三个一是把app/里的某个核心系统应用删了比如Phonesky以外的系统组件二是修改了build.prop里跟硬件解码器相关的属性导致服务启动死循环三是精简时误删了framework/下的资源包系统 UI 无法加载。解决先用上一步备份的原始 working 目录恢复重新打包一次确认不是你的环境问题。如果恢复原厂就能开机那就是某个改动点的问题采用二分排查法先只改 build.prop回包测试通过后再只精简应用再测试。分成两步而不是一次性改完能快速定位问题所在。另外刷机前尽量保留一个完整的官方 ROM 包在电脑里一旦新包有问题随时可以 fastboot 刷回原厂。5.3 .rar 格式解压脚本报bad magic number现象解压 Kitchen 包时执行.sh文件报错说文件头不对或者 bash 提示cannot execute binary file。原因可能是压缩包解压不完整也可能是文件在传输过程中发生了格式转换。最常见的场景是你在 Windows 下用记事本打开过脚本然后保存过导致文件编码变成 CRLF 换行bash 在执行时读到了\r字符把它当成文件名的一部分。解决用dos2unix把所有脚本和配置文件转换一次或者用编辑器把换行符改回 LF。sudo apt install -y dos2unix dos2unix ~/kitchen/*.sh ~/kitchen/tools/*.jar bash menu.sh这个问题的典型特征是同样的脚本在别人的电脑上能运行到了你这里就报错。如果你有在 Windows 和 Linux 之间来回拷贝文件的习惯这个坑迟早会遇到。写脚本用的换行标准在 Linux 下是 LF不要随便用 Windows 的记事本改动任何.sh文件。5.4 新版 Android ROM 使用 system.new.datKitchen 无法识别现象把新版系统包放进去菜单里选择解包 ROM 后提示找不到 system.img但压缩包里明明有 system 相关的文件。原因Android 5.0 之后的官方刷机包开始广泛使用system.transfer.list和system.new.dat格式它们不再是一个直接的 ext4 镜像而是数据块差分文件。V0.223 年代的 Kitchen 不认识这种格式菜单当然找不到它想要的文件名。解决先用sdat2img工具把system.new.dat转换为system.img然后把转换出来的镜像放回 original 目录再走 Kitchen 的解包流程。这个工具是一个单文件的 Python 脚本在 GitHub 上可以找到运行命令如下python sdat2img.py system.transfer.list system.new.dat system.img参数说明三个参数依次是 transer.list、new.dat 和输出文件名。运行完成后会得到一个 ext4 的完整镜像这时再打开 Kitchen 菜单解包即可。这条路径是我做新机 ROM 定制时最常用的办法它不改变 Kitchen 的内部逻辑只是在输入端多做一步转换变相延长了这套老工具的使用寿命。6. 进阶验证刷入前自查、设备端确认和避免重复踩坑的习惯6.1 回包后用脚本检查 zip 结构与签名完整性不要急着把包刷进手机。我一般会先做两个快速验证第一检查 zip 内部的文件层级是否和官方包一致第二确认签名是否生效。层级不对的话刷进去 Recovery 可能提示安装失败签名不正确部分 Recovery 会直接拒绝。cd ~/kitchen/output unzip -l custom_rom_signed.zip | head -30预期列表里应该能看到boot.img、system.img、META-INF/com/google/android/这几个必备项。路径里缺少META-INF的话刷机包大概率无法被 Recovery 识别。再运行一次签名检查用 Android SDK 里的apksigner验证也可以但更直接的方法是看 zip 里是否已经有签名用的原目录被加入。对于 V0.223 生成的刷机包只要不是在签名前误删了META-INF一般都没有问题。6.2 刷入后的设备端验证不只开机还要看 logcat设备可以开机并不代表定制成功了。系统应用的精简隐藏问题往往会在使用一段时间后才暴露。我的习惯是刷完机后的前十分钟内用 adb 抓取一段 logcat 检查报错信息特别是PackageManager和ActivityManager的输出。刷入后 adb 通常默认可用执行以下命令adb logcat -d -s PackageManager:E ActivityManager:E如果日志里频繁出现Package [com.example.xxx] ... failed或者Unable to start service说明有应用在启动时被其他依赖拖住了。这不一定是坏事只要不影响正常使用那就不用管但如果反复弹“XX 已停止运行”就要考虑把对应应用恢复回去。每次定制完我都习惯把这次的改动记录到一个文本文件里包括删了哪些包、改了哪些属性。下次出了问题翻一下记录比盲猜快得多。6.3 这套工具值不值得继续投入时间用了这么多年我的结论是 Android Kitchen 的思路值得学但直接拿来做现代设备的主力工具已经有点吃力了。它更准确的角色是一个教学工具和通用工作台通过它你能彻底搞懂 boot.img、system.img、ramdisk、签名这些概念之间的关系这份认知迁移到任何现代的 ROM 构建工具上都是有效的。对于追求新设备的用户AOSP 源码编译和super.img分区才是归宿但如果你只是为了把手头的老设备整理得顺手一点V0.223 依然是效率最高的一条路。我自己现在仍然在用它做一件事把老旧设备的系统精简到最低限度去掉所有用不上的服务让只做备用机的手机跑得更轻快。每次在working目录里删掉一个几十兆的预装应用、回包刷进去那种掌控感是图形工具给不了的。所有技艺型的工具都会有类似的宿命——界面会老、格式会变但方法论不会。把 Kitchen 这套思路吃透下次遇到再新的打包格式你也知道该怎么拆开它、改哪里、再装回去。希望帮到你。本文还有配套的精品资源点击获取