apk-reverse 的 Split APK 与 App Bundle 处理完全指南签名、合并与安装【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverseapk-reverse 是一款面向 Android APK 逆向分析的开源 Skill 工具集它对 split APK 与 App Bundle应用包拆分集合的处理尤为完整——从提取、统一签名到单文件合并与安装覆盖全流程。本文用新手也能读懂的方式带你理解 App Bundle 拆分包的本质掌握统一重签名与合并成单个 APK两条路线的取舍并看懂安装被拒时每一种报错背后的真实含义。 核心关键词apk-reverse·Split APK·App Bundle·统一签名·合并 APK·安装被拒一、什么是 Split APK 与 App Bundle为什么应用不是一个文件普通开发者在应用商店看到的往往是一个base.apk。但Google Play 和多数手机厂商应用商店上架的是 App Bundle设备最终收到的是一组 APK成员类型Manifest 里的split标记实际携带的内容base基座无全部classes*.dex、主resources.arsc、真实applicationABI 拆分config.arm64_v8a等仅lib/架构/*.so动态库密度拆分config.hdpiconfig.xxxhdpi自己的resources.arsc和res/资源语言拆分config.en、config.zh自己的resources.arsc字符串功能拆分feature_x自己的classes*.dex可能还带资源关键在于这组文件共享同一个包名、各带一份签名而包管理器把它们当成一个应用。这就是新手最常误解的地方——你以为自己在处理一个 APK其实是一整套。二、新手最容易踩的两个假性坏包坑把这套集合当成单个 APK 处理会引发两类失败而它们看起来像构建坏了其实根本不是只给 base 签名整组文件的证书不一致安装器会拒绝整组报错还会点名包名而非你漏签的那个成员。直接合并成一个 APK只有携带代码或动态库的成员才能免费折进去。携带资源的成员无法在不合并resources.arsc的情况下塞进 base——而资源表合并是资源编译器的工作不是字节级改动能做到的。[repack.py](https://link.gitcode.com/i/04c4a4704e7b9b64dea8621e4e85f30b)会帮你拒绝猜测先清点集合、判断哪条路线合法、打印原因然后才动手。三、从设备提取 Split 集合想确认一个应用是不是拆分集合最直接的办法是看pm path的输出——一行对应一个成员返回多行就是拆分集合adb shell pm path 包名 # 返回多行即为 split 集合几个新手要记住的要点成员文件通常并排放在同一目录把整个目录拷出来即可。adb pull 目录会在目标下多套一层子目录repack.py --split-dir会递归查找正好应对这一点。第三方 App 很少以拆分形式出现在普通 ROM 上系统预装组件反而更常见——这是正常现象不是你操作错了。⚠️ 不要用自己的包名重新安装拉下来的集合来测试它已装在该设备上、且属于你并不持有的厂商证书安装必然失败且这个失败与你的流程无关。四、核心决策合并成一个还是统一重签名先跑一次只读分析它不写任何文件只用文字告诉你哪条路线合法以及原因python skills/apk-reverse/scripts/repack.py --split-dir 集合目录/ --split-mode analyze下面这张决策速查表能帮你 90% 的情况做对选择你的处境推荐路线原因非 base 成员只带代码和/或lib/空资源表也算合并 merge没有需要资源表的东西要搬任一成员携带res/条目或真实资源表重签名 resign资源合并需要改写整张表既要保持可安装、应用又以 Bundle 形式分发重签名这正是应用商店的做法集合仍是集合只想要一个文件侧载/喂给某个工具合并若合法唯一能得到单一产物的方式成员声明isFeatureSplittrue且同时带 dex 和资源重签名代码能折、资源不能半合并产物更糟五、路线一统一重新签名最稳妥强烈推荐⭐这是永远有效的路线每个成员去签名 → 重写为 4 字节对齐的归档 → 用同一个 keystore以v1v2v3签名。python skills/apk-reverse/scripts/repack.py \ --split-dir 集合目录/ --split-mode resign \ --split-out-dir 已签名目录/ \ --ks key.jks --apksigner apksigner 路径通过标准不是每个文件都能 verify而是整组共用一张证书。工具会逐成员校验并打印每份文件的签名指纹理想输出形如[result] OK: 8 members, one certificate (sha256 1eb31d9c…2c44)然后连 base 在内整组安装adb install-multiple -r 已签名目录/*.apk两条新手须知签名必须覆盖每一个成员--abi/ 密度选择发生在安装时而非签名时——所以全都签让安装器去挑详见 split-apk.md §4。顺序不能反先对齐、再签名。apksigner只在归档里追加签名条目若像jarsigner那样在签名后重写 zip会破坏 Android R 要求的resources.arsc对齐。六、路线二合并为单个 APKpython skills/apk-reverse/scripts/repack.py \ --split-dir 集合目录/ --split-mode merge --out merged.apk \ --abi arm64-v8a --ks key.jks --apksigner apksigner 路径什么会被折进去classes*.dex成员的classes.dex会被重命名为classes2.dex保留 base 自己的 dex 不动、lib/**、assets/**。什么不会res/**和resources.arsc。 为什么不尝试合并资源resources.arsc是一张索引表全局字符串池 类型分块每个资源用(包, 类型, 条目)三元组标识、字符串靠池偏移引用。把成员表折进 base意味着要双向改写池偏移、类型/条目计数和每串对齐——那是aapt2 link的活不是字节级编辑。它造成的失败最隐蔽归档结构合法、能装上然后把资源 id 解析到错误的条目或空。当集合确实带有资源拆分、你却必须交付单文件时诚实的做法有三条详见 split-apk.md §5用原始.aab跑bundletool build-apks --modeuniversal唯一能正确合并资源的路线保留拆分集合整组安装用--drop-split-resources接受降级并在交付时如实说明。七、安装被拒的 7 种信号速查表新手看到报错常会对号入座错文件。记住INSTALL_FAILED_INVALID_APK是一个家族不是单一错误——先看冒号后的文字再归因。报错信号它真正在说归属判断...signatures do not match...正在装的集合与设备已装的证书不同不是坏包用原密钥重签或装到尚不存在的包名INSTALL_FAILED_ALREADY_EXISTS/UPDATE_INCOMPATIBLE同包不同签名或未加-d的降级拉下来的系统组件不能装回它自己INSTALL_FAILED_MISSING_SPLITbase 声明isSplitRequiredtrue且集合不完整——或你合并了它base 说的是真话它期望有成员...split ... has different signature集合中某一个成员签名与其余不同正是只签 base的失败形态请签整个目录[-124: resources.arsc ...]某成员的resources.arsc被压缩或未对齐逐成员报错repack.py签名前会逐成员报告[-99]或纯数字码OEM 安装器拦截器拒绝了请求与集合无关改用 root 的pm install-multiple路径完整解读见 split-apk.md §6。八、ABI 与屏幕密度匹配设备会告诉你自己能跑什么getprop ro.product.cpu.abilist。新手最容易混淆的是分隔符split 名用下划线config.arm64_v8alib/目录用连字符lib/arm64-v8a/。映射是替换而非查表——arm64_v8a→arm64-v8a这正是--abi arm64-v8a能匹配到config.arm64_v8a的原因。四条规则64 位设备仍能装 32 位集合并以 32 位运行ABI 拆分由安装器选择--abi只用于合并把选择烧进单个文件不带--abi合并会把所有 ABI 成员全折进去得到一个合法但更大的单文件单设备交付毫无意义getprop报告的是设备声称能跑的真正跑的是实时的映射问题。九、常见陷阱与最佳实践resources.arsc归谁携带谁拆分集合里它是逐成员的base 的表并不包含密度成员的条目。只读 base 就下资源存在的结论是错的。extractNativeLibsfalse现代 targetSdk 默认.so直接从归档 mmap必须未压缩且页对齐——这就是zipalign -p存在的原因。合并 native 成员后若未按此对齐写入会得到能装、启动即死在 linker。40 字节的占位resources.arsc不是资源拆分。用有没有 arsc做判据会拒绝一次完全合法的合并正确判据是*res/有条目或表大于 1 KB*。别在签名后再zipalign去修它会重写归档并作废签名。先对齐再签名。十、工具与延伸阅读想深入每一步的原理与实测证据建议按以下顺序阅读 完整参考本文所有结论的出处split-apk.md 实际执行的脚本repack.py--split-mode analyze / resign / merge 实测验证记录两个真实集合逐字节复现EXTENSION-split-apk.md 重打包与签名通用规则repack-and-sign.md 症状到文档的路由索引routing.md 回归基准矩阵含本主题 B9 行的实测强度标注tests/benchmark.md 技能入口SKILL.md获取项目仓库只读请勿直接修改/新增/删除内容git clone https://gitcode.com/gh_mirrors/ap/apk-reverse️免责声明本项目仅用于学习、研究与授权的安全测试。请只在你拥有分析权或已获得许可的应用上操作分析无权的软件在部分地区可能违法责任由使用者自行承担。【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 apk-reverse 的 Split APK 与 App Bundle 处理完全指南：签名、合并与安装
apk-reverse 的 Split APK 与 App Bundle 处理完全指南签名、合并与安装【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverseapk-reverse 是一款面向 Android APK 逆向分析的开源 Skill 工具集它对 split APK 与 App Bundle应用包拆分集合的处理尤为完整——从提取、统一签名到单文件合并与安装覆盖全流程。本文用新手也能读懂的方式带你理解 App Bundle 拆分包的本质掌握统一重签名与合并成单个 APK两条路线的取舍并看懂安装被拒时每一种报错背后的真实含义。 核心关键词apk-reverse·Split APK·App Bundle·统一签名·合并 APK·安装被拒一、什么是 Split APK 与 App Bundle为什么应用不是一个文件普通开发者在应用商店看到的往往是一个base.apk。但Google Play 和多数手机厂商应用商店上架的是 App Bundle设备最终收到的是一组 APK成员类型Manifest 里的split标记实际携带的内容base基座无全部classes*.dex、主resources.arsc、真实applicationABI 拆分config.arm64_v8a等仅lib/架构/*.so动态库密度拆分config.hdpiconfig.xxxhdpi自己的resources.arsc和res/资源语言拆分config.en、config.zh自己的resources.arsc字符串功能拆分feature_x自己的classes*.dex可能还带资源关键在于这组文件共享同一个包名、各带一份签名而包管理器把它们当成一个应用。这就是新手最常误解的地方——你以为自己在处理一个 APK其实是一整套。二、新手最容易踩的两个假性坏包坑把这套集合当成单个 APK 处理会引发两类失败而它们看起来像构建坏了其实根本不是只给 base 签名整组文件的证书不一致安装器会拒绝整组报错还会点名包名而非你漏签的那个成员。直接合并成一个 APK只有携带代码或动态库的成员才能免费折进去。携带资源的成员无法在不合并resources.arsc的情况下塞进 base——而资源表合并是资源编译器的工作不是字节级改动能做到的。[repack.py](https://link.gitcode.com/i/04c4a4704e7b9b64dea8621e4e85f30b)会帮你拒绝猜测先清点集合、判断哪条路线合法、打印原因然后才动手。三、从设备提取 Split 集合想确认一个应用是不是拆分集合最直接的办法是看pm path的输出——一行对应一个成员返回多行就是拆分集合adb shell pm path 包名 # 返回多行即为 split 集合几个新手要记住的要点成员文件通常并排放在同一目录把整个目录拷出来即可。adb pull 目录会在目标下多套一层子目录repack.py --split-dir会递归查找正好应对这一点。第三方 App 很少以拆分形式出现在普通 ROM 上系统预装组件反而更常见——这是正常现象不是你操作错了。⚠️ 不要用自己的包名重新安装拉下来的集合来测试它已装在该设备上、且属于你并不持有的厂商证书安装必然失败且这个失败与你的流程无关。四、核心决策合并成一个还是统一重签名先跑一次只读分析它不写任何文件只用文字告诉你哪条路线合法以及原因python skills/apk-reverse/scripts/repack.py --split-dir 集合目录/ --split-mode analyze下面这张决策速查表能帮你 90% 的情况做对选择你的处境推荐路线原因非 base 成员只带代码和/或lib/空资源表也算合并 merge没有需要资源表的东西要搬任一成员携带res/条目或真实资源表重签名 resign资源合并需要改写整张表既要保持可安装、应用又以 Bundle 形式分发重签名这正是应用商店的做法集合仍是集合只想要一个文件侧载/喂给某个工具合并若合法唯一能得到单一产物的方式成员声明isFeatureSplittrue且同时带 dex 和资源重签名代码能折、资源不能半合并产物更糟五、路线一统一重新签名最稳妥强烈推荐⭐这是永远有效的路线每个成员去签名 → 重写为 4 字节对齐的归档 → 用同一个 keystore以v1v2v3签名。python skills/apk-reverse/scripts/repack.py \ --split-dir 集合目录/ --split-mode resign \ --split-out-dir 已签名目录/ \ --ks key.jks --apksigner apksigner 路径通过标准不是每个文件都能 verify而是整组共用一张证书。工具会逐成员校验并打印每份文件的签名指纹理想输出形如[result] OK: 8 members, one certificate (sha256 1eb31d9c…2c44)然后连 base 在内整组安装adb install-multiple -r 已签名目录/*.apk两条新手须知签名必须覆盖每一个成员--abi/ 密度选择发生在安装时而非签名时——所以全都签让安装器去挑详见 split-apk.md §4。顺序不能反先对齐、再签名。apksigner只在归档里追加签名条目若像jarsigner那样在签名后重写 zip会破坏 Android R 要求的resources.arsc对齐。六、路线二合并为单个 APKpython skills/apk-reverse/scripts/repack.py \ --split-dir 集合目录/ --split-mode merge --out merged.apk \ --abi arm64-v8a --ks key.jks --apksigner apksigner 路径什么会被折进去classes*.dex成员的classes.dex会被重命名为classes2.dex保留 base 自己的 dex 不动、lib/**、assets/**。什么不会res/**和resources.arsc。 为什么不尝试合并资源resources.arsc是一张索引表全局字符串池 类型分块每个资源用(包, 类型, 条目)三元组标识、字符串靠池偏移引用。把成员表折进 base意味着要双向改写池偏移、类型/条目计数和每串对齐——那是aapt2 link的活不是字节级编辑。它造成的失败最隐蔽归档结构合法、能装上然后把资源 id 解析到错误的条目或空。当集合确实带有资源拆分、你却必须交付单文件时诚实的做法有三条详见 split-apk.md §5用原始.aab跑bundletool build-apks --modeuniversal唯一能正确合并资源的路线保留拆分集合整组安装用--drop-split-resources接受降级并在交付时如实说明。七、安装被拒的 7 种信号速查表新手看到报错常会对号入座错文件。记住INSTALL_FAILED_INVALID_APK是一个家族不是单一错误——先看冒号后的文字再归因。报错信号它真正在说归属判断...signatures do not match...正在装的集合与设备已装的证书不同不是坏包用原密钥重签或装到尚不存在的包名INSTALL_FAILED_ALREADY_EXISTS/UPDATE_INCOMPATIBLE同包不同签名或未加-d的降级拉下来的系统组件不能装回它自己INSTALL_FAILED_MISSING_SPLITbase 声明isSplitRequiredtrue且集合不完整——或你合并了它base 说的是真话它期望有成员...split ... has different signature集合中某一个成员签名与其余不同正是只签 base的失败形态请签整个目录[-124: resources.arsc ...]某成员的resources.arsc被压缩或未对齐逐成员报错repack.py签名前会逐成员报告[-99]或纯数字码OEM 安装器拦截器拒绝了请求与集合无关改用 root 的pm install-multiple路径完整解读见 split-apk.md §6。八、ABI 与屏幕密度匹配设备会告诉你自己能跑什么getprop ro.product.cpu.abilist。新手最容易混淆的是分隔符split 名用下划线config.arm64_v8alib/目录用连字符lib/arm64-v8a/。映射是替换而非查表——arm64_v8a→arm64-v8a这正是--abi arm64-v8a能匹配到config.arm64_v8a的原因。四条规则64 位设备仍能装 32 位集合并以 32 位运行ABI 拆分由安装器选择--abi只用于合并把选择烧进单个文件不带--abi合并会把所有 ABI 成员全折进去得到一个合法但更大的单文件单设备交付毫无意义getprop报告的是设备声称能跑的真正跑的是实时的映射问题。九、常见陷阱与最佳实践resources.arsc归谁携带谁拆分集合里它是逐成员的base 的表并不包含密度成员的条目。只读 base 就下资源存在的结论是错的。extractNativeLibsfalse现代 targetSdk 默认.so直接从归档 mmap必须未压缩且页对齐——这就是zipalign -p存在的原因。合并 native 成员后若未按此对齐写入会得到能装、启动即死在 linker。40 字节的占位resources.arsc不是资源拆分。用有没有 arsc做判据会拒绝一次完全合法的合并正确判据是*res/有条目或表大于 1 KB*。别在签名后再zipalign去修它会重写归档并作废签名。先对齐再签名。十、工具与延伸阅读想深入每一步的原理与实测证据建议按以下顺序阅读 完整参考本文所有结论的出处split-apk.md 实际执行的脚本repack.py--split-mode analyze / resign / merge 实测验证记录两个真实集合逐字节复现EXTENSION-split-apk.md 重打包与签名通用规则repack-and-sign.md 症状到文档的路由索引routing.md 回归基准矩阵含本主题 B9 行的实测强度标注tests/benchmark.md 技能入口SKILL.md获取项目仓库只读请勿直接修改/新增/删除内容git clone https://gitcode.com/gh_mirrors/ap/apk-reverse️免责声明本项目仅用于学习、研究与授权的安全测试。请只在你拥有分析权或已获得许可的应用上操作分析无权的软件在部分地区可能违法责任由使用者自行承担。【免费下载链接】apk-reverseSuitable for Android APK reverse engineering analysis项目地址: https://gitcode.com/gh_mirrors/ap/apk-reverse创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考