从零跑通 Apktool:APK 反编译与重编译实操指南
【免费下载链接】ApktoolA tool for reverse engineering Android apk files项目地址: https://gitcode.com/GitHub_Trending/ap/Apktool
Apktool 反编译一个 APK,再把改好的内容重新打包成能装回手机的安装包——它专门干这件事。你手里往往只有别人发来的成品 apk,看不到一行源码,却想改个文案、换个图标、拆段逻辑,那就得先把这个二进制文件拆成能读能改的样子,改完再合回去。
它到底能帮你做什么
这一节你先建立直觉:Apktool 就是在"成品 apk"和"能改的目录"之间做双向转换。
它解决的核心痛点是:APK 是打包好的二进制,代码是 smali 伪代码(Android 字节码的人类可读文本),资源是被压缩过的 XML,人没法直接上手改。Apktool 把它拆成一棵文件目录,你改完目录里的明文,它再帮你原样拼回一个能安装的 apk。定位很明确:用于本地化、加功能、调试 smali,而不是盗版。
看清楚它干嘛之后,先把它跑起来。
从零到第一次跑通
这一节带你走完"装好 → 跑起 → 看到第一个有意义输出"的最短路径。
没有图形界面,所有操作都在终端完成。你只需要一个能跑 Java 的 apktool.jar(Apktool 就是以单个 jar 形式发布的)。
先确认环境里有 Java:
java -version你应看到类似这样三行:
openjdk version "17.0.10" 2024-01-16 OpenJDK Runtime Environment (build 17.0.10+7) OpenJDK 64-Bit Server VM (build 17.0.10+7, mixed mode, sharing)再确认工具本身能跑,看它的版本:
java -jar apktool.jar v你应看到一行版本号:
2.9.3最后拆一个 apk,这是你的第一个有意义输出:
java -jar apktool.jar d app.apk你应看到它逐项解码并收尾:
I: Decoding file 'res/values/strings.xml': I: Decoding AndroidManifest.xml with res parser I: Copying assets and libs... I: Copying unknown files... I: Done核心工作流:三步走
这一节是全文重点,占最大篇幅,把"拆、改、编"的 APK 重编译流程一次走通。
第一步:反编译,把 apk 拆成目录
做什么:把成品 apk 还原成一棵可编辑的文件目录。
怎么做:
java -jar apktool.jar d app.apk为什么:它把压缩的资源表和 dex 还原成明文的资源文件、smali 伪代码和清单文件,只有变成明文,你才有东西可改。
拆完目录,接下来是动它。
第二步:改明文,动你想动的地方
做什么:编辑拆出来的明文文件,只改你真正要改的部分。
怎么做:改文案就打开res/values/strings.xml;改行为就进 smali 目录编辑伪代码。
为什么:这里改的是拆出来的明文和伪代码,不是原始字节,改完才谈得上往回合。
改完之后,最后一步把它拼回去。
第三步:重编译,把目录拼回 apk
做什么:把改过的目录重新打包成一个能安装的 apk。
怎么做:
java -jar apktool.jar b app为什么:它重新生成资源表、重新打包并签名,产出的安装包能直接装回手机。这一步的实际输出大致是:
I: Building resources... I: Building smali... I: Building apk file... I: Copying unknown files from original APK... I: Done到这一步,一个改过的 apk 就完整走完了 apktool 反编译重编译的闭环。
关键配置速查
这一节给你一张速查表,只在需要时才动手。这些字段大多写在反编译目录里的apktool.yml中,少量是命令行开关。
| 配置项 | 默认值 | 作用 | 什么时候需要改 |
|---|---|---|---|
doNotCompress | 空列表 | 指定哪些文件不压缩、原样存进 apk | 重编译后某文件打不开或乱码 |
resourcesInfo.compactEntries | false | 是否用紧凑方式存资源表 | 资源表报错或体积异常 |
sdkInfo.targetSdkVersion | 原值 | 声明的目标 Android API 级别 | 想让改过的包声明更高兼容等级 |
usesFramework.ids | 按原 apk 记录 | 依赖的系统框架 id 列表 | 解/编基于 framework 的系统级 apk |
--debuggable | false | 给新包开启调试开关 | 要在设备上联调、抓日志 |
--res-resolve-mode | default | 资源解析力度 default/greedy/lazy | 资源引用解析不全或反编译偏慢 |
-j(jobs) | CPU 核心数(≤8) | 并行任务数 | 大 apk 反编译或重编译太慢 |
--keep-broken-res | false | 有资源解析失败时仍保留 | 想留着被丢弃的资源手动修 |
平时这些配置默认值就能用,你基本不用碰。只有当你要改一个系统级 apk(依赖框架,得先补usesFramework),或者重编译后某个文件解压出来坏了(往doNotCompress里加它)时,才需要打开apktool.yml动一动。比如把某个.ttf字体加进不压缩列表,再重新编译一次就好。
几个容易踩的坑
这一节是真实高频踩过的坑,照着排雷就行。
输出目录已存在→ 拆 apk 时提示目标目录已存在,直接卡住不继续。解法:加-f强制覆盖,或先把旧的输出目录挪走再拆。
凭空建目录再重编译→ 自己手建了一个空目录想往里塞文件,一编译就因缺少apktool.yml元信息而失败。解法:重编译的输入必须是d反编译出来的那棵目录,别自建;改版本号时记得versionInfo要同步。
缺框架导致资源编不过→ 解/编系统级 apk 时报 framework 找不到、资源引用缺失。解法:先执行if把对应 framework 装进框架目录,或用-p指定框架文件路径,再重试重编译。
你的第一个 apk 拆开了,接下来打算改哪一行?
【免费下载链接】ApktoolA tool for reverse engineering Android apk files项目地址: https://gitcode.com/GitHub_Trending/ap/Apktool
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考