热成像仪已经完成项目验收，设备交给客户，配套 Android App 也安装在现场使用的手机上。几个月后，客户更换了一台新手机，才发现原来的 APK 只保存在已经离职的实施人员电脑里；售后群中虽然还能找到几个安装包，但文件名相似，没人能确定哪一个适用于当前热成像仪和固件。
与此同时，研发已经修复了新系统上的连接问题，项目负责人却没有一条稳定路径把新版交付给客户。有人建议重新在群里发文件，有人准备放进网盘，还有人认为设备已经验收，App 更新应该由客户自己解决。
这类问题并不罕见。热成像仪的使用周期通常长于某个 Android App 版本。设备交付完成后，客户仍可能重新安装 App、更换手机、升级系统、更新仪器固件，或在售后排查时需要确认历史版本。如果 App 只服务购买设备的企业客户，没有公开上架应用商店，那么"客户以后从哪里获得正确版本"就必须成为交付方案的一部分。
真正需要管理的不是某一个 APK 文件，而是配套 App 在整个设备使用周期中的下载安装、版本更新和兼容责任。
设备已经交付，不代表 App 交付也可以结束
热成像仪属于软硬件共同工作的产品。Android App 可能负责实时画面、温度数据展示、参数设置、图片或报告导出，也可能只是完成其中一部分功能。无论功能多少，只要客户的日常使用依赖 App，企业就需要考虑设备交付后的软件可获得性。
一次性把 APK 发给客户，只能满足当时那台手机的安装需求。它无法解决后续问题：新员工加入项目后从哪里下载安装，旧手机损坏后怎样恢复，Android 系统升级后出现兼容问题怎么办，新 App 是否仍支持原来的仪器固件，以及售后人员怎样判断客户当前使用的是哪一版。
如果企业没有长期入口，客户通常会自行保存安装包。文件会进入个人电脑、项目网盘、聊天记录和移动存储设备。时间越长，来源越多。等到真正出现问题时，售后不仅要排查设备和网络，还要先辨认一个没有可靠记录的 APK。
所以，热成像仪交付清单中不能只写"已安装 App"，还要回答三个长期问题：客户从哪里重新获得 App，哪个版本是当前推荐版本，出现兼容问题时由谁决定升级或回退。
不公开上架，也要给客户一个正式的应用入口
B2B 配套 App 不上架应用商店，原因可能是用户范围有限、应用只与特定设备配合，或者正式上架尚未进入当前计划。但"不上架"不应该等于"没有发布入口"。
面向客户的应用页面至少要帮助使用者确认以下信息：
-
这是哪个品牌、哪类热成像仪的配套 App；
-
适用哪些设备型号和硬件批次；
-
当前 App 版本、更新时间及主要变更；
-
需要配合什么固件版本或连接方式；
-
Android 系统和手机需要满足哪些基本条件；
-
新版能否覆盖安装，是否涉及数据迁移或重新授权；
-
安装或连接失败时应该联系谁。
这比只提供一个下载按钮更重要。客户拿到 APK 后能够安装，并不代表装对了应用，更不代表该版本适用于手中的设备。如果同一企业有多款热成像仪、工业内窥镜或测温设备，页面上的型号范围必须写清楚，不能只使用"检测设备 App"这样的宽泛名称。
更新说明也不应只写"修复已知问题"。对于已经交付的硬件，客户真正需要知道的是：新版解决了什么兼容问题，是否影响既有操作流程，是否要求升级固件，以及哪些客户应该更新、哪些客户可以暂时保持当前版本。
测试、验收和长期使用，不应共用同一套版本规则
热成像仪 App 在研发测试、项目验收和客户长期使用三个阶段，面对的人群和风险不同。
研发测试入口可以保留高频构建，用于验证新功能和设备适配。版本可能包含测试配置，页面说明也可以更偏技术。项目验收入口则应对应合同或验收计划中的明确版本，保证项目成员安装的是同一套 App、仪器固件和服务器环境。
客户长期使用入口最稳定，只应提供经过正式放行的版本。它不能因为研发上传了一个新构建就自动改变，也不应该把内部测试包直接暴露给客户。
三个阶段可以使用同一套分发工具，但必须通过应用、版本状态、展示范围和内部流程区分。最危险的做法，是把研发日常使用的临时链接直接写进客户资料，然后期待研发团队以后每次上传都不会影响已经交付的项目。
蒲公英可以承接安装入口，但版本是否可交付仍由企业决定
企业完成 APK 构建、签名和兼容验证后，可以把热成像仪配套 App 上传到蒲公英，通过应用页面维护名称、版本和更新信息，并把约定入口交给客户。后续版本继续发布在同一应用下，客户更换手机或需要重装时，不必再从旧聊天记录中寻找附件。
按照蒲公英当前规则，应用上传后默认使用内测模式，适合企业或团队内部的小范围测试。如果实际使用范围扩大到更多客户或对外分发，则应根据当前用途和平台要求申请分发模式，而不是把内测入口直接当作无限制的公开下载站点。
蒲公英的版本管理可以对版本进行显示或隐藏、编辑更新说明、设为当前版本或删除。部分操作会受账户方案和权限影响，具体应以账户页面实际显示为准。
这些能力解决的是"哪个版本在页面上提供给客户"。但平台不会替企业判断这个版本是否通过设备兼容验证，也不会自动知道某位客户使用哪款热成像仪和固件。设为当前版本之前，企业仍需完成自己的放行流程。
一个稳妥的发布顺序应当是：研发生成 APK，测试核对包名、签名、Android 条件、仪器型号和固件范围，产品或交付负责人确认客户说明，最后再更新客户可见的当前版本。
新版不应简单覆盖旧版，先判断客户是否适合升级
App 更新后，最省事的操作是直接把新版设为当前版本。但对于已经交付的热成像仪，这个动作可能影响不同项目和不同设备批次。
如果新版只修复通用的系统兼容问题，且已经验证可以覆盖现有客户，更新当前版本通常比较直接。如果新版依赖新的仪器固件、改变数据格式或调整关键权限，则不能只在更新说明里写一句"请升级最新版"。
企业需要先判断：哪些设备可以直接更新，哪些设备必须先升级固件，哪些项目暂时应保留原版本，以及出现问题时是否允许回退。
这也是为什么版本说明需要包含设备条件，而不仅是 App 变化。客户反馈"新版无法连接"时，售后应能迅速核对 App 版本、Android 系统、热成像仪型号、固件版本和连接方式，而不是反复让客户卸载重装。
如果某些项目必须长期使用经过验收的旧版本，应把它作为明确的维护对象：记录适用客户、设备和停止支持条件，并保留企业自己的归档副本。历史版本不是越多越好，更不应该全部公开给客户自行尝试。
"长期有效"不等于所有历史安装包都会永久保存
长期维护非商店 App 时，企业容易把"应用入口长期可访问"和"所有历史 APK 永久存在"理解成同一件事。实际上，这两个问题需要分别管理。
蒲公英当前版本管理按账户容量处理 App 和历史安装包。自2026年10月15日起，账户容量超额会根据账户选择的策略处理符合条件的历史版本。被删除或自动清理的安装包无法恢复，对应下载链接也会失效。
正常托管的系统最新版本、当前对外版本以及部分被引用的版本会受到相应规则保护，但企业仍不能把平台托管当成唯一的软件归档。官方文档也明确区分了下载有效期与版本保留："长期有效"表示没有设置下载起止时间，并不代表每个历史安装包永久保存。
因此，热成像仪企业至少要建立两层保留策略：蒲公英负责客户当前下载安装和必要版本展示；企业内部制品库负责保存需要长期归档的 APK、签名信息、构建记录和兼容说明。
准备清理历史版本前，还应检查客户资料、售后文档和项目链接是否仍指向该版本。删除操作不可恢复，不能仅凭"很久没人下载"就认定它已经没有业务价值。
客户身份、设备授权和数据合规不能交给下载页面代替
配套 App 入口解决的是软件交付，不是整个客户权限体系。
即使页面设置了密码、团队成员或其他安装方式，也不能当然地把它视为严格的客户身份认证。链接和凭据仍可能被转发。涉及保密项目或受控设备时，企业需要通过自己的客户账号、合同、人员名单或项目系统确认谁有权使用。
同样，关闭下载入口不会远程卸载客户手机上的 App，也不能收回已经保存的 APK，更不能撤销热成像仪本身的设备授权。如果业务要求项目结束后停止使用，必须在 App 账号、设备端授权或服务端权限中另行设计控制机制。
App 还可能处理热图、测温数据、现场图片或项目资料。分发平台不能替企业完成隐私告知、数据权限、存储规则和行业合规。下载成功只是软件到达手机的开始，不代表连接、功能和数据处理已经符合要求。
热成像仪交付前，应把 App 长期维护写进交付清单
企业可以在设备交付前完成一次 App 生命周期检查：
-
客户资料使用的是稳定应用入口，而不是某个临时 APK 文件地址。
-
页面明确标注热成像仪型号、固件范围、App 版本和 Android 条件。
-
研发测试、项目验收和客户长期使用入口已经区分。
-
每次更新都有构建、签名、设备兼容和客户说明的放行记录。
-
需要保留的历史版本已记录适用客户，并在企业内部完成备份。
-
账户容量、历史版本清理策略和关键链接有人定期检查。
-
客户身份、设备授权和数据合规由企业自己的系统与流程负责。
-
售后反馈能够同时记录 App、手机、热成像仪和固件版本。
热成像仪配套 App 不公开上架，并不会天然造成交付困难。真正的问题是，企业是否把 App 当作设备生命周期中的持续服务，而不是验收当天发送的一份附件。
建立长期应用入口、明确当前版本、谨慎管理历史版本，并把兼容验证和维护责任写入交付流程，客户才能在设备使用多年以后仍找到正确的软件。蒲公英可以承担 APK 托管、应用页面和版本入口，但一个可靠的 B2B 配套 App 体系，最终仍取决于企业是否持续管理软件、设备、固件和客户之间的对应关系。