只读取安装包实际声明的证据
APK、AAB、IPA 在线解析：查看包结构与签名文件
APK、AAB 和 IPA 都是归档文件，却有不同的元数据链路。静态检查可以盘点文件路径、体积和有限的身份信息，但不能证明应用安装后会做什么，也不能仅凭签名文件判断它是否可信。
安装包身份与结构清单
格式
根据 .apk / .aab / .ipa 扩展名识别
包名或 Bundle ID
仅从 XML Info.plist 读取 IPA 声明
版本
IPA 的营销版本与构建版本
归档体积
上传前文件的压缩字节数
最低系统版本
IPA XML Info.plist 中的声明
架构线索
Android ABI 目录与 Mach-O framework 是否存在
APK 证据路径
ZIP 目录 → AndroidManifest.xml → DEX / resources / native libraries → META-INF
- 确认 AndroidManifest.xml 路径，但不猜测二进制清单中的组件或权限
- 按路径统计 DEX、资源、assets 和原生库的未压缩体积
- 从 lib 目录识别 arm64-v8a、armeabi-v7a、x86_64 或 x86
- 列出 META-INF 中的签名证据文件，但不验证证书链
AAB 证据路径
归档根目录 → base / feature 候选模块 → manifest + DEX + resources + native libraries
- 根据归档根目录推断模块候选项
- 确认 BundleConfig.pb 与模块 manifest 等元数据路径
- 统计 DEX、资源、assets 与原生库分类体积
- 不生成设备 APK，也不解码 protobuf 中的交付规则
IPA 证据路径
.ipa → Payload/*.app → Info.plist → entitlements / mobileprovision → Frameworks
- Info.plist 为 XML 时读取 Bundle ID、版本、名称和最低 iOS 版本
- 二进制 plist 只报告存在与体积，不声称已解码
- 列出 entitlements、embedded.mobileprovision 与 _CodeSignature 证据路径
- 识别 Frameworks 中存在 Mach-O 文件，不推断具体架构切片
存在签名文件，不等于安装包可信
当前报告确认的是 META-INF、_CodeSignature、entitlements 或 provisioning profile 等证据路径，并不解析或验证证书主题、签发者、指纹、有效期和撤销状态。它也不能证明商店审核、开发者归属或运行时完整性。
静态归档检查的边界
不会执行
不会运行 DEX、Mach-O、服务或应用生命周期。
只读归档结构
展示 ZIP 条目与体积，不等于校验每个条目的 CRC、代码签名或完整性。
不做完整元数据解码
编译后的 Android manifest、protobuf 和二进制 plist 不会被猜测。
不下恶意软件结论
文件结构和签名路径不能证明应用安全。
不评估运行时与隐私
权限授予、网络行为和数据合规需要更多证据。
APK、AAB 与 IPA 解析常见问题
- AAB 就是最终安装到设备上的 APK 吗？
- 不是。AAB 是发布格式，包含模块化的代码与资源；交付系统会根据设备配置生成并签署实际安装的 APK。
- 看到签名文件就能确认安装包安全吗？
- 不能。签名证据只能说明归档中存在相关文件；还需要验证签名方案、证书链、指纹来源、撤销状态和文件完整性，并结合代码与运行时行为判断风险。
- 解析安装包会上传我的发布文件吗？
- 不会。归档读取与报告生成都在浏览器的 Web Worker 中完成，文件不会发送到 DevSexy 服务器。