本文为基于公开技术资料编写的解释性教程。命令和输出示例不代表已在你的设备上验证；执行前请核对版本、目标设备和数据影响。
不要从一个弹窗猜根因
手机上的“应用未安装”只表示安装没有完成，并没有告诉你是哪一项校验失败。可能涉及包内容、设备架构、版本更新规则、签名、存储或系统策略。排查的第一步是获得更具体的失败信息。
如果你拥有可调试的测试设备和合法安装包，可以在电脑上用 ADB 进行一次明确的安装尝试。先确认目标设备，再保存输出。下面的命令会安装或更新应用，因此应在你允许修改的测试设备上执行。
adb devices -l
adb -s SERIAL install -r app.apk-r 用于重新安装并保留现有数据，但不能让不兼容的签名或版本自动变成兼容。不要把添加更多参数当作通用修复。
把失败信息归到正确的层
| 典型线索 | 优先检查 |
|---|---|
| UPDATE_INCOMPATIBLE | 现有包与新包的签名和更新关系 |
| VERSION_DOWNGRADE | 新旧 versionCode 与预期测试路径 |
| NO_MATCHING_ABIS | native 库架构与设备支持的 ABI |
| MISSING_SPLIT | 是否缺少必要拆分包 |
| INSUFFICIENT_STORAGE | 可用存储、安装所需空间与系统状态 |
表格给的是排查方向，不是对所有厂商系统都适用的完整错误码表。应保留原始失败行，包括可能存在的附加说明。
记录四组条件，减少来回询问
- 设备条件：型号、Android 版本、支持的 ABI。
- 包条件：来源、文件摘要、包名、版本号、是否为 split。
- 环境条件：是否已有旧版本、旧版本来源、是否为受管理设备。
- 执行条件：完整安装命令、执行时间、标准输出和错误输出。
若应用包含 native 库，可以先查询设备 ABI 列表，再检查包内对应目录；如果它根本没有 native 库，就不要优先投入时间分析 ABI。
adb shell getprop ro.product.cpu.abilist一次只改变一个条件
如果同时更换设备、修改包名、重签名并删除旧应用，即使安装成功，也无法知道原来的问题是什么。更好的实验方式是先验证包是否完整，再固定设备检查签名与版本，最后才讨论特定系统的安装策略。
对于必要 split 缺失，补齐同一构建的安装集合通常比重打包更直接。对生产升级失败，卸载后安装成功只证明“新装路径”可用，不能证明“升级路径”已经修复。
整理一个可以交接的结论
把报告分成现象、证据、调整和验证四段。例如：“新包安装返回版本降级错误；记录显示新 versionCode 小于设备现有版本；提升构建版本后重新生成测试包；同一设备更新安装成功且原数据保留。”
若仍无法复现，明确写出没有覆盖的条件，不要把“我这里能安装”当作否定用户报告的依据。安装与启动也要分开记录：前者通过后，仍需检查应用启动和关键功能。