智能门锁进入试产后，研发仍在调整蓝牙通信、测试项目和设备兼容逻辑，Android 工厂测试 App 也会跟着更新。上午，研发把修复版 APK 发到项目群；下午，工厂新增一个测试工位，工程师却从共享文件夹里找到了另一个同名安装包。两个 App 都能打开，也都能连接部分样机，产线很难只凭界面判断哪一个才是当天允许使用的版本。
问题往往不是"工厂拿不到 APK"，而是 APK 太容易被复制和转发。聊天记录、网盘、本地文件夹和测试手机里同时留着多个版本，只要文件名不清楚、换班没有交接，或者新工位沿用了旧手机，已经停用的测试包就可能重新进入生产现场。
对于智能门锁企业来说，工厂测试 App 不是普通办公软件。它的版本可能对应特定门锁型号、硬件批次、固件版本和测试规则。如果产线装错 APK，得到的不只是一次安装错误，还可能是错误的测试结论。
因此，真正需要解决的不是"怎样更快把文件发到工厂"，而是怎样让产线只看见经过验证和放行的版本，并且能随时确认自己正在使用哪一版。
研发生成了新版，不等于产线可以立刻更新
研发构建 APK 的目标，是尽快验证修改是否有效；产线使用 APK 的目标，则是稳定、可重复地执行已经确定的测试流程。两个目标不同，版本状态也不能混在一起。
一个刚刚完成构建的版本，可能只修复了某个连接问题，但还没有覆盖全部门锁型号；也可能改变了测试步骤，却没有同步修改产线作业指导书。即使 App 本身可以正常安装，也不代表它已经适合投入当前批次的生产测试。
比较稳妥的做法，是把版本分成至少三个状态：研发验证中的候选版本、已经完成内部验证但尚未允许产线切换的待放行版本，以及当前产线正式使用的版本。
这里的"放行"不应只是研发在群里说一句"可以用了"。企业至少要明确由谁确认 App 版本、包名和签名，谁核对门锁型号与固件范围，谁确认测试项目和作业说明已经同步，最后由谁通知产线切换。
只有完成这些动作，新 APK 才能从"研发产物"变成"产线版本"。
群文件看似方便，却没有回答"现在该用哪一个"
通过群聊或网盘发送 APK，最大的风险不一定是文件丢失，而是多个副本失去统一状态。
研发人员可能使用"测试版""最新版""修复版"命名文件；工厂工程师为了区分，又在文件名后加上日期或人员姓名。几轮更新以后，不同电脑中的"最新版"可能已经不是同一个文件。即使后来撤回消息或删除网盘文件，别人此前下载到本地的 APK 仍然存在。
测试手机也会放大这个问题。旧 App 没有卸载，新包因为签名、包名或版本条件无法覆盖安装时，操作人员可能临时换回另一个文件。只要没有记录最终安装结果，下一班人员看到的仍是一台"可以运行"的手机，却不知道它实际对应哪个构建。
因此，产线需要的不是不断增加新的文件地址，而是一个稳定入口，以及一句明确答案：当前批准使用的版本是什么。
历史版本可以保留用于复测和问题追溯，但不应该与当前产线版本并排摆放，让操作人员自行猜测。
正确版本必须同时对应 App、门锁和测试规则
智能门锁工厂测试通常不是孤立的软件操作。App 与门锁硬件、固件及测试项目共同构成一次测试条件。只记录 APK 文件名，无法在发生争议时还原现场。
每次放行至少应记录以下对应关系：
-
App 名称、包名、版本号或企业内部构建编号；
-
安装包签名及文件校验信息；
-
适用的门锁型号、硬件批次和固件范围；
-
本次新增、修改或取消的测试项目；
-
是否允许覆盖安装，切换前是否需要清理旧数据；
-
放行时间、确认人员和停止使用条件。
这些信息不需要全部塞进下载页面，但必须在企业内部有可追溯记录。下载页面负责告诉工厂"当前应该安装什么"，测试记录或质量系统负责证明"为什么允许使用它"。
如果一款 App 同时服务多个门锁型号，更要避免一句"适配全系列"带过。某次更新可能只验证了其中一部分型号，页面和更新说明就应该写清适用范围。没有完成验证的型号，不应因为共用同一个 App 名称而被默认包含。
蒲公英可以提供稳定入口，但不能代替版本放行
企业完成内部验证后，可以把智能门锁工厂测试 APK 上传到蒲公英，通过固定的应用入口向工厂提供安装包。工位新增测试手机或重新安装时，可以从统一入口获取当前版本，不再依赖某位工程师保存的群文件。
蒲公英支持 Android APK 上传，可通过网站、桌面客户端或开放 API 等方式发布。版本管理中可以编辑更新说明、控制版本显示或隐藏，并把确定的版本设为当前版本。部分操作会受账户方案和权限影响，应以实际账户页面为准。
这些能力适合承接"版本怎样到达工厂"和"页面当前展示哪一版"，但不会自动判断 APK 是否适配某款门锁，也不会替企业完成质量审批。
比较清晰的协作方式是：研发可以上传候选包，但候选版本先保持内部验证状态；测试负责人完成门锁型号、固件和测试项目核对后，再由有权限的负责人调整产线可见版本。更新说明写清本次变化和适用范围，产线只从约定入口安装，不从聊天附件中寻找所谓最新版。
如果企业构建频繁，也可以通过开放 API 把 APK 上传接入已有的构建或 CI/CD 流程。不过，自动上传只是减少文件搬运，不应该自动跳过验证和放行。程序显示上传成功，只能说明文件进入了发布流程，不能证明它已经适合产线使用。
版本切换不能只发一句"请更新"
产线切换测试 App 时，最容易遗漏的是现场确认。
负责人首先要确定切换窗口：是当前批次结束后统一更新，还是允许部分工位先验证。若新旧 App 的测试逻辑不同，同一批产品不宜在没有标记的情况下混用两个版本，否则测试结果难以比较。
其次要确认旧版本如何退出。仅仅把新版本设为当前版本，并不会自动删除工位手机上已经安装的旧 App。企业需要根据自己的现场管理方式，要求操作人员核对版本、覆盖安装或重新安装，并记录完成状态。
最后还要准备回退条件。新版本在研发环境通过测试，不代表所有产线手机、门锁批次和连接环境都没有差异。如果现场出现异常，应明确是暂停当前工位、回到上一已批准版本，还是由工程师进一步确认，而不是让操作人员自行从历史文件中任选一个 APK。
一次完整的切换通知，至少应包含当前版本、适用门锁与固件、变更内容、生效时间、安装方式、确认方法以及异常联系人。这样，通知才是在改变生产条件，而不只是发送一个下载地址。
换班、增设工位和更换手机，都要重新确认安装来源
版本管理失控往往发生在"临时操作"中。设备故障后借来一台手机、旺季临时增加工位、夜班找不到原负责人，都可能让旧安装包重新出现。
企业可以把下面几项加入日常点检：测试手机只能从约定入口获取 App；启动测试前显示或记录版本信息；新增工位必须核对门锁型号和固件范围；交接班时确认当前批准版本；发现本地存在多个 APK 时，不以文件名判断新旧，而是回到版本记录核对。
售后或质量人员收到异常反馈时，也不应只问"是不是最新版"。更有效的做法是同时收集 App 版本、手机系统、门锁型号、固件版本、测试项目和异常时间。只有这些条件能够对应，研发才能判断问题来自 App、门锁、测试流程还是现场环境。
平台保留版本，企业仍要保留自己的生产证据
蒲公英上的历史版本能够帮助企业管理和回看已经上传的安装包，但平台托管不应成为唯一归档。版本删除不可恢复，账户方案、容量和版本保留规则也可能影响历史安装包的可用状态。
对于真正进入过产线的版本，企业应在内部保存 APK、签名或校验信息、构建记录、适用范围、放行记录和停止使用原因。这样，即使页面展示发生调整，也能还原某个批次当时使用的测试条件。
同时要控制谁可以改变产线入口。研发可以拥有上传能力，但"上传""显示""设为当前版本"和"通知工厂"最好不是一个未经复核的连续动作。权限和流程越清楚，越不容易因为赶进度，把尚未验证的包直接推到生产现场。
避免装错 APK，关键不是给文件改一个更长的名字
智能门锁量产阶段的 App 管理，本质上是生产条件管理。给 APK 加上日期、版本号和"最终版"只能改善辨认，不能建立可靠的版本状态。
真正有效的做法，是把研发构建、内部验证和产线放行分开；为工厂提供唯一且稳定的安装入口；让当前版本与门锁型号、固件和测试规则建立对应关系；每次切换都完成现场确认，同时保留企业自己的归档和放行证据。
蒲公英可以承担 Android APK 托管、应用入口和版本展示，减少群文件与多份副本带来的混乱。但平台只是交付链路的一部分。只有企业明确谁能上传、谁负责验证、谁决定放行，以及工厂怎样确认安装结果，产线才能真正做到"拿到的不是最新文件，而是当前允许使用的正确版本"。