策略冲突不是下发失败：两条规则都生效了，语义却互相覆盖。同一设置被多个来源下发时，多数政策取最严；另有少数项按「最近一次」或「角色优先级」裁决，黑白名单并存时先看作用域再看值。
先排除：它不是哪三种故障
设备行为不对，先分清落在哪一层。第一类是指令没发到：通道证书过期、长时间未心跳、设备离线，后台显示已下发但设备侧毫无回执。第二类是单条规则本身无效：字段写法不对、签名过期、负载标识符对不上，单独下发就会报错。第三类才是冲突：每条单独下发都成功也生效，合在一起结果却不是任何一条单独的样子。
一句话判据：单独下发能不能复现你要的预期？能，就是合并层的问题；不能，就先回到下发链路或配置本身。很多人在这三条路上来回跑，是因为没有先做这一步。更多到账与凭证类排查见 指令发出去了设备却没反应。
表 1 · 三类现象分别落在哪一层
| 你的疑问 | 单独下发这一条 | 全部规则一起 | 该去看哪一层 |
|---|---|---|---|
| 设备毫无反应 | 同样没反应 | 也没反应 | 下发链路：通道、证书、心跳 |
| 这条规则不生效 | 单独就报错 | 报同样的错 | 配置本身：字段、签名、标识符 |
| 结果和规则不一致 | 单独是对的 | 结果被改写 | 合并规则：优先级与解析机制 |
苹果侧：合并取严，两类则由声明式优先
同一项设置被多个来源下发时，苹果走的是合并而不是覆盖。官方说明写得很直接：如果把相同设置同时作为描述文件和声明式配置发送到设备，应用的规则与多个描述文件发送设置时相同，系统会合并这些策略并实施最严格的设置。所以「我明明下发了宽松版，为什么还是严的」，通常不是故障，是有另一个来源还挂着严的那一份。
这条规则有两个例外。软件更新与 App 配置，用声明式设备管理下发的优先于类似的设备管理命令，官方把它列为重要事项。查这两类冲突时，先看有没有传统设备管理命令与声明并存——不是比新旧，是按类型定胜负。
另外两种现象容易被误判成冲突。激活是原子化的：一组配置与其引用的所有资源必须全部有效，只要有一个无效，整个关联策略都不会应用，表现是「整段都没上车」而不是「两条打架」。谓词决定 applicability：没有谓词时设备总是处理该激活引用的配置，有谓词时只有求值为真才处理，且设备状态变化后会自动重新求值。想深挖这几条见 苹果设备管理原理。
安卓侧：四套裁决机制，不看下发先后
从 Android 14（API 级别 34）起，多个管理代理可以同时设置政策，平台用一套固定机制裁决，而不是比谁先谁后。绝大多数政策的口径是最严格者胜出：任一代理设了限制，就执行那一条。
判断的可观测依据是两个回调。每次设置政策都会产生 onPolicySetResult，告诉你设成了还是因某个原因失败，文档列举的原因里明确包含政策冲突与硬件故障；如果解析出来的结果后来被别的代理改了，还会收到 onPolicyChanged，告诉你当前生效的是不是你设的那个。换句话说，冲突本身有回执，只是很多人没去看。
表 2 · 四类裁决机制与各自的坑
| 机制 | 怎么裁决 | 代表 API | 踩坑点 |
|---|---|---|---|
| MostRecent | 后设的覆盖先设的 | setPermittedInputMethods | 重启或重新入网后谁最后写不确定 |
| MostRestrictive | 任一来源设了就生效 | setCameraDisabled 等限制类 | 旧来源没撤销，改也改不回去 |
| StringSetUnion | 多个来源的集合取并集 | setUserControlDisabledPackages | 边界是全量并集，不是某一条 |
| TopPriority | 设备锁定管理员优先于企业管理员，再优先于其他 | setLockTaskPackages 等 | 角色变了结果跟着变 |
两点补充说明。角色决定可用范围：代理能设置哪些政策，取决于它担任的 Android 角色。没进这张表的政策只由一个代理支持，根本不会出现冲突；只有多代理同设同一项，才进入裁决流程。厂商侧还有一层单消息内的覆盖关系：单个应用的策略里显式指定了权限口径时，它会覆盖作用于所有应用的同名默认值，粒度更细的条目覆盖粒度更粗的默认值。
黑白名单并存：先定作用域，再定值
表现最多的是三种形态：允许清单与禁止清单同时下发、单对象策略与全局默认并存、条件型规则把同一台设备切成两套。三者的判定顺序其实是同一个，按四问往下走：先看对象有没有被更高优先级的来源接管，再看同一作用域内限制类与允许类谁优先，再看同一设置不同取值怎么合并，最后确认结果是替换还是并存。
最常见的错在第二步的方向上。以为全局默认里的放行会吃掉单对象里的禁止，实际通常是粒度更细的那一条覆盖粒度更粗的默认，方向是反的。第二常见的错在第三步：以为两个来源都设置了同一项，改其中一个就会变，结果另一个来源从未被撤销，看起来就成了「改不动」。
把这两条记牢，能覆盖大部分现场：旧的许可要显式撤销，不要靠删除；同一件事只留一个来源负责。冲突绝大多数不是平台算错了，是来源清单本身已经失管。
最小规则集：五步确认它到底是不是冲突
这套动作的目的不是修好，是把问题从你说不清变成你能指认。
第一步 · 冻结
停止一切下发，导出当前生效的全部来源清单，历史遗留的旧策略一条都别漏
第二步 · 只留一条
把目标策略之外的规则全部置空，只下发这一条，记录设备侧的生效值
第三步 · 逐条加回
一次只加回一条，每次记录生效值。出现拐点的那一条就是冲突源
第四步 · 反证
把嫌疑规则单独下发一次，确认它自己单独的效果，排除巧合
第五步 · 收敛
把最终取值固化到单一来源，其余来源明确置空而不是删除，避免下次复活
第五步最容易被省钱省掉。置空与删除在多代理环境下不是一回事：删掉只是这条不再被下发，别的来源如果还在，结果不变；置空才明确表达了「这一项由另一处负责」。
复盘：从一次故障到一条规则
收尾做三件事：定位到具体是哪一对规则（留下两份来源与时间戳）、写清平台用什么机制裁决的（取严、取最近、还是角色优先）、把结论写进变更清单（下一次改同类设置先看这条）。做完这三件，同类问题第二次出现的概率会明显下降。
权限层面还有四条边界值得写进流程。合同授权：增加或收紧限制要有合同依据。用户知情：事前告知设备会被管理到什么程度。规则透明：同一项设置的最终生效值要能在后台查到，而不是靠回忆。权限最小化：为排查冲突临时开宽口的权限，排查完要立即收回。完整边界见 MDM 合规与授权边界。
- 已导出并核对当前生效的全部策略来源清单
- 单独下发时能复现预期，说明问题在合并层
- 已确认平台对该项用哪种机制裁决
- 旧来源已按侧略显式置空，没有靠删除放行
- 同一项设置只有一个来源负责，且已写进变更清单
- 为排查临时开宽的权限已全部收回
绘盒（厦门绘盒网络科技）做租赁商家的设备管理与经营系统，品牌是绘盒金盾 MDM。9 条产品线覆盖金盾 MDM、荣耀 MDM、小米 MDM（小米官方授权）、风控、支付宝代扣、抖音融合交易、账单分析、CRM 与海外租赁，全部支持独立部署（也就是常说的私有化部署），策略来源、下发记录与冲突回执都留在客户自己的库里。已服务 500+ 家租赁企业（数据口径：取自后台实际运行统计，按季度更新）。选型时怎么问供应商的策略优先级与回执可见性见 MDM 供应商选型清单，全部产品线见 产品中心。
解析机制、命令与参数由平台方定义且可能随版本调整，正式操作请以 Apple 官方文档、AOSP 文档、Android Management API 文档与你所用管理服务的官方说明为准。
常见问题
用一句话分开：单独下发这条规则，能不能复现你要的预期。能，说明下发链路和配置本身都没问题，出事的是「多条规则怎么被合并」这一层；不能，就先回到通道证书、心跳与字段写法上去。还有一个辅助信号是回执：安卓侧每次设置政策都会产生回调，文档明确把政策冲突列为失败原因之一，硬件故障也在同一份列表里，看回执里的原因值比猜快得多。
大多数情况是这样，但不是全部。苹果的官方口径是合并后实施最严格的设置，安卓也说大多数政策以最严格者胜出。但两边都有例外：苹果规定软件更新与 App 配置由声明式下发的优先于类似的设备管理命令；安卓另有取最近一次、按字符串集合取并集、按角色优先级裁决三类机制。所以正确做法是先查该项属于哪种机制，再谈哪条赢，不要默认套「取最严」。
按四问走：先看对象有没有被更高优先级的来源接管（安卓的锁定任务类按角色排优先级：设备锁定管理员优先于企业管理员，再优先于其他管理员）；再看同一作用域内限制类与允许类谁优先，最常见的是粒度更细的那一条覆盖粒度更粗的默认值，方向与你以为的「全局吃掉局部」相反；然后看同一设置不同取值怎么合并（取严、取并集、还是取最近一次）；最后确认结果是替换还是并存。四问问完还没定位，就该怀疑还有第三个来源没被列进清单。
最常见的两个原因。其一是旧来源从未被撤销：你改的是新来源，老的那一份还在设备里挂着，而多数限制类政策是任一来源设了就生效，所以值不会降下来。其二是卸载方式错了：把旧条目「删除」并不代表这一项被放开，多代理环境下要用显式置空来表达「这一项交给另一处负责」。排查时用最小规则集走一遍：冻结、只留一条、逐条加回、反证、收敛，拐点出现在哪一次加回，冲突源就是它。
通常不是，那是激活的原子性在起作用：一组配置与其引用的所有资源必须全部有效，只要有一个无效，整个关联策略都不会应用。表现是整段没上车，而不是两条规则各让一步。另一个容易混淆的是谓词：带谓词的激活只有在求值为真时才处理其引用的配置，没有谓词时才会始终处理；而且设备状态一变，谓词会自动重新求值。这两种现象都不在冲突范畴。
可以，但要把它当成一次有记录的变更，而不是随手操作。四条边界值得写进流程：合同授权（增加或收紧限制要有依据）、用户知情（事前告知设备被管理到什么程度）、规则透明（同一项的最终生效值要能在后台查到）、权限最小化（为排查临时放开的口子，排查完立即收回）。另外放开期间设备处于低防护状态，窗口要压到最短，并在变更记录里写清起止时间。
把一次故障变成一条规则。收尾固定三件事：定位到具体是哪一对规则并留下两份来源与时间戳；写清平台用什么机制裁决（取严、取最近、还是角色优先）；把结论写进变更清单，下一次改同类设置时先读它。再配一条硬习惯：同一项设置只留一个来源负责。冲突绝大多数不是平台算错，是来源清单本身已经失管。
本文引证清单（3 组 · 可展开核对）
本页只引平台官方文档，未引法律法规与司法判例；解析机制由平台定义且随版本演进，具体项以官方文档当前版本与你所用管理服务的说明为准。
安卓侧（Google / AOSP 官方文档）
- 《设备政策解决框架》—— Android 14 起多个管理代理可设置政策、onPolicySetResult 与 onPolicyChanged 两个回调、失败原因含政策冲突与硬件故障、大多数政策最严格者胜出、四类解析机制与各自代表 API、TopPriority 角色优先顺序、未列入清单的政策不存在冲突（核对日 2026-10-28）
- Android Management API《enterprises.policies / ApplicationPolicy》—— 单个应用策略其中的权限口径覆盖作用于所有应用的默认值、installType 为特定类型时每条 policy 只能设置一个应用、版本未达标上报 APP_NOT_UPDATED（核对日 2026-10-28）
苹果侧（Apple 官方文档与会议资料）
- 《使用声明式设备管理来管理 Apple 设备》（2024-12-11 发布）—— 相同设置由描述文件与声明式配置同时下发时合并并实施最严格设置、软件更新与 App 配置由声明式优先、激活谓词与自定义管理属性、适用版本门槛（核对日 2026-10-28）
- WWDC21《Meet declarative device management》—— 激活的原子性、激活与配置多对多关系、无谓词时始终处理、状态变化时自动重新求值（核对日 2026-10-28）
本方运营口径（非外部依据，供核对用）
- 三类现象分层对照表、四类裁决机制的踩坑点、黑白名单四问判定顺序、最小规则集五步验证法与六条复盘自查 —— 均为本方运营建议，可按自身设备形态、管理平台版本与团队流程调整（核对日 2026-10-28）
本页不承诺任何排查结果，也不代替你所用管理平台的技术支持判断；具体命令、参数与裁决口径以官方现行文档为准。