拒绝清单配置系统应用的依赖风险说明
先给结论：拒绝清单里写应用，写的不只是一个图标。有些系统应用之间有依赖关系，把上游那个写进拒绝清单，下游的功能会先断。最典型的一条链：应用商店被拒绝之后，通过商店分发和许可的正版应用，安装与更新都会卡住。管控动作本身成功了，业务先停了。
现象：被拒的不是商店，是商店背后的那条链
先看症状：设备上商店图标消失或者打不开，看起来只是少了个应用；接下来几个小时里，需要从商店侧拿到许可的那些受管应用开始装不上、更新不动，报错五花八门。
因为报错发生在下游应用身上，排查方向很容易被带偏——去查网络、查许可、查应用本身，绕一大圈才发现根子在被拒绝的商店上。
这条链的结构值得拆开看。商店不只是一个下载入口，它同时承担着条款接受与许可分发：
- 基于用户的批量采购，条款的接受动作要经由商店这一侧完成
- 许可的分配与核销也挂在同一条链上
拒绝清单挡的是应用可见性与启动权，挡不到「许可怎么流转」这一层——但许可流转依赖商店这个载体，载体没了，流转就停了。原因不在清单这一层，在依赖这一层。
机制：清单管入口，入口背后还有依赖
- 第一层，清单的语义：拒绝清单挡显示与启动，允许清单做封闭集过滤。这一层管的是「入口」，一台设备上有多少个能被点开的入口，由它说了算。
- 第二层，依赖关系：系统应用之间不是平铺的，有的应用是别的功能的前提。前提被挡，下游功能跟着失效。因为清单这一层只认识应用这个粒度，不认识依赖，所以「挡住一个、连坐一片」在机制上是必然行为，不是异常。本质上是两个控制面错位：管控面按应用切，功能面按依赖切。
- 第三层，验证通道：声明式通道下，设备对清单的状态有独立的状态项可查。清单生效没生效、设备侧实际认了哪些条目，能从状态上报里读出来。这给了排查一个抓手——先确认清单本身生效了，再去查下游症状，两步分开，方向就不会跑偏。
租赁机队里该风险的触发场景与稳妥方案
踩到的场景是有共性的：商家想收紧管控，把「客户乱装应用」的问题一刀切，把商店整个挡掉，以为受管应用走的是另一条通道不受影响。受管应用的分发确实走管理侧推送，但许可与条款那一环仍依赖商店载体。收紧的动作没错，错在对依赖边界的估计。
更稳妥的做法是分层：
- 商店保留，用「安装需要许可」这一档去管住客户侧乱装
- 真要挡商店，就先把自己分发的正版应用的许可模式理一遍，确认它们的许可不挂在用户侧的…
