三星系统APK反编译与ODEX合并：资源报错排查与汉化避坑指南

简介：这份文档面向需要深度定制三星等闭源 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.apk

if是 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 type="string" name="xxx" id="0x7f0a0123" /> <!-- 删除后：保留行，内容清空，避免行号错位 -->

删完重新执行打包，如果还有报错，重复「看 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.xml

resources.arsc是编译后的资源索引二进制，你改了任何values下的内容，它都必须重新生成，所以旧的要删。布局文件同理，你改了res/layout里的 xml，keep里那份旧的会覆盖新编译结果，必须清掉。没改的资源留着，能减少打包体积和出错面。这个机制的本质是「增量替换」，理解这一点，你就不会纠结为什么改了没生效——多半是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 reboot

chmod 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 额外依赖一批 jar，I9000 上还需要：

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 相关的报错虽然花样多，但排查路径是可以固定下来的。我现在的习惯是，任何一次打包失败，先按下面这个顺序过一遍，八成问题在前三步就能定位。

具体操作上，我一般先greplog 里的关键字，把错误归类到「资源」还是「代码」两大类。资源类问题九成出在public.xml和keep目录，代码类问题九成出在 BOOTCLASSPATH 和 smali 回编译。分类之后就不用满世界搜了，直接对着对应章节的步骤走。

验证是否真正修好，别只看打包成功。打包成功只说明编译过了，还要推回机器实测：系统应用推回后chmod 644、重启、进对应界面点一遍。framework 类的改动尤其要测系统菜单和语言切换，因为它的影响面是全局的。我吃过一次亏，打包成功、推回也没 FC，但语言切换里少了繁体选项，回头查是values-zh-rTW被误删且public.xml没清干净，表面正常实则残缺。

从那以后我每次动系统应用，都强制走一遍「备份原始包 → 小步改 → 打包看 log → 推回实测」这个循环，绝不跳步。这套流程看着慢，但比反复刷机还原快得多。希望这些踩坑记录能帮你少走几晚弯路。

本文还有配套的精品资源，点击获取