企业官网建设流程全解析

简介：这份文档面向需要深度定制Android系统应用的开发者与ROM爱好者，聚焦三星等闭源系统下APK与ODEX文件的合并处理。内容从工具准备讲起，涵盖Android SDK与Java环境搭建、apk manager 4.9的脚本化操作，再到系统应用提取、反编译、修改打包、签名替换的完整链路，并延伸至汉化时语言包取舍与public.xml报错排查等细节。资源包仅含1个docx文档，约23KB，以文字步骤与命令示例为主，适合对照实操。已有334人学习，对想弄清三星自定义framework、绕开签名限制实现系统应用汉化与布局修改的读者，可提供可复用的操作思路与排错参考。

1. 三星闭源 ROM 里改一个系统 APK，为什么绕不开 odex 合并

手里有台老机器，系统是厂商深度定制的闭源 ROM，你想把设置菜单里的英文换成中文，或者把启动器图标换一套。反编译、改资源、重新打包，一套流程走完，adb push回去，重启——应用直接消失，或者无限报错。问题往往不在你改的那几个 XML，而在于系统应用根本不是以纯 APK 形式存在的：代码被抽成了同目录下的.odex文件，APK 里只剩资源和一张空壳classes.dex。这时候谈 apk odex 合并就不是可选项，而是前置条件。

这篇笔记拆的是一个很具体的场景：在有限环境、没有厂商签名、没有完整源码的前提下，怎么把系统 APK 和它的 odex 重新捏回一个可反编译、可修改、可回推的包。适合两类人看——一类是还在折腾老机型 ROM 汉化和主题替换的爱好者，另一类是需要理解 Android 早期应用打包结构、给存量设备做定制的从业者。工具链不新，但里面的判断逻辑和踩坑点，放到今天看系统分区结构时依然用得上。

2. 动手前的环境与文件结构：先搞清楚你在改什么

2.1 系统应用的三件套与 framework 依赖

厂商定制 ROM 的/system/app目录下，一个系统应用通常对应三个东西：Xxx.apk、Xxx.odex，以及可能存在的Xxx.smali中间产物（一般没有）。APK 里装的是resources.arsc、res/资源目录、AndroidManifest.xml和一张占位的classes.dex；真正的 Dalvik 字节码在 odex 里，而且 odex 是针对特定 BOOTCLASSPATH 优化过的，脱离原框架直接反编译会缺类。

更麻烦的是厂商自定义 framework。以文中这类定制系统为例，除了标准的framework.jar，还多出一个twframework-res.apk和配套的twframework.jar。你反编译任何系统 APK 之前，必须先把这套自定义 framework 装进反编译工具的资源表，否则resources.arsc解析会报资源 ID 找不到。这一步不做，后面所有修改都是空中楼阁。

常见做法是先确认目标机型对应的 framework 文件清单。AOSP 基线一般是这几个：

# AOSP 基线 BOOTCLASSPATH 常见组成 core.jar ext.jar framework.jar android.policy.jar services.jar

厂商定制过的还要追加，比如某类定制 ROM 会多出设备相关 jar、相机 jar、硬件抽象 jar、twframework.jar、obex jar、地图 jar 等。这些 jar 不是让你手动加载，而是告诉 smali/baksmali 在反汇编 odex 时去哪里找父类和引用。少一个，反汇编阶段就会抛Could not find class一类错误。

2.2 提取系统文件的两种路径

拿到系统文件有两条路，选哪条取决于你手上有没有 root 权限的机器。

第一条，机器已 root，直接拉：

# 把整个 system 目录拉到本地某个路径，注意末尾斜杠 adb pull /system/ ./system_dump/ # 只取需要的部分时，可以精确到 app 和 framework adb pull /system/app/ ./system_dump/app/ adb pull /system/framework/ ./system_dump/framework/

adb pull对目录要带尾部斜杠，否则在某些 adb 版本上会把目录当文件处理报错。拉下来的文件权限信息会丢，回推时记得用chmod补回 644。

第二条，手上只有官方刷机包，解包挂载：

# 仅 Linux，把 factoryfs 镜像挂到本地目录只读查看 mkdir -p ./factory_mnt sudo mount -o loop,ro factoryfs.rfs ./factory_mnt # 拷贝需要的文件出来 cp -r ./factory_mnt/app ./system_dump/app sudo umount ./factory_mnt

-o loop是把普通文件当块设备挂载，ro是只读挂载，避免误写污染原始镜像。挂载失败常见原因是镜像不是标准 ext 格式，或者内核不支持对应文件系统，这时候换一台环境或者用专门的解包工具处理。

提示：提取阶段就把原始 APK 和 odex 各备份一份，后面无论怎么改，回滚都靠这份原始文件，别指望从改坏的包里还原。

3. apk 与 odex 合并：baksmali 反汇编到 smali 回编译的完整链路

3.1 为什么合并只能走 smali 这条路

市面上有些所谓“一键合并”工具，本质是批处理脚本，底层还是调 baksmali 和 smali。原理不复杂：odex 是优化过的 dex，baksmali 能把它反汇编成 smali 源码目录，smali 再把 smali 目录汇编回一个标准classes.dex，把这个 dex 塞回 APK 替换掉占位 dex，合并就完成了。没有第二条可靠路径，因为 odex 的优化信息（依赖表、寄存器分配）在反汇编时会被丢弃，重新汇编得到的是等价但未优化的 dex，这对修改场景完全够用。

工具准备上，需要 baksmali 和 smali 两个 jar，版本要匹配，混用不同版本会出现指令集不识别的问题。工作目录里同时放好前面列的 BOOTCLASSPATH 那批 jar，baksmali 靠它们解析类型。

3.2 反汇编 odex 与回汇编 dex

先反汇编：

# -x 表示输入是 odex，-d 指定框架 jar 所在目录 java -jar baksmali.jar -x TargetApp.odex -d ./framework_jars/ -o ./out_smali/

参数说明：-x是 odex 模式开关，不加会被当普通 dex 处理然后报 magic 错误；-d指向存放 core.jar、framework.jar、twframework.jar 等依赖的目录，baksmali 会按需加载；-o指定输出目录，不指定默认是当前目录下的out。执行成功后out_smali里是按包名分目录的.smali文件，一个类一个文件。

再回汇编：

# 把 smali 目录汇编成标准 classes.dex，-Xmx 给足堆内存 java -Xmx512M -jar smali.jar ./out_smali/ -o ./classes.dex

-Xmx512M是给 JVM 的堆上限，系统应用类多的时候默认堆容易 OOM，512M 对单个应用足够，遇到超大包可以加到 1G。输出就是一个标准 dex，可以直接替换进 APK。

3.3 把 dex 塞回 APK 并保持资源不动

合并动作本身用压缩工具完成，不需要重新编译资源：

# 用 zip 把新 dex 更新进 APK 副本，-j 表示不保留路径 cp TargetApp.apk TargetApp_merged.apk cd ./dex_out && zip -j ../TargetApp_merged.apk classes.dex

这里的关键是只替换classes.dex，resources.arsc和res/保持原样。因为这一步的目标是让 APK 变成“可反编译的完整包”，资源修改留到下一步用 apktool 或 apk manager 做。合并后的包不需要签名就能被反编译工具读取，但直接安装到系统仍然会因为签名不一致失败——系统应用替换走的是文件覆盖，不是安装流程，这点后面细说。

注意：合并后的 APK 体积会明显变大，因为原来 odex 里的代码现在进了 APK。这是正常现象，不要以为是打包出错。

4. 反编译、改资源、迂回打包：没有厂商签名时怎么回推系统

4.1 安装 framework 与反编译的正确顺序

反编译前先让工具认识厂商 framework：

# apktool 方式，把自定义 framework 装进资源表 apktool if twframework-res.apk # 再反编译目标 APK apktool d TargetApp_merged.apk -o ./TargetApp_src/

apktool if是把 framework 资源安装到本地资源缓存，后续反编译遇到对应资源 ID 才能解析出名字而不是一串数字。用 apk manager 的话，等价操作是把 framework 放到工具指定目录后执行其安装选项，脚本内部调的还是同一套逻辑。

反编译完成后，res/values/strings.xml是界面文案，res/values/arrays.xml是菜单选项数组，res/layout/是布局，res/drawable-hdpi/是当前分辨率素材。改文案就动 strings，改按钮样式就动 drawable 里的 selector XML 和对应图片。

4.2 汉化的边界：哪些能翻，哪些碰不得

汉化不是把所有英文都替换掉。arrays.xml里带_values后缀的条目是程序内部取值用的，翻译了会导致逻辑判断失效，这类必须原样保留。真正要翻的是展示给用户的string条目和数组里的显示项。

建立values-zh-rCN目录时，从values/拷贝strings.xml和arrays.xml过去再翻译，不要直接改values/下的原文件，否则默认语言也被改掉，回退困难。语言目录命名要规范，values-zh-rCN是简体，values-zh-rTW是繁体，写错后缀系统不会加载。

framework 的汉化是另一回事。framework-res.apk里的语言包种类决定了系统设置里语言切换的选项数量，删减时保留values-land、values-port、values-hdpi这类非语言目录，只删values-xx语言目录。地图相关参数要改成对应区域，否则定位和地图显示会异常。这项工作量大且容易越界，译文过长会导致菜单文字显示不全，只能靠反复回推测试。

4.3 迂回打包：keep 目录与原始文件覆盖

没有厂商签名，重新打包出的 APK 签名对不上，直接替换会被系统拒绝。可行做法是“打包取改动、覆盖回原包”：

# apk manager 流程等价操作：编译得到未签名包后 # 用压缩工具打开未签名包和原始包，只把改动过的文件拖回原始包 # 命令行方式示例，把改过的 strings 相关资源更新回原包 cd ./TargetApp_src/build/apk/ zip -r ../../TargetApp_patched.apk res/ resources.arsc

核心思路是：新编译包只作为“改动容器”，最终产物是以原始 APK 为底、替换掉改动文件的包。这样签名区域和未改动部分保持原样，系统校验能过。用 apk manager 时它会生成带unsigner前缀的包，进keep目录把原始文件保留，改过的资源从新包覆盖过去，效果一样。

回推命令：

# 推回系统分区并修正权限，然后重启 adb push TargetApp_patched.apk /system/app/TargetApp.apk adb shell chmod 644 /system/app/TargetApp.apk adb reboot

chmod 644不能省，权限不对系统加载会失败。推之前最好先adb shell mount -o rw,remount /system把系统分区改成可写，否则 push 会报只读文件系统。

5. 避坑与排查：那些让包直接报废的操作

5.1 删语言包后打包报资源不存在

现象：删掉部分values-xx目录后编译，日志报public.xml某行资源不存在，打包中断。

原因：被删语言目录里有该语言独享的 string，values/strings.xml里没有对应条目，资源表引用悬空。

解决：打开日志定位public.xml行号，删除对应行，但保留行号占位避免后续行号错位。更稳的做法是首次不删语言包，确认流程跑通后再逐步删减。日志是唯一可靠线索，不看日志等于盲改。

5.2 反汇编 odex 报找不到类

现象：baksmali -x执行到一半抛Could not find class，输出目录不完整。

原因：BOOTCLASSPATH 缺 jar，通常是漏了厂商自定义的 twframework.jar 或设备相关 jar。

解决：对照原 ROM 的 framework 目录补齐所有 jar 到-d指定目录，重新反汇编。缺哪个类日志会写清楚，按类名反查属于哪个 jar 补进去。

5.3 回推后应用消失或反复崩溃

现象：adb push成功，重启后应用图标没了，或者点开就闪退。

原因：三种可能——权限不是 644、APK 签名区域被破坏、odex 没同步处理。如果只替换了 APK 而系统仍加载旧 odex，类加载会对不上。

解决：先确认权限，再确认是否需要在替换 APK 的同时删除对应 odex（合并后的包已含代码，旧 odex 必须移除或系统优先加载 odex 导致冲突）。操作前用 recovery 备份，出问题直接还原。

5.4 改布局后界面错位

现象：替换 drawable 或改 layout 后，按钮位置偏移、文字截断。

原因：素材分辨率目录不匹配，或者删了hdpi资源但保留了引用。

解决：确认目标机型分辨率对应的 drawable 目录，改图时保持原尺寸比例；删资源前先在public.xml里确认没有引用，删完同步清理引用行。

6. 进阶：用资源对比法把 Froyo 启动器改成姜饼样式

改主题最笨也最稳的办法是拿两个版本的 APK 做资源对比。分别反编译 2.2 和 2.3 的启动器包，保持 2.2 的包在编辑状态，把 2.3 包里同名图片覆盖过去，壁纸和通用图标跳过。然后删掉所有带mdpi后缀的目录，但保留values-hdpi、values-land、values-port这类非语言、非密度专属目录。

第一次打包大概率报错，日志会说某些资源不存在，基本都是被删掉的 mdpi 壁纸引用。去public.xml删对应行，再打包，可能又报某资源 larger 或找不到——这次往往是 hdpi 壁纸数量对不上。继续按日志删，直到打包通过。有个经验规律：hdpi 壁纸数量约等于 mdpi 壁纸数量加上被删掉的 hdpi 壁纸数量，按这个核对能少走几轮。

打包成功后签名安装测试，界面通常已经很接近目标版本，布局微调往往可以省掉。这套对比法的价值在于：它不依赖你理解每个资源的作用，只依赖命名一致性和日志反馈，适合资源量大、文档缺失的闭源包。

我自己的习惯是每次动系统包之前，先在 recovery 里做一份完整备份，改完先推一个测试包验证，确认没问题再批量处理。有一次偷懒跳过备份直接改 framework，结果开机卡动画，只能靠 recovery 还原，从那以后每次回推前都强制走一遍备份和单包验证。希望这些步骤帮到你，少走几轮重启。

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