企业官网建设流程全解析

Apktool 入门指南：反编译安卓 APK、修改资源并重新打包

【免费下载链接】ApktoolA tool for reverse engineering Android apk files项目地址: https://gitcode.com/GitHub_Trending/ap/Apktool

Apktool 是一个用于逆向工程闭源 Android 应用的命令行工具：它能把 apk 里的二进制资源还原成接近原始形态的可编辑 XML，把 dex 字节码还原成 smali 汇编，让你在改完后再重新构建出一个新的 apk。整个"解包 → 修改 → 回包"的循环在一个项目目录里就能完成，不需要先拿到应用的源码工程。

把 apktool 装到你的机器上

Apktool 是一个 Java 程序，安装本质上就是"有一个 jar 包 + 一个能跑它的 JDK"。最省事的方式是直接用预编译版本：macOS 上brew install apktool一行搞定；其他系统可以从源码构建，或从发行说明里找到对应平台的 jar 包。从源码构建只需要 JDK 17 以上：

git clone https://gitcode.com/GitHub_Trending/ap/Apktool cd Apktool ./gradlew build shadowJar

构建完成后会得到一个 fat jar（脚本约定命名为apktool_x.x.x.jar）。仓库里 scripts/linux/apktool 这类包装脚本做的事就是帮你执行java -jar apktool.jar，你把它和 jar 放一起，之后就能像系统命令一样直接敲apktool。装好后用apktool v看版本、apktool help看全部命令，确认工具链就绪。

apktool 解包一个安卓应用

解包用d（decode）子命令：

apktool d -o my_app_src my_app.apk

它会做四件事：把classes.dex系列反汇编成smali/目录下的 smali 文件；把res/和resources.arsc解码成可读的 XML 和资源文件；把二进制的AndroidManifest.xml转成文本 XML 放在根目录；把assets/、lib/等原样拷出来，同时把META-INF存进original/、无法识别的文件存进unknown/。最后生成的apktool.yml记录了解包元信息，回包时靠它还原原始配置。这几个步骤在 ApkDecoder.java 里是按"源码 → 资源 → 清单 → 原始文件"的顺序串起来的。

几个常用的参数可以按需加：-f在输出目录已存在时强制清空重建；-s跳过 smali 只解资源（只想看清单和资源时很快）；-r反过来不解资源；-j 4开 4 个线程并行处理大 apk；只关心清单时可以加--only-manifest。🔧

把修改后的项目重新打包成 apk

改完文件后，b（build）子命令负责回包：

apktool b my_app_src -o rebuilt.apk

它的内部流程是：先用 smali 把smali/重新汇编回 dex，再调用 aapt2 把解码出来的 XML 和资源重新编译成resources.arsc和二进制清单，最后把所有内容按apktool.yml记录的压缩策略（哪些文件不能压缩）装回 zip。注意 3.x 版本只支持 aapt2，旧的 legacy aapt 会被直接拒绝，仓库还专门从 AOSP 编译了一个放宽了校验规则的定制版 aapt2 随发行包分发（构建细节见 INTERNAL.md）。

常用参数：-f跳过变更检测、强制重建所有文件（大改动时更稳）；--debuggable会在构建时把AndroidManifest.xml里的android:debuggable直接置为 true，方便调试版安装；--no-crunch关闭资源 crunching，构建更快但产物更大。另外要心里有数：b命令只负责打包，产出的 apk 是没有签名的，安装前还需要走一遍签名和 zipalign 对齐的流程（apksigner 工具即可），这一步 apktool 本身不代劳。

解包失败时安装 framework 依赖

有些应用（常见于银行、安全类 App）引用了私有共享库或自定义 framework apk，直接apktool d会报 framework 缺失。这时先把那个 framework apk 安装进本地库：

apktool if vendor_framework.apk apktool d -p ./framework my_app.apk

if（install-framework）把 framework 解码后存到~/.local/share/apktool/framework（可用-p指定其他位置），之后解包时带上-p指向该目录，资源里的引用就能正确解析。配套还有lf（list-frameworks）列出已安装的 framework、cf（clean-frameworks）清理它们，以及-l 包名:文件参数用于把某个 shared library 挂进解析上下文。如果某些资源解码时报错被丢弃、但你仍然想要它们，可以加--keep-broken-res硬解，代价是回包前得手工修复。

常见玩法：改文案、调清单、读 smali

给应用做本地化是最高频的用途：解包后直接编辑res/values-zh-rTW/strings.xml把文案换成繁体中文（缺文件就从values/复制一份加限定词目录），然后apktool b回包，改动只涉及资源、不碰代码，风险很低。安全审计或学原理时，打开smali/逐层看字节码即可定位逻辑；想进一步转成 jar 或 Java 伪代码，再配合 dex2jar、JADX 这类工具做二次阅读。调整权限、改package名、去掉某个 Activity 导出声明，则是在根目录的AndroidManifest.xml上直接动手——因为清单已被解码成文本，改起来和改普通 XML 没区别。⚠️ 动手前备份原始 apk，遇到做了壳或资源加密的应用时解包大概率失败，这不是 apktool 的 bug，它的定位是"保持与原始结构尽量一致"，而不是修复任意损坏的包。

源码结构与周边生态

想看实现的话，代码组织得很清晰，模块划分见 settings.gradle.kts：核心逻辑在 brut.apktool/apktool-lib/（ApkDecoder/ApkBuilder/资源表解析器都在brut/androlib/下），brut.apktool/apktool-cli/src/main/java/brut/apktool/Main.java 只是命令行入口；brut.j.util、brut.j.dir、brut.j.xml、brut.j.yaml是它自建的目录、XML、YAML 小库。字节码能力全部来自 gradle/libs.versions.toml 里声明的 smali/baksmali 依赖，测试套件（BuildAndDecodeApkTest等，位于 apktool-lib/src/test/）覆盖了多 dex、压缩策略、清单变更等边界情况，是理解各子命令行为的最好教材。

周边的自然搭配：用 ProGuard 产物配合 dex2jar/JD-GUI 做代码层分析，用 apksigner 处理签名，用 jadx 当"图形版只读 apktool"。未来方向（资源 ID 自动重映射、split apk 支持等）记录在 ROADMAP.md 里。更多参数细节以apktool help输出和仓库 README.md 指向的官方文档为准，动手改包之前先备份原文件，基本就不会翻车。📦

【免费下载链接】ApktoolA tool for reverse engineering Android apk files项目地址: https://gitcode.com/GitHub_Trending/ap/Apktool