【HarmonyOS 6.0】MDM Kit 进阶:restrictions 模块五大新策略
文章目录

1 -> 文章概述与引言
随着企业移动办公场景的持续深化,金融、政务、军工等对安全性要求极高的行业,对于移动终端设备精细化管控的需求呈现出快速增长的态势。早期的MDM(Mobile Device Management,移动设备管理)方案主要停留在“管应用、管安装、管卸载”的层面,但企业真实的业务需求早就远远超出了这一范畴。在实际的管理实践中,除了管控第三方应用,企业对系统底层的能力开关同样有强烈的控制需求,例如在网络数据访问、通信渠道隔离以及支付安全管控等方面,都需要系统级的干预能力。
鸿蒙操作系统在其6.0版本中,对MDM Kit(企业设备管理服务套件)进行了深度的功能扩展。据统计,HarmonyOS 6.0 在 MDM Kit 上开放的各类系统 API 已经超过了 300 项,这些接口广泛覆盖了设备管理、网络配置、应用分发、KIOSK 展台模式等多个关键业务域。在这一次的大版本更新中,restrictions 模块(即限制类策略模块)获得了五个备受瞩目的新特性:短信管控(sms)、蜂窝数据管控(mobileData)、飞行模式管控(airplaneMode)、通知消息管控(notification)以及 NFC 管控(nfc)。这些新增的策略特性不仅仅是 API 清单上的几行代码,它们的出现标志着鸿蒙企业设备管理体系实现了从基础硬件控制到通信链路和数据通道管控的一次质的提升,使企业 IT 管理员拥有了更全面的围栏管控手段。
本文将立足于鸿蒙 MDM Kit 最新的技术文档和 API 接口定义,由浅入深地对这五项管控策略进行拆解。从 MDM Kit 的基础架构、restrictions 模块的核心设计原理,到每个特性的具体参数说明、权限依赖以及代码落地实现,本文都会进行详细阐述,力求为正在从事鸿蒙企业级应用开发的工程师提供一份具有实际操作参考价值的实践文档。
2 -> MDM Kit 与 restrictions 模块的技术脉络
2.1 -> MDM Kit 的全局视角
Mobile Device Management (MDM) 是一种企业级的 IT 应用解决方案,其核心目的是管理和保护企业设备上的数据与应用。在鸿蒙 6.0 的架构体系中,MDM Kit 作为支撑企业移动设备管理的核心功能集,并非是一个单一的 API,而是一个由多个功能子模块组成的系统性能力集合,涵盖应用管理、通信管理、安全管理、禁用管理、设备设置与查询、硬件外设管理等多个方面。
这里需要特别说明的一点是,并非任意一个普通的鸿蒙应用都有权限调用 MDM Kit 中的接口。只有具备特定资质的企业级应用——即已经通过激活流程获取设备管理权限的 MDM 应用,才有权限调用这些策略接口。开发这类应用需要在项目的 Module.json5 配置文件中声明 EnterpriseAdminExtensionAbility,并且在设备端完成激活流程,使应用获得企业设备管控的授权。
2.2 -> restrictions 模块的核心定位
在 MDM Kit 的众多模块当中,@ohos.enterprise.restrictions 模块扮演着一个非常特殊且重要的角色。这个模块专门负责设备通用功能的全局限制控制,其核心价值在于通过一个标准化的接口,实现对设备底层能力的统一管理。无论目标是禁用蓝牙(bluetooth)、关闭 Wi-Fi,还是本文将要重点展开的禁用短信功能或者限制蜂窝数据网络,开发者调用的都是同一个核心 API:restrictions.setDisallowedPolicy。
restrictions 模块首批接口自 API version 12 开始支持,该模块仅可在 Stage 模型下使用,且仅对已激活的设备管理应用开放,调用相关接口前需要提前激活设备管理应用。
2.3 -> setDisallowedPolicy 接口的设计原则与冲突规则
setDisallowedPolicy 是这个模块中最核心、最常用的接口之一。其方法签名如下:
setDisallowedPolicy(admin: Want, feature: string, disallow: boolean): void
关于这个接口的设计与执行,有几个非常重要的技术原则需要开发者理解清楚:
第一,全局作用域。 一旦通过 MDM 应用将某个特性设为禁用(即 disallow 参数传入 true),那么这个限制策略将作用于整个设备的系统层面,而不仅仅是针对某一个特定用户或者某几个特定应用。
第二,冲突规则从严管控。 在实际的企业设备管理环境中,一个设备上完全可能存在多个 MDM 管理应用同时运行的情况。为了防止策略冲突带来的混乱,HarmonyOS 的设计者引入了“从严管控”的冲突规则:如果存在多个设备管理应用,只要其中有一个应用对该特性提出了“禁用”的要求,那么系统最终的生效策略就是禁用;只有所有持有管控权限的 MDM 应用都移除了对该特性的“禁用”指令,限制策略才会解除。
第三,持久化存储。 策略设置之后会被系统持久化保存在设备中,即使设备执行重启操作,之前设置的禁用策略在系统重启后依然会保持生效状态,直到被新的 MDM 应用策略显式地清除或覆盖。
2.4 -> 使用 MDM Kit 的前置准备工作
在实际动手编写代码之前,开发者需要确保自己的应用满足以下几个必要条件:
- 应用类型要求:调用方必须是一个已经成功激活的企业设备管理应用。普通第三方应用不具备调用资格。
- 模型约束:必须在 Stage 模型下使用,这一点在工程创建时就需要明确。
- 权限声明:根据要设置的特性类型的不同,需要在应用的 module.json5 文件中声明相应的权限。例如,禁用短信(sms)需要声明
ohos.permission.ENTERPRISE_MANAGE_RESTRICTIONS;而禁用蜂窝数据(mobileData)和飞行模式(airplaneMode)则需要声明ohos.permission.ENTERPRISE_MANAGE_NETWORK。
3 -> 新增五大特性深度剖析与实战
接下来,我们将逐一深入解析这五项新增管控特性。每一部分的讲解将涵盖功能说明、所需权限、设备形态限制、完整的代码实现示例以及在实际开发中需要注意的关键点。
3.1 -> 短信管控(sms)
3.1.1 -> 功能说明
短信功能一直是企业数据安全治理中的重点关注对象。从 API 20 版本开始,restrictions.setDisallowedPolicy 接口新增了 sms 管控项,用于控制设备发送和接收短信的能力。此项策略主要服务于那些对信息泄露防范要求极高的场景。例如在金融机构的外勤业务终端、涉及敏感信息的政府办公设备等场景中,企业通常需要禁用原生短信应用,强制要求员工通过企业自有的安全加密通讯应用来传递业务信息。
3.1.2 -> 所需权限与设备限制
- 所需权限:
ohos.permission.ENTERPRISE_MANAGE_RESTRICTIONS - 设备形态限制:当前仅支持手机、平板设备使用,PC(电脑形态的设备)不在支持范围内。
3.1.3 -> 代码示例
以下是一个完整的 ArkTS 代码示例,演示如何通过 MDM 应用禁用设备的短信能力:
import { Want } from '@kit.AbilityKit';
import { restrictions } from '@kit.MDMKit';
/**
* 禁用设备的短信功能
* @param adminWant - 当前设备管理应用的Want对象
*/
function disableDeviceSms(adminWant: Want): void {
try {
// 第一个参数传入激活的设备管理应用的Want对象
// 第二个参数传入特性名称"sms",第三个参数传入true表示禁用
restrictions.setDisallowedPolicy(adminWant, 'sms', true);
console.info('短信功能已成功禁用');
} catch (err) {
console.error(`禁用短信功能失败,错误码: ${err.code}, 错误信息: ${err.message}`);
}
}
/**
* 恢复(启用)设备的短信功能
* @param adminWant - 当前设备管理应用的Want对象
*/
function enableDeviceSms(adminWant: Want): void {
try {
// 将disallow参数设置为false即可恢复短信功能
restrictions.setDisallowedPolicy(adminWant, 'sms', false);
console.info('短信功能已成功恢复');
} catch (err) {
console.error(`恢复短信功能失败,错误码: ${err.code}, 错误信息: ${err.message}`);
}
}
3.1.4 -> 关键注意事项
禁用 sms 之后,设备的内置短信应用将无法发送和接收短消息。但是需要特别说明的是,这一策略限制的是系统层面的短信能力,企业自研的网络通讯应用(通过 VoIP 或即时通讯协议收发消息的应用)并不受该策略的影响——因为这类应用依赖的是网络数据通道而非传统短信服务。这一点对于企业中规划混合通信策略非常重要,值得在架构设计阶段就予以充分考虑。
3.2 -> 蜂窝数据管控(mobileData)
3.2.1 -> 功能说明
蜂窝数据(即我们日常所说的“移动数据网络”)管控是企业控制移动设备联网行为的重要手段。该策略通过 mobileData 特性名称进行标识,可以对设备的蜂窝数据能力进行全局禁用或恢复。这一功能在企业场景中有很高的实用价值,特别是在一些需要严格控制网络访问的应用场景下——例如在海外差旅场景中,为了避免产生高昂的国际漫游数据费用,IT 部门可以通过 MDM 平台远程批量为差旅人员的设备禁用蜂窝数据,同时保留企业内网环境或受信 Wi-Fi 网络的访问权限。
3.2.2 -> 所需权限与设备限制
- 所需权限:
ohos.permission.ENTERPRISE_MANAGE_NETWORK - 设备形态限制:当前仅支持手机、平板设备使用。
3.2.3 -> 代码示例
import { Want } from '@kit.AbilityKit';
import { restrictions } from '@kit.MDMKit';
/**
* 禁用设备的蜂窝数据(移动数据)功能
* @param adminWant - 当前设备管理应用的Want对象
*/
function disableMobileData(adminWant: Want): void {
try {
restrictions.setDisallowedPolicy(adminWant, 'mobileData', true);
console.info('蜂窝数据已成功禁用');
} catch (err) {
console.error(`禁用蜂窝数据失败,错误码: ${err.code}, 错误信息: ${err.message}`);
}
}
/**
* 启用设备的蜂窝数据功能
* @param adminWant - 当前设备管理应用的Want对象
*/
function enableMobileData(adminWant: Want): void {
try {
restrictions.setDisallowedPolicy(adminWant, 'mobileData', false);
console.info('蜂窝数据已成功启用');
} catch (err) {
console.error(`启用蜂窝数据失败,错误码: ${err.code}, 错误信息: ${err.message}`);
}
}
3.2.4 -> 关键注意事项
这里有一个容易被忽略的细节需要注意:mobileData 管控项与 airplaneMode 管控项在设备行为上存在一定的关联影响。如果设备处于飞行模式开启的状态,由于飞行模式会从系统层面切断所有无线通信能力(包括蜂窝模块),此时通过 MDM 接口禁用或启用 mobileData 的效果可能不会立即体现在界面上。在实际开发中,如果需要确保蜂窝数据的策略能够精确生效,建议先通过 airplaneMode 的管控接口确保设备未处于飞行模式锁定状态下。
3.3 -> 飞行模式管控(airplaneMode)
3.3.1 -> 功能说明
飞行模式是一项用户熟悉的系统功能,开启后会切断蜂窝网络、Wi-Fi 和蓝牙等无线通信。从企业管控的角度来看,飞行模式的自主开关权限是非常关键的管理点。在考试防作弊场景中,如果考生在考试过程中私自打开飞行模式,有可能导致考试应用无法联网提交答案,甚至可能被用于绕过系统的网络监控。因此,通过 airplaneMode 管控项锁定飞行模式的开关状态,可以有效保障业务应用的网络连通性和安全性。
3.3.2 -> 所需权限与设备限制
- 所需权限:
ohos.permission.ENTERPRISE_MANAGE_NETWORK - 设备形态限制:当前仅支持手机、平板设备使用。
3.3.3 -> 代码示例
import { Want } from '@kit.AbilityKit';
import { restrictions } from '@kit.MDMKit';
/**
* 禁用飞行模式(即禁止用户在设备上开启飞行模式)
* @param adminWant - 当前设备管理应用的Want对象
*/
function disableAirplaneMode(adminWant: Want): void {
try {
restrictions.setDisallowedPolicy(adminWant, 'airplaneMode', true);
console.info('飞行模式已被禁止开启,用户无法在系统设置中启用飞行模式');
} catch (err) {
console.error(`禁用飞行模式失败,错误码: ${err.code}, 错误信息: ${err.message}`);
}
}
/**
* 启用飞行模式功能(即允许用户在设备上自由开关飞行模式)
* @param adminWant - 当前设备管理应用的Want对象
*/
function enableAirplaneMode(adminWant: Want): void {
try {
restrictions.setDisallowedPolicy(adminWant, 'airplaneMode', false);
console.info('飞行模式功能已恢复,用户可以自由控制飞行模式的开关');
} catch (err) {
console.error(`启用飞行模式功能失败,错误码: ${err.code}, 错误信息: ${err.message}`);
}
}
3.3.4 -> 关键注意事项
将 airplaneMode 设置为禁用(即 disallow = true)后,用户将无法在系统控制中心或者“设置”应用中开启飞行模式。但是,如果在设置禁用策略之前设备已经处于飞行模式开启状态,那么该策略仅会阻断后续的开关操作,设备当前已有的飞行模式状态并不会被自动撤销。在实际应用场景中,建议 IT 管理者在执行策略下发前,先做好设备状态的初始化检查,或者在策略下发后引导用户进行必要的网络重启操作。
3.4 -> 通知消息管控(notification)
3.4.1 -> 功能说明
通知消息管控是企业级设备管理中一个非常实用但又很容易被忽略的管控维度。notification 特性用于控制设备上所有应用的通知消息显示能力。当禁用后,系统应用和第三方应用发出的所有通知将不会被显示在通知栏中,也不会出现横幅提示或角标提示,但系统核心服务的通知能力不受此策略影响。这一能力在考试专用的 KIOSK 展台设备上应用较多——通过禁用通知消息,可以避免各类社交应用的弹窗提醒干扰考生的注意力;同时也可以防止应用通知中可能携带的敏感信息在不恰当的时机暴露到设备锁屏上。
3.4.2 -> 所需权限与设备限制
- 所需权限:
ohos.permission.ENTERPRISE_MANAGE_RESTRICTIONS - 设备形态限制:无明确的设备形态限制,通用能力。
3.4.3 -> 代码示例
import { Want } from '@kit.AbilityKit';
import { restrictions } from '@kit.MDMKit';
/**
* 禁用设备上的所有通知(包括系统应用和三方应用的通知)
* @param adminWant - 当前设备管理应用的Want对象
*/
function disableAllNotifications(adminWant: Want): void {
try {
restrictions.setDisallowedPolicy(adminWant, 'notification', true);
console.info('设备的通知显示能力已被禁用,所有应用的通知均不会显示');
} catch (err) {
console.error(`禁用通知失败,错误码: ${err.code}, 错误信息: ${err.message}`);
}
}
/**
* 恢复设备上的通知显示能力
* @param adminWant - 当前设备管理应用的Want对象
*/
function enableAllNotifications(adminWant: Want): void {
try {
restrictions.setDisallowedPolicy(adminWant, 'notification', false);
console.info('设备的通知显示能力已恢复');
} catch (err) {
console.error(`恢复通知失败,错误码: ${err.code}, 错误信息: ${err.message}`);
}
}
3.4.4 -> 关键注意事项
这里有一个在开发调试中容易踩到的坑,需要特别提一下。setDisallowedPolicy 的 notification 策略与 applicationManager 模块中的 addAllowedNotificationBundles(应用通知白名单)接口存在明确的冲突关系。根据官方文档的说明,当设备已经通过 addAllowedNotificationBundles 接口设置了某个或某几个应用的通知白名单之后,再通过 restrictions.setDisallowedPolicy 接口禁用设备整体的通知能力,系统会抛出错误码 9200010。
因此,如果企业在策略规划阶段已经配置了精细化的“仅允许特定应用发送通知”的白名单策略,那么在此之后再执行全局禁用 notification 的操作就会直接失败。在实际的企业 MDM 管控方案设计中,需要明确“全局禁用通知”与“白名单精细化管控”之间的互斥关系,在部署策略前做好充分的自检和协调。
3.5 -> NFC 管控(nfc)
3.5.1 -> 功能说明
NFC(近场通信,Near Field Communication)能力在现代移动设备上的应用场景越来越丰富,从移动支付、交通卡刷卡、门禁识别到设备配对等,都离不开这项能力。在企业设备管控场景中,针对 NFC 功能的控制需求同样存在。例如在金融行业的外勤业务终端上,通过禁用 NFC 可以防止设备被非法用于盗刷银行卡或者读取企业内部的门禁卡信息;在军工等对物理数据交换安全有极高要求的场所,禁用 NFC 可以有效阻断通过接触式通信窃取数据的风险。
3.5.2 -> 所需权限与设备限制
- 所需权限:
ohos.permission.ENTERPRISE_MANAGE_RESTRICTIONS - 设备形态限制:当前仅支持手机、平板设备使用。
3.5.3 -> 代码示例
import { Want } from '@kit.AbilityKit';
import { restrictions } from '@kit.MDMKit';
/**
* 禁用设备的NFC(近场通信)功能
* @param adminWant - 当前设备管理应用的Want对象
*/
function disableNfc(adminWant: Want): void {
try {
restrictions.setDisallowedPolicy(adminWant, 'nfc', true);
console.info('NFC功能已被禁用,设备无法进行任何NFC通信');
} catch (err) {
console.error(`禁用NFC失败,错误码: ${err.code}, 错误信息: ${err.message}`);
}
}
/**
* 恢复设备的NFC功能
* @param adminWant - 当前设备管理应用的Want对象
*/
function enableNfc(adminWant: Want): void {
try {
restrictions.setDisallowedPolicy(adminWant, 'nfc', false);
console.info('NFC功能已成功恢复');
} catch (err) {
console.error(`恢复NFC失败,错误码: ${err.code}, 错误信息: ${err.message}`);
}
}
3.5.4 -> 关键注意事项
禁用 NFC 功能之后,受影响的不仅仅是支付类的应用。实际上,所有依赖于 NFC 硬件模块的服务都会受到阻断,包括但不限于读取 NFC 标签、手机间基于 NFC 的快速配对、通过 NFC 模拟门禁卡或交通卡等场景。这一策略的实施需要跟企业的实际业务场景进行充分地适配和验证,避免因为策略的过度禁用而影响到员工正常的工作效率。例如,如果一个企业的办公区域采用了 NFC 门禁系统且员工使用手机刷卡进出门禁,那么在全量设备上禁用 NFC 之前就需要先评估这一策略对员工日常办公的便利性所带来的影响。
4 -> 典型业务场景与组合策略建议
新增的这五项管控特性单独使用时各有其价值,但在真实的业务场景中,企业 IT 管理员往往更倾向于将它们与已有的管控能力进行组合使用,以构建更为全面的设备管控方案。
以高安全级别的 移动考试终端 为例,一套完整的设备管控策略可以由以下几个层面构成:
- 结合
airplaneMode禁用飞行模式,确保考试终端在整个考试期间始终保持网络连通状态,防止考生利用飞行模式规避网络监控。 - 结合
sms禁用短信收发,防止考生在考试过程中通过短信方式接收外部信息或者对外传递试题内容。 - 结合
notification禁用通知显示,屏蔽各类社交应用、即时通讯工具和系统自带的提醒消息,避免干扰考生的考试注意力并防止敏感信息的外泄。 - 结合
mobileData对蜂窝数据网络进行精细化管控,在已经接入考场专用 Wi-Fi 网络的前提下禁用蜂窝数据可以进一步降低从其他移动通信链路泄密的风险。 - 结合
nfc禁用近场通信功能,防止考生尝试利用 NFC 传输数据与外部设备建立物理连接。 - 结合已有的
camera(相机)和screenshot(截图)等限制策略,进一步完善防作弊的围栏体系。
在 COPE(企业统一派发设备)场景下,这些新增的管控策略同样有广泛的适用价值。COPE 是指企业统一购买笔记本电脑、平板电脑、智能手机等设备并分发给员工使用,这类设备的所属权属于企业,企业对设备拥有完整的管理权限。企业可以根据不同岗位对设备功能使用上的差异化需求,对员工设备上的短信、蜂窝数据、NFC 等能力进行差异化的“功能裁剪”,从而在安全性需求和员工使用体验之间找到一个合理的平衡点。
5 -> 总结与展望
HarmonyOS 6.0 在 MDM Kit 的 restrictions 模块中新增的短信(sms)、蜂窝数据(mobileData)、飞行模式(airplaneMode)、通知消息(notification)和 NFC(nfc)这五项管控特性,其意义不仅仅在于“开放了五个新的 API 接口”这么简单。从更宏观的视角来看,这标志着鸿蒙企业设备管理体系的管控能力正在从硬件层和基础应用层,向通信层和数据交互层实现纵深拓展。这意味着企业 IT 管理者现在拥有了更加丰富和灵活的系统级策略编制能力,能够依据不同的业务场景和风险等级对设备实现精准的、颗粒化的控制。
从技术演进趋势来看,未来的 MDM Kit 还将持续增加更多的管控维度。从当前已发布的技术文档中可以看到,restrictions 模块在后续版本中还会持续新增更多的特性和管控能力,设备通话能力(telephoneCall)、彩信能力(mms)、应用分身能力(appClone)等更多维度的管控项已经在路线图中显露雏形。此外,随着 BYOD(自带设备办公)、COPE 以及专用设备(Dedicated Device)等不同设备管理模式逐步走向深度融合,MDM Kit 在企业移动信息化建设中的价值会越来越突出,鸿蒙 6.0 及其后续版本在这一领域的技术积累会为开发者带来更加完善的移动设备管理生态。
对于正在从事 MDM 应用开发的工程师来说,深入理解和掌握 restrictions 模块以及 setDisallowedPolicy 接口的工作原理,是搭建坚实的企业设备管控方案的第一步。希望本文对这五项新增策略的梳理、分析和代码实践,能够为大家在实际开发过程中的技术落地提供一些有价值的参考。
更多推荐




所有评论(0)