TG咨询测试版一安装，正式版就被替换；或者两份安装包看起来不同，却提示无法安装——通常要先检查应用身份。做好多版本应用共存测试的包名与签名管理，核心是分别确认包名决定的安装身份和签名证书决定的更新信任关系，再按测试用途安排组合。
以下流程以 Android 应用为主。Android 的 applicationId 是安装时识别应用的包名；签名则用于验证应用来源及后续更新是否可信。两者作用不同，不能只改显示名称来实现共存。
第1步：列清版本用途与安装关系
先把正式版、开发版、测试版分别列出，并注明它们是否需要同时安装、是否要覆盖升级、是否连接不同的后端环境。比如，若测试人员要在同一台设备上比较正式环境与预发布环境，两个版本通常需要不同的 applicationId；若测试的是正式版的更新包，则应保持包名一致，并使用兼容的签名。
这一步先定目标，避免把“能够并存”和“能够升级”混为一谈：不同包名便于并装，但它们是系统眼中的不同应用；相同包名便于验证更新，却不能作为两个独立应用同时保留。
第2步：为并装版本设置独立包名
- 在构建配置中检查 applicationId，确认各变体最终生成的值，而不是只看源代码目录或应用桌面名称。
- 为开发、测试等变体使用明确的 applicationIdSuffix，或为不同 product flavor 指定独立 applicationId。后缀与命名规则要稳定，避免每次构建随意变化。
- 检查通知渠道、深链、文件提供器等组件是否使用了依赖包名的配置；包名变化后，相关配置和服务端登记也可能需要同步调整。
applicationIdSuffix 适合在同一应用工程中区分构建变体，维护成本较低；单独指定 applicationId 更适合需要长期独立发布、配置差异较大的版本。两种方式都应先检查最终构建产物中的包名。
第3步：按更新关系管理签名
同一包名的安装包要作为彼此更新，通常必须由相同签名身份签署；签名不兼容时，设备会拒绝覆盖安装。反过来，不同包名可以并装，即便签名配置不同，也不等于它们能互相升级。
把签名配置与构建变体明确对应：本地调试使用调试签名，交付测试或验证正式更新时使用指定的发布签名。检查 signingConfig 是否被错误地复用于不该共享身份的变体，并限制密钥文件及密码的访问。若应用已通过 Google Play App Signing 发布，还要区分上传密钥与应用签名密钥；验证更新兼容性时，应以实际分发链路使用的签名身份为准。
第4步：核验实际安装包，不只看配置
- 分别构建计划测试的 APK，记录变体名称、最终包名、版本号和签名证书指纹。
- 用 Android SDK 的 apksigner 检查 APK 签名信息；将证书指纹与团队维护的记录比对，不要仅凭文件名判断。
- 在测试设备上确认安装结果：并装场景应能看到两个独立应用；升级场景则应确认旧版本能否被目标包覆盖，并验证数据是否按预期保留。
如果交付的是 Android App Bundle，实际安装内容可能由分发流程生成；需要验证该流程最终提供给设备的包及其签名，而不能只检查本地构建目录中的中间文件。
第5步：用测试矩阵固定验收标准
| 测试目标 | 包名安排 | 签名安排 | 重点检查 |
|---|---|---|---|
| 两个环境并装 | 使用不同 applicationId | 按各自发布流程配置 | 能否同时安装、数据和通知是否串用 |
| 验证版本升级 | 保持包名一致 | 使用兼容的签名身份 | 覆盖安装、数据迁移及版本号规则 |
| 验证签名变更 | 保持原包名 | 按平台支持的密钥轮换流程评估 | 目标系统版本与分发渠道是否兼容 |
把设备系统版本、安装来源和构建编号一并记录，能帮助定位“仅某些设备失败”或“本地可装、分发后不可更新”等问题。多版本应用共存测试的包名与签名管理应沉淀为构建规则和验收记录，而不是依赖测试人员临时改名或重签。
常见问题
改了应用名称，为什么还是不能并装？
桌面显示名称不决定安装身份。要检查最终 APK 的 applicationId 是否不同。
包名不同，签名还需要相同吗？
并装本身通常不要求两者使用相同签名；签名是否一致应由更新、发布和内部信任需求决定。
卸载旧版能解决签名冲突吗？
卸载可能让新包安装成功，但会失去验证覆盖升级和数据迁移的机会。应先确认测试目标，再决定是否清理设备。
归根结底，先按用途区分并装还是升级，再核验包名和证书，才能让多版本应用共存测试的包名与签名管理既可重复，也便于追踪问题。