简介这份文档面向需要深度定制三星等闭源 Android 系统应用的中高级玩家与 ROM 爱好者聚焦 APK 与 ODEX 的合并处理解决系统应用在缺少源码、签名受限条件下难以反编译、修改与回编的痛点。资源包共 1 个 docx 文件约 23KB以图文步骤形式记录工具准备、系统应用提取、反编译与打包、签名替换及汉化修改等环节并穿插 apk manager 脚本选项、keep 目录处理、语言包删除报错等实操细节。已有 334 人学习适合作为动手前的流程参照与排错思路参考帮助读者理解闭源系统下修改系统应用的迂回方案与风险边界。1. 反编译报错 resource not found先别急着删语言包改三星系统 APK 的人十个里有八个卡在同一句报错上resource not found后面跟着public.xml的某个行号。你只是想删掉几个用不上的语言包结果打包直接翻车apk manager 窗口一闪log 里红字一片。这类故障在闭源 ROM 定制里极其常见尤其是三星这类带自定义 framework 的机器——它不像 CM 那样源码在手、改完单独编译就行你面对的是已经编译好的二进制包任何资源删减都可能牵动public.xml的索引。这篇笔记适合正在折腾系统应用汉化、布局替换、APK 与 ODEX 合并的开发者新手能照着命令走通熟手能看到资源索引和 BOOTCLASSPATH 这些根因层面的东西。2. 反编译就失败framework 没装对APK 根本解不开很多人第一步就翻车把 APK 丢进 apk manager选 9 反编译结果报一堆资源解析错误或者解出来的res目录残缺。这不是工具坏了是反编译环境没搭对。三星系统应用依赖它自己的 framework 资源你不先把twframework-res.apk注册进去apktool 解析drawable/xxx、string/xxx这类引用时找不到定义自然解不完整。2.1 先装 framework再谈反编译三星 I9000 的 FROYO 系统里除了标准的framework-res.apk还多了一个/system/framework/twframework-res.apk。这是三星自定义的资源包系统应用大量引用它里面的图片、样式、菜单资源。反编译前必须先安装# 进入 apktool 所在目录先注册三星自定义 framework java -jar apktool.jar if twframework-res.apk # 如果目标 APK 还引用了标准 framework也一并装上 java -jar apktool.jar if framework-res.apkif是 install-framework 的缩写它把 framework 包解析后缓存到用户目录下的apktool/framework/里后续反编译时 apktool 会按包名和版本号去匹配资源。参数说明twframework-res.apk必须来自你当前这台机器的同一个 ROM 版本跨版本混用会导致资源 ID 对不上反编译出来的引用全是错的。常见做法是先从手机里adb pull /system/framework/把整个目录拉下来确保 framework 和你要改的 APK 同源。用 apk manager 的话它内部也是调 apktool但脚本不会自动帮你装 framework。所以要么先在命令行手动执行上面两条要么把 framework 放到 apk manager 的other目录里按它的提示装。我一般习惯先用命令行确认 framework 装成功再进 apk manager 操作省得脚本报错时你还得猜是环境问题还是包本身的问题。2.2 提取系统应用的两种路径framework 装好后得把目标 APK 弄到电脑上。有 root 权限的机器直接拉# 拉取整个 system/app 到本地某个路径 adb pull /system/app/ /your/local/path/app/ # 单独拉某个应用和它的 odex adb pull /system/app/TouchWiz30Launcher.apk adb pull /system/app/TouchWiz30Launcher.odex没有 root 或者想从刷机包入手就解官方包挂载factoryfs.rfs# Linux 下挂载 factoryfs 镜像到指定目录 mkdir -p /mnt/factoryfs mount -o loop,rw factoryfs.rfs /mnt/factoryfs # 之后从 /mnt/factoryfs/app 里拷贝文件-o loop表示把普通文件当块设备挂载rw是可读写其实只读拷贝用ro更安全。挂载完app目录下的 APK 和 ODEX 就是你要的原料。注意从刷机包提取的文件和手机里现存的可能因为 OTA 更新有版本差异改之前确认一下版本号别拿旧包改完推回新系统那又是一轮莫名其妙的 FC。3. 打包报 public.xml 行号不存在删语言包的连锁反应这是最经典的坑也是第 1 章那句报错的完整根因。你反编译完看到res下几十个values-xx语言包心想只留英简繁其余全删干净。结果一打包log 告诉你public.xml第 N 行引用的资源不存在。为什么因为public.xml是资源 ID 的索引表每个资源在编译时被分配了一个固定 ID你删掉了某个语言包里的独有字符串但public.xml里还留着它的条目打包器按图索骥找不到实体直接报错。3.1 看 log 定位按行号精准删处理这类报错的唯一正确姿势是读 log不是猜。apk manager 打包失败后去它主目录下找日志文件里面会明确写出哪一行、哪个资源名缺失# apk manager 的日志一般在主目录打包失败后立刻查看 cat log.txt | grep -i public.xml # 输出类似public.xml:1245: error: resource string/xxx not found拿到行号后打开res/values/public.xml定位到那一行删掉整个public条目。关键细节删的时候保留行号占位也就是把该行内容清空但别把行删掉否则后面所有行号整体上移你之前记的行号全错位越删越乱。我一般会在那一行留个空行或者注释等全部处理完再统一清理。!-- 删除前 -- public typestring namexxx id0x7f0a0123 / !-- 删除后保留行内容清空避免行号错位 --删完重新执行打包如果还有报错重复「看 log → 定位行号 → 删条目」这个循环。通常删语言包产生的缺失条目不会太多两三轮回合就能清干净。这里有个血泪经验别一次性把所有语言包删完再打包先删一个、打一次包、看一次 log确认没问题再删下一个。批量操作看着快出错时你根本不知道是哪个包牵出来的资源。3.2 keep 目录的取舍规则apk manager 打包时会进keep目录这里放的是原始 APK 里需要保持原样的文件。规则很直接你改了什么就从keep里删掉对应的旧文件让新编译的版本生效。# 改了 values 下的语言包删掉旧的 resources.arsc rm keep/resources.arsc # 改了 layout 或 xml 目录下的布局文件删掉对应的旧 xml rm keep/res/layout/xxx.xmlresources.arsc是编译后的资源索引二进制你改了任何values下的内容它都必须重新生成所以旧的要删。布局文件同理你改了res/layout里的 xmlkeep里那份旧的会覆盖新编译结果必须清掉。没改的资源留着能减少打包体积和出错面。这个机制的本质是「增量替换」理解这一点你就不会纠结为什么改了没生效——多半是keep里的旧文件把它盖回去了。3.3 无签名迂回拖回原包再 push三星的系统签名你拿不到所以打包出来的 APK 是未签名的直接装必然签名冲突。迂回方案是用压缩工具同时打开未签名包和原始 APK把改过的文件从新包拖到原包里覆盖保持原包的签名结构不变。# 打包产物在 place-apk-here-for-modding 下带 unsigner 前缀 # 用归档工具打开两个包把修改过的 res 文件拖回原始 apk 覆盖 # 然后推回系统并重启 adb push your.apk /system/app/your.apk adb shell chmod 644 /system/app/your.apk adb rebootchmod 644别漏系统应用的权限是rw-r--r--权限不对系统加载时会拒绝。这个方案的前提是你只改了资源文件图片、xml、语言包没动classes.dex。一旦涉及代码修改就必须走 ODEX 合并那条路光拖资源是不够的。4. APK 与 ODEX 合并smali 拆包再回填的完整链路系统应用如果带.odex说明它的classes.dex已经被抽出来做了预优化APK 里根本没有 dex。你想改代码或者重新打包成可用的形式就必须把 ODEX 还原成classes.dex再塞回 APK。目前靠谱的方案只有 smali 这一套所谓各种「一键合并工具」底层都是批处理调它。4.1 baksmali 拆 ODEX 为 smali# 把 odex 反汇编成 smali 目录 java -jar baksmali.jar -x TouchWiz30Launcher.odex # 执行后当前目录生成 out/里面是按包结构组织的 smali 文件-x表示对 odex 做反汇编deodex 的第一步。这一步依赖 BOOTCLASSPATH因为 odex 里的指令引用了框架类baksmali 需要知道这些类在哪才能正确解析。如果 BOOTCLASSPATH 不全会报class not found或者解析出错误的引用。4.2 BOOTCLASSPATH 必须补齐厂商定制 jar标准 AOSP 的 BOOTCLASSPATH 是这几个core.jar, ext.jar, framework.jar, android.policy.jar, services.jar但三星定制 ROM 额外依赖一批 jarI9000 上还需要com.samsung.device.jar, seccamera.jar, sechardware.jar, twframework.jar, javax.obex.jar, com.google.android.maps.jar最省事的做法是把这些 jar 直接从手机/system/framework/拉下来丢到 smali 工作目录然后用-d指定依赖目录或者用-c显式给 classpath# 把所有依赖 jar 放同一目录反汇编时指定 java -jar baksmali.jar -x TouchWiz30Launcher.odex -d ./framework_jars/漏掉厂商 jar 是这一步最常见的翻车点报错往往很隐晦比如某个invoke指令解析失败或者 smali 里出现一堆UNKNOWN引用。判断方法如果反汇编出来的 smali 里大量类名解析不出来先回头检查 BOOTCLASSPATH 是不是只给了 AOSP 那五个。4.3 smali 回编译成 classes.dex# 把 out 目录重新汇编成 classes.dex java -Xmx512M -jar smali.jar out -o classes.dex-Xmx512M给 JVM 512MB 堆大应用比如 launcher、framework回编译时内存不够会 OOM这个参数按机器情况可以往上调。out是上一步 baksmali 生成的目录-o指定输出文件名。生成的classes.dex就是可以塞回 APK 的代码文件。回填时把classes.dex加到 APK 根目录同时删掉原来的.odex引用如果系统还按 odex 加载需要一并处理。这一步之后 APK 就变成了「deodex 后的完整包」可以正常反编译改代码、重新打包。注意deodex 后的包首次启动会慢一些因为系统要重新做 dex 优化这是正常现象不是坏了。5. 汉化与布局替换的避坑清单前面把环境、打包、合并的链路走通了真正动手改内容时还有一批坑等着。这一章按「现象 → 原因 → 解决」列几条我踩过的都是改三星系统应用时高频出现的。5.1 删了语言包打包报资源缺失现象删掉values-it、values-en-rUS后打包log 报public.xml某行资源不存在。原因这些语言包里有values/strings.xml没有的独享字符串public.xml仍保留其 ID 条目。解决按第 3 章的流程看 log 定位行号删对应public条目保留行号占位。别图省事整段删行号错位会让你反复误删。5.2 改了布局没生效界面还是老样子现象改了res/layout下的 xml打包推回重启界面纹丝不动。原因keep目录里旧 xml 覆盖了新编译结果。解决改哪个 xml 就从keep/res/layout/删哪个再打包。判断依据是「改了什么删什么」没改的别动。5.3 framework 汉化后开机 FC现象改完framework-res.apk推回重启直接进不去系统反复 FC。原因framework 资源被系统全局引用某个字符串或尺寸改错、资源 ID 冲突整个系统 UI 起不来。解决改之前把原始framework-res.apk做成刷机包备份FC 就进 recovery 还原改一点测一点别一次改完再推。汉化 framework 是苦活字符串过长还会越界显示不全得对照实际界面调。5.4 替换图片后按钮状态错乱现象换了drawable-hdpi里的按钮图按下、聚焦状态显示不对。原因按钮的三种状态normal/pressed/focused在drawable下的 selector xml 里定义你只换了图没对齐命名或者把 selector 引用的资源名改错了。解决先看 selector xml 里drawable/xxx_pressed这些引用名替换时保持文件名一致新增图片要在public.xml对应类别末尾加条目。5.5 跨版本移植资源打包报 larger 或找不到现象把 2.3 的 launcher 资源往 2.2 上搬打包报某资源 larger、某资源找不到。原因不同版本drawable密度目录和壁纸资源数量不一致你删了 mdpi 资源但public.xml还引用着。解决对比两个版本的资源清单删掉public.xml里指向已删资源的条目壁纸这类资源如果 hdpi 和 mdpi 数量对不上保留全部壁纸别删能绕开大部分报错。6. 快速定位这类问题的排查顺序折腾久了会发现APK 与 ODEX 相关的报错虽然花样多但排查路径是可以固定下来的。我现在的习惯是任何一次打包失败先按下面这个顺序过一遍八成问题在前三步就能定位。排查步骤看什么典型结论1. 看 log 首行错误类型resource not found/class not found/larger资源缺失走 public.xml类缺失查 BOOTCLASSPATH2. 确认 framework 是否同源apktool if装的是不是当前 ROM 版本跨版本 framework 导致引用全错3. 检查 keep 目录改过的文件旧版本是否还在旧文件覆盖新编译结果4. 核对 public.xml 行号log 行号与文件是否对齐行号错位导致误删5. 验证 BOOTCLASSPATH厂商 jar 是否齐全漏 jar 导致 smali 解析失败具体操作上我一般先greplog 里的关键字把错误归类到「资源」还是「代码」两大类。资源类问题九成出在public.xml和keep目录代码类问题九成出在 BOOTCLASSPATH 和 smali 回编译。分类之后就不用满世界搜了直接对着对应章节的步骤走。验证是否真正修好别只看打包成功。打包成功只说明编译过了还要推回机器实测系统应用推回后chmod 644、重启、进对应界面点一遍。framework 类的改动尤其要测系统菜单和语言切换因为它的影响面是全局的。我吃过一次亏打包成功、推回也没 FC但语言切换里少了繁体选项回头查是values-zh-rTW被误删且public.xml没清干净表面正常实则残缺。从那以后我每次动系统应用都强制走一遍「备份原始包 → 小步改 → 打包看 log → 推回实测」这个循环绝不跳步。这套流程看着慢但比反复刷机还原快得多。希望这些踩坑记录能帮你少走几晚弯路。本文还有配套的精品资源点击获取