飞行模式大概是Android里最常被用户触碰的系统级开关之一，但奇怪的是，翻遍公开SDK文档，你会发现没有一条正规API允许普通应用直接切换它。谷歌对这类系统级模式的管控远比表面看起来复杂，涉及全局设置数据库、系统广播、SELinux策略等多个层面。本文从底层原理出发，拆解Android如何控制飞行模式开关，以及在开发中有哪些合规或变通的实现路径。
一、飞行模式的底层实现：Settings.Global与广播链路
Android系统中，飞行模式的当前状态并不是保存在某个应用的私有存储里，而是记录在全局设置数据库中。早期的Android版本使用Settings.System，从Android 4.2（API 17）开始，这个值被迁移到了Settings.Global命名空间，键名为AIRPLANE_MODE_ON。读取当前状态非常简单：
public boolean isAirplaneModeOn(Context context) {
return Settings.Global.getInt(context.getContentResolver(),
Settings.Global.AIRPLANE_MODE_ON, 0) != 0;
}
写入则完全是另一回事。普通应用调用Settings.Global.putInt()尝试修改这个值时，会被系统直接抛出SecurityException，因为Global命名空间下的写入操作要求调用方持有android.permission.WRITE_SECURE_SETTINGS权限，而这是一个signature|privileged级别的权限，只有平台签名应用或安装在system/priv-app目录下的系统应用才能获得。
真正触发飞行模式切换的流程是这样的：应用或系统UI修改AIRPLANE_MODE_ON的值，随后广播Intent.ACTION_AIRPLANE_MODE_CHANGED。SystemServer中的相关服务（主要是NetworkPolicyManagerService和各连接服务）收到广播后，依次关闭蜂窝网络、蓝牙、Wi-Fi等无线电模块。理解这条链路很重要——它说明飞行模式本质上是一组无线电模块状态的总开关，而不是一个独立功能。
二、为什么第三方应用被禁止直接控制
谷歌收紧这个权限的核心原因是安全边界问题。设想一下，如果任意一个申请了普通权限的应用都能关闭手机的所有无线连接，后果会非常严重：反盗窃定位机制会失效，远程管理类应用会失去与服务端的联系，用户在紧急情况下也可能因为恶意软件悄悄开启飞行模式而无法拨打电话。因此Android把飞行模式归入“影响设备基础通信能力”的操作类别，与关机、重启等操作同级管控。
另一个技术层面的原因是状态一致性。前面提到，飞行模式涉及多个服务的联动——RadioInterfaceLayer、BluetoothManager、WifiManager都要同步切换状态。如果允许多个应用并发地直接改写全局设置值，很容易出现广播乱序、模块状态不同步的问题。谷歌的解决方案是让设置写入只能通过一个受控入口（系统设置应用）进行，保证整个切换过程原子且有序。
此外还有一个历史遗留问题值得注意。Android 4.2之前，应用可以发送AIRPLANE_MODE_CHANGED广播来欺骗系统切换状态；4.2之后这个广播被改为protected broadcast，只有系统进程才能发送，第三方应用发送会直接被SecurityException拦截。很多老代码迁移到新版本时报错，根源就在这里。
三、开发中可行的三种实现方案
方案一：引导用户手动切换
最稳妥也最符合谷歌政策的方式，是读取状态后引导用户自己操作。Android提供了对应的系统面板意图：
private void openAirplaneSettings(Context context) {
Intent intent = new Intent(Settings.ACTION_AIRPLANE_MODE_SETTINGS);
intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK);
context.startActivity(intent);
}
这种方式没有任何权限风险，上架应用市场不会遇到审核问题，缺点是无法真正自动完成切换，只适合作为功能的辅助入口。
方案二：设备管理员或Device Owner
面向企业MDM场景，Android 9（API 28）为设备所有者应用提供了setGlobalSetting的间接能力，结合受限设置管理可以实现一定程度的策略控制。但要注意，谷歌对设备所有者应用管控飞行模式同样有限制：完全禁止用户关闭无线电的场景才有意义，普通企业应用不应该尝试用它来做日常开关控制，Play商店审核对此非常严格。
方案三：ADB命令与自动化测试
在自动化测试、CI流水线或自己拥有设备的场景下，ADB是最直接的途径：
# 开启飞行模式 adb shell settings put global airplane_mode_on 1 adb shell am broadcast -a android.intent.action.AIRPLANE_MODE_CHANGED --ez state true # 关闭飞行模式 adb shell settings put global airplane_mode_on 0 adb shell am broadcast -a android.intent.action.AIRPLANE_MODE_CHANGED --ez state false
这套命令之所以能生效，是因为ADB shell进程拥有WRITE_SECURE_SETTINGS权限，本质上是借用了系统通道。如果你在开发中需要应用内执行，可以借助su（需要root）或通过adb shell pm grant给调试包临时授予该权限：
adb shell pm grant com.your.debug.package android.permission.WRITE_SECURE_SETTINGS
授权后的调试包就能直接调用Settings.Global.putInt()并手动发送广播（注意发送系统保护广播仍然不行，需配合settings命令）。这种方式仅适用于调试构建，正式发布版本不可能要求用户连接电脑授权。
四、定制ROM与系统应用开发者的路径
如果你是ROM开发者或系统应用开发者，情况则完全不同。将应用以平台签名编译，或在AndroidManifest中声明android:sharedUserId="android.uid.system"并放入priv-app目录，即可获得WRITE_SECURE_SETTINGS权限，之后就能像系统设置应用一样自由控制飞行模式。另外，部分厂商ROM提供了私有API或扩展服务（如通过AIDL暴露的Vendor服务），但这类接口碎片化严重，依赖它们意味着绑定特定厂商，跨设备兼容性会很差。
还有一个容易踩坑的点：不同厂商对飞行模式的行为定制不一致。例如有的设备切换后Wi-Fi可以单独重新打开（遵循Android 4.2后的标准行为），有的则强制全部关闭。读取状态时也不要只依赖AIRPLANE_MODE_ON这一个值，最好同时检测Settings.Global.RADIO_BLUETOOTH、RADIO_WIFI等键值，才能准确判断各模块的真实状态。
五、总结
Android对飞行模式的管控体现了一个设计原则：凡涉及设备基础通信能力的操作，必须收敛到受信任的系统入口。对普通应用开发者而言，正确的做法是读取状态、引导用户手动切换；对测试与工具链开发者，ADB加上临时权限授权已经足够覆盖绝大多数需求；只有系统开发者才拥有直接写全局设置的完整能力。理解Settings.Global、保护广播与系统权限三者之间的关系，不仅能解决飞行模式这一个具体问题，也能举一反三地理解Android对其他系统级开关（如数据流量、定位总开关）的管控思路。
Android飞行模式系统级权限ADB命令修改时间：2026-09-06 12:52:39