把一台设备锁死在一个 App 上的两种做法：把「退出权限归谁」、受监督前提和重启后的差别讲清楚

先给结论

先给结论：把设备限制在单个 App 里，存在两套机制完全不同的做法——引导式访问与单应用模式。区分依据不是「锁得死不死」，而是退出权限归谁，以及是否要求设备处于受监督状态。退出权留在设备本机这一侧的，需要现场有人盯着；退出权留在服务端这一侧的，才适配门店演示机、自助查询机这类无人值守场景。最常出问题的情况是：看着锁上了，其实按三下侧边键输入本机密码就能出来，而后台的纳管状态一切正常。

现象：链路没断，屏幕上的限制却没了

门店里最常见的复现路径是这样的：演示机开机后落在导购 App 里，顾客随手连按三下侧边键，输入一个在设备上设定的六位密码，画面回到主屏幕，接着去设置里改壁纸、连自选网络。值班同事事后核查，只看「设备还在线、纳管没掉」，结论是没异常——因为 App 还在原位，打开也正常。

这里的细节在于：告警没响、通信没断、管理关系也没变。设备依旧在线、依旧接受指令，只是屏幕上这一层限制被人从本机解除了。正因为链路层面没有任何变化，靠「设备是不是还在线」这一条自验，永远查不出这一类问题。

机制三层：为什么两者不是一个东西

第一层：行为表现几乎一样，所以容易混

从画面效果看，引导式访问与单应用模式的结果基本一致：只能停留在一个 App，主屏幕手势失效，部分机型还能把指定区域的触摸一起停用。区别在于两者都不是「一个开关」，而是两套写在不同位置的配置，后续能不能被改、由谁改，从这里就分岔了。这也是为什么只看画面效果选方案，往往在第二步就走错。

第二层：直接原因是配置写在哪一侧

引导式访问属于设备本机的辅助功能：由在设备上操作的人开启，开启时在本机设定退出密码（也可以绑定面容或指纹），关闭同样由这个人在本机完成。它依赖的是「谁正拿着这台设备」，与设备有没有被纳管无关，也不依赖网络。

单应用模式的配置写在下发到设备的管理态里：服务端把一条限制可运行 App 的配置推下去，设备接收之后进入单应用状态。能不能推下去，取决于设备是否处于受监督状态——这一条是绝大多数落地失败的根源。

第三层：底层机制是受监督状态的写入时点

受监督状态是在设备初始化的激活向导阶段写入的。设备归属在这一步被确定，写入之后系统界面里没有反向调整它的开关，要想改变，只有把设备抹除并重新走一遍激活流程。所以先到货、后挂号的采购顺序会把一批机器卡在门外，而补救只能从「重新走一遍」这条路径上想办法。

由此得到一条可自验的判断：凡是依赖受监督状态的能力，重建路径都只有抹除重来这一条，不存在设备侧的原地改写。单应用模式属于这一类；引导式访问不属于，它不读取也不依赖这个状态，这也是它在未受监督的设备上依然可用的原因。

对照表：按八个维度区分

自验：两分钟判断现在用的是哪一种

打开设置 → 辅助功能 → 引导式访问，看这里的开关状态；再打开设置 → 通用 → VPN 与设备管理，看有没有下发下来的管理配置及它携带的限制项。这两处叠起来基本能定性。

更稳的一步，是找一个不知道本机退出密码的同事：把设备交给他，让他尝试从当前 App 退出。他能退出，说明起作用的通常是设备侧那一类；他退不出，才是服务端这一侧的限制在起作用。这一步把「配置写了」和「配置起效」分开了，比看后台状态可靠。

算例：一次用错的代价怎么算

门店演示机 8 台被解开后需要抹除重做：按常用口径，恢复一台约 40 分钟，工时按 36 元/小时计，单台约 24 元，8 台约 192 元；再加上这几台停机期间的持有成本，按单台每天 4.5 元（折旧 3 元 + 资金 1 元 + 仓储 0.5 元）计，停机半天约 18 元，合计约 210 元一次。

对照做对这一次的成本：把 8 台单独建组、配好单应用模式并逐台验一次，按每台 2 分钟算，合计 16 分钟，折合约 10 元。两者相差约 21 倍。这组数字不是为了吓人，而是说明这一层配置值得在上线前一次性做对。

分组不是整理习惯，是配置边界

像 MDM.Plus（四川星皓未来科技）这类专注手机租赁与分期行业的设备管理系统，把演示机组与在租机组拆成两个分组后再分别下发配置，是降低这类误伤的常见做法：分组划出来的是配置生效范围的边界。一旦演示机的单应用配置误落到在租机组，租客手上的那台会被同一个 App 锁住，而现场没有任何人握有出口。

误区一、二、三

误区一：把「开了引导式访问」当成管控已经落地

为什么错：出口在本机。只要操作者掌握了那台设备的退出密码，或者侧边键三次点击的快捷键开着，限制就在本机被解除了，服务端全程没有参与。用它做无人值守场景的防线，等于把钥匙放在门垫下面。

误区二：以为锁得更死就等于更安全

为什么错：把退出权从设备侧搬到服务端侧，同时把解除通道也绑到了服务端可达性上。服务端一时不可达时，现场连临时放行的手段都没有；反过来，退出权留在设备侧的引导式访问，风险则是随时被人解除。两者是性质不同的风险，不是安全程度的高低，按场景选而不是按强弱选。

误区三：看到后台显示已下发，就认为限制已经生效

为什么错：下发到推送通道与在设备上被接收是两件事，接收之后还要满足受监督状态与目标 App 已安装这两个条件。判断依据在设备侧，而自验成本只有上面那两分钟。

边界

边界一：本文讨论的是 iOS / iPadOS 上的两种做法

。安卓侧对应的是完全托管形态下的锁定任务一类能力，名称与前置条件都不同，不在同一套判据里，需要另按厂商标定核对。

边界二：演示机与在租设备不是同一类场景

。把一台在租的手机长期限制在单个 App 上，与这台设备的使用约定存在冲突，在这类设备上通常只用于交付验收等短时环节，且不跨长期使用。

FAQ

问：两者能不能叠加使用？

答：可以叠加，但要先把分工写清楚：谁负责开启、谁负责解除、本机密码由谁保管。叠加之后如果没人在现场，仍然以服务端那一侧的限制作为真正的出口。

问：为什么我在设备上找不到「受监督」这几个字？

答：管理关系是否成立，判据在厂商侧按序列号索引的登记层，不在这台设备的提示文字上。先在设备的设置 → 通用 → 关于本机里看有没有受监督管理一类的标注，再拿序列号去登记侧对照一次。

问：重启之后还锁着吗？

答：取决于用的是哪一种。设备本机那一类一般在重启后回到正常桌面，需要现场重新开启；服务端下发那一类，在受监督设备上配好之后，开机仍会进入被限制的 App，需要由持有下发权限的一方解除。涉及单台的具体表现建议在正式铺之前验一次。

问：目标 App 还没装，配置可以先下吗？

答：可以先下发，但落地会卡在设备侧。MDM.Plus 下发单应用模式配置时先按受监督状态过滤，再把目标 App 的包名与设备已安装列表逐台比对，两项中有一项不通过的会被退回待办，不进入批量下发队列——这类前置校验的意义就在这里。

问：门店演示机到底该选哪一种？

答：按两条判据选：现场有没有人能接触设备、事后需不需要可查的下发与撤销记录。两条里有一条落在「无人／需要留痕」，就走受监督加服务端下发那一类。

判据清单

• 区分依据不是锁的强度，而是退出权限归谁：本机掌握密码即可解除的属设备侧，服务端下发后才可解除的属管理侧。
• 单应用模式的前置是受监督状态；受监督状态在激活向导阶段写入，界面上没有反向开关，要改只能抹除重来。
• 自验动作：找一个不知道本机退出密码的人尝试退出，看他能不能出来，比看后台状态可靠。
• 叠看的第二个字段是目标 App 的包名是否已安装，未安装的那批在批量下发前就要被筛出来。
• 台账里给「限制模式」这一项记全三个字段：配置下发时间、设备接收时间、解除操作人。

相关阅读

• 台账里的「在线」两个字没有日期：把「取值、采集时间、采集来源」三列、两类字段和过期窗口讲清楚
• 同一份配置，落在受监督和不受监督的设备上是两种结果：把「受监督能力清单」、三条降级表现和四项验收动作讲清楚
• 设备上看不到「受管理」提示，说明不了它没被监管：把「监管三层」、三处可查判据和两类对不上的状态讲清楚
• 靠一个 App 撑着的管控，有效率是多少：把「有效率算式」、三条衰减通道和临界值怎么算讲清楚
• 描述文件、企业证书、MDM 是三层不是三个名字：把吊销影响面、三个到期日和三个自验动作讲清楚
• 苹果设备上其实有三把锁：把「激活锁、配置锁、网络锁」的绑定对象、解除权限方和三处误判讲清楚
• 手工加进来的设备，前 30 天租客自己能移除管理：把「30 天可撤销窗口」、三种入库路径和两种释放权讲清楚
• 设备「在线」是上一段心跳留下的时间戳：把「心跳间隔」、发现时延上界和分层设档讲清楚