Android关机重启广播监听全解析：从原理到兼容性实现

1. 项目概述：为什么监听关机重启广播是个“技术活”？

在Android开发中，监听系统广播是获取设备状态变化最直接、最常用的手段之一。无论是应用需要保存最后的状态，还是服务需要在设备重启后自动拉起，亦或是实现一些特殊的系统级功能，都离不开对系统广播的监听。其中，ACTION_SHUTDOWN（关机广播）和ACTION_REBOOT（重启广播）无疑是两个重量级的系统事件。乍一看，这似乎是个简单的BroadcastReceiver注册问题，但真正深入进去，你会发现从权限申请、接收器注册方式、到不同Android版本的适配、乃至后台限制的规避，每一步都藏着“坑”。很多开发者，包括一些有经验的同行，都曾在这里踩过雷——比如监听不到、接收延迟，或者在Android 8.0（API 26）之后直接失效。今天，我们就来彻底拆解这个“技术活”，从原理到实践，从兼容性到避坑指南，手把手带你实现一个稳定可靠的关机重启监听方案。无论你是需要实现数据安全保存、服务保活，还是开发系统工具类应用，这篇文章都能给你提供可直接落地的参考。

2. 核心原理与广播机制深度解析

2.1 Android广播系统的工作机制

要理解如何监听关机重启广播，首先得明白Android的广播（Broadcast）系统是怎么运转的。你可以把它想象成一个全小区的大喇叭（系统）和每家每户的对讲机（应用）。当系统发生某个特定事件（比如停电关机、物业通知重启电梯）时，大喇叭就会喊一嗓子。那些事先表示“我对停电通知感兴趣”的住户（注册了对应BroadcastReceiver的应用），他们的对讲机就会响起来。

在技术层面，这个过程涉及几个核心角色：

1. 发送者（BroadcastSender）：通常是Android系统框架（ActivityManagerService等系统服务）。对于关机重启，发送者就是系统在关机/重启流程的某个环节。
2. 广播（Intent）：这是一个携带了行动指令（Action）和可能附带数据（Extras）的消息对象。关机广播的Action是Intent.ACTION_SHUTDOWN，重启广播的Action是Intent.ACTION_REBOOT。
3. 接收者（BroadcastReceiver）：我们编写的，用于响应特定广播的类。它只有一个核心方法onReceive(Context context, Intent intent)，当匹配的广播到来时，系统会调用这个方法。
4. 注册中心（ActivityManagerService）：负责管理广播的发送和接收匹配。应用通过清单文件（静态注册）或代码（动态注册）向它“订阅”感兴趣的广播。

对于关机重启这类有序广播（Ordered Broadcast），系统还会设定优先级（Priority），允许高优先级的接收者先接收，甚至可以中止广播的继续传递（虽然对于系统广播，开发者通常无权中止）。理解这个机制，是后续解决监听问题的理论基础。

2.2 关机与重启广播的独特性

ACTION_SHUTDOWN和ACTION_REBOOT广播与普通的应用间广播有显著不同，这也正是其监听复杂性的根源：

• 系统级权限：它们是受保护的广播。从Android 3.1开始，系统加强了对广播的限制，许多系统广播不再能被第三方应用随意监听。关机重启广播正在此列。这意味着，仅仅在清单文件中声明<receiver>是远远不够的。
• 发送时机关键：广播的发送时机非常靠前，位于关机/重启流程的早期。系统会先发送广播，然后再逐一关闭应用进程、卸载存储等。这给了应用一个短暂但宝贵的窗口期来执行紧急操作，比如将内存中的关键数据刷入数据库或本地文件。但这个窗口期很短，通常只有几秒钟，所以onReceive方法中的操作必须轻量、快速，绝对不允许执行耗时操作（如网络请求）。
• 静态注册的局限性：在Android 8.0之后，谷歌为了优化系统性能和电池续航，对后台执行施加了严格限制。其中一条就是：大多数隐式广播（implicit broadcast，即不指定具体包名的广播）不允许在清单文件中进行静态注册。而ACTION_SHUTDOWN和ACTION_REBOOT恰恰就是隐式广播。这意味着，在Android 8.0及以上的设备上，仅通过静态注册的接收器将完全无法收到这两个广播。这是一个至关重要的分水岭，也是很多监听方案在新系统上失效的根本原因。

3. 实现方案选型与适配策略

面对不同Android版本的差异，我们需要设计一个兼容性的方案。核心思路是：静态注册与动态注册相结合，并针对高版本系统进行特殊处理。

3.1 方案一：静态注册（针对Android 8.0以下设备）

这是最传统、理论上最可靠的方式，因为即使应用进程不在运行，系统也能在发送广播时唤醒你的接收器。

实现步骤：

1. 在AndroidManifest.xml中声明接收器并申请权限：

   <uses-permission android:name="android.permission.SHUTDOWN" /> <!-- 注意：SHUTDOWN权限的protectionLevel是signature|privileged， 普通应用无法直接获取，但声明它有时是必要的，具体见下文分析 --> <application ...> <receiver android:name=".ShutdownReceiver" android:enabled="true" android:exported="true"> <intent-filter android:priority="1000"> <!-- 设置高优先级 --> <action android:name="android.intent.action.ACTION_SHUTDOWN" /> <action android:name="android.intent.action.ACTION_REBOOT" /> </intent-filter> </receiver> </application>

   注意：android.permission.SHUTDOWN是一个系统级签名权限（signature|privileged）。这意味着只有使用系统平台证书签名的应用（即系统应用或预装在/system/分区的应用）才能获得此权限。普通第三方应用声明此权限是无效的。那为什么我们还要声明？在某些旧的或特定厂商定制的系统上，系统检查可能不那么严格，声明它可能有助于通过某些检查。但对于绝大多数标准设备，监听的关键不在此权限，而在于接收器能否被调用。

2. 实现BroadcastReceiver类：

   class ShutdownReceiver : BroadcastReceiver() { override fun onReceive(context: Context, intent: Intent) { when (intent.action) { Intent.ACTION_SHUTDOWN -> { Log.d(“ShutdownReceiver”, “设备正在关机...”) // 执行紧急保存操作，例如： // 1. 将SharedPreferences提交（commit，不能用apply） // 2. 关闭数据库连接并确保事务完成 // 3. 向持久化服务发送一个保存命令（通过startService或发送有序广播） // 切记：这里不能做任何异步或耗时操作！ performEmergencySave(context) } Intent.ACTION_REBOOT -> { Log.d(“ShutdownReceiver”, “设备正在重启...”) // 重启广播的处理逻辑通常与关机类似 performEmergencySave(context) } } } private fun performEmergencySave(context: Context) { // 示例：同步保存状态到SharedPreferences val prefs = context.getSharedPreferences(“app_state”, Context.MODE_PRIVATE) prefs.edit().putBoolean(“was_shutting_down”, true).commit() // 必须用commit！ // 可以发送一个启动服务的Intent，但服务必须在onStartCommand中快速处理 val serviceIntent = Intent(context, EmergencySaveService::class.java) context.startService(serviceIntent) } }

此方案的局限性：如前所述，在Android 8.0 (API 26) 及以上，针对隐式广播的静态注册限制将导致此接收器失效。用户关机时，你的应用将收不到任何通知。

3.2 方案二：动态注册（应对Android 8.0+的限制）

为了绕过高版本的限制，我们必须让应用进程在关机事件发生时是活跃的，并通过代码动态注册广播接收器。动态注册的广播接收器，其生命周期与注册它的组件（如Activity、Service）绑定。

核心思路：创建一个前台服务（Foreground Service），在该服务的onCreate()中动态注册关机重启广播的接收器。只要服务保持运行，接收器就有效。

实现步骤：

1. 创建一个前台服务：

   class ShutdownMonitorService : Service() { private lateinit var shutdownReceiver: BroadcastReceiver override fun onCreate() { super.onCreate() // 创建广播接收器实例 shutdownReceiver = object : BroadcastReceiver() { override fun onReceive(context: Context, intent: Intent) { handleShutdownOrReboot(context, intent) } } // 动态注册接收器 val filter = IntentFilter().apply { addAction(Intent.ACTION_SHUTDOWN) addAction(Intent.ACTION_REBOOT) priority = IntentFilter.SYSTEM_HIGH_PRIORITY // 尝试设置高优先级 } registerReceiver(shutdownReceiver, filter) // 启动前台服务，避免被系统杀死 startForegroundService() } private fun startForegroundService() { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { val channel = NotificationChannel( “shutdown_monitor_channel”, “关机监听服务”, NotificationManager.IMPORTANCE_LOW ).apply { description = “用于监听设备关机重启事件” } (getSystemService(Context.NOTIFICATION_SERVICE) as NotificationManager) .createNotificationChannel(channel) val notification = Notification.Builder(this, “shutdown_monitor_channel”) .setContentTitle(“运行中”) .setContentText(“正在监听关机重启事件”) .setSmallIcon(R.drawable.ic_notification) .build() startForeground(1, notification) // 通知ID必须非零 } } override fun onBind(intent: Intent): IBinder? = null override fun onDestroy() { super.onDestroy() // 务必在服务销毁时解注册，防止内存泄漏 unregisterReceiver(shutdownReceiver) } }

2. 在AndroidManifest.xml中声明服务并请求前台服务权限：

   <uses-permission android:name="android.permission.FOREGROUND_SERVICE" /> <!-- Android 9+ 还需要注意电源白名单策略 --> <application ...> <service android:name=".ShutdownMonitorService" android:enabled="true" android:exported="false" /> <!-- 通常不需要导出 --> <!-- 保留静态接收器用于兼容旧版本 --> <receiver android:name=".ShutdownReceiver” ...> ... </receiver> </application>

3. 在应用启动时（如主Activity或Application类中）启动该服务：

   // 在MainActivity的onCreate或自定义Application的onCreate中 val intent = Intent(this, ShutdownMonitorService::class.java) if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { startForegroundService(intent) } else { startService(intent) }

此方案的挑战：

• 服务保活：即使用前台服务，在极端内存压力下或用户强制停止后，服务仍可能被杀死。一旦服务进程死亡，动态注册的接收器自然失效。
• 用户体验：前台服务会显示一个常驻通知，可能引起用户反感，用户可能会手动关闭通知或禁止应用后台运行。
• 厂商限制：不同手机厂商（小米、华为、OPPO、vivo等）有各自的后台启动管理和省电策略，可能会阻止你的服务长期存活。

3.3 方案三：双保险策略与厂商适配

在实际生产环境中，最稳健的做法是采用“静态注册兜底 + 动态注册增强 + 厂商白名单引导”的组合拳。

1. 兼容性判断与自动选择：在应用启动时，判断系统版本。

   fun setupShutdownMonitor(context: Context) { // 始终尝试启动动态监听服务（针对Android 8.0+） startShutdownMonitorService(context) // 对于Android 8.0以下的设备，静态接收器是主力。 // 对于Android 8.0+，静态接收器虽然系统限制不调用，但保留无妨。 // 动态服务是主要监听手段。 }

2. 处理onReceive中的紧急操作：无论通过哪种方式接收到广播，onReceive中的逻辑都必须遵循“快速、同步、持久化”的原则。一个常见的模式是：在onReceive中立即向一个IntentService或JobIntentService发送一个命令，将耗时的保存操作转移到另一个线程，但前提是这个Service必须能极大概率在进程被杀死前完成任务。更可靠的做法是在onReceive中直接进行同步的文件写入或数据库提交。

3. 应对厂商后台限制：

   • 引导用户添加电池白名单：在应用内检测到是特定厂商设备时，友好地提示用户去系统设置中，将你的应用加入“电池优化忽略名单”、“允许后台活动”等白名单。这能大幅提升服务存活率。
   • 使用厂商推送通道保活：一些厂商提供了自己的推送服务（如小米推送、华为推送），接入后可以利用其系统级通道来间接感知设备状态变化，但这并非直接监听关机广播。
   • 使用AlarmManager设置精确闹钟：结合RTC_WAKEUP类型的闹钟，可以定期唤醒应用，检查服务是否存活，若死亡则重新启动。但这需要SCHEDULE_EXACT_ALARM权限（Android 12+需要单独申请），且策略需谨慎设计，避免耗电。

4. 实操过程与核心代码实现

让我们整合一个完整的、考虑兼容性的实现示例。这个示例包含一个静态接收器（用于旧系统）、一个动态监听服务（用于新系统）、以及一个处理实际保存逻辑的IntentService。

4.1 核心组件定义

1. 静态广播接收器 (LegacyShutdownReceiver)：

// 主要用于 API 25 及以下 class LegacyShutdownReceiver : BroadcastReceiver() { override fun onReceive(context: Context, intent: Intent) { Log.i(“ShutdownMonitor”, “Legacy Receiver: ${intent.action}”) // 立即启动一个IntentService来处理保存，利用其独立工作线程 val serviceIntent = Intent(context, EmergencySaveService::class.java).apply { this.action = intent.action } context.startService(serviceIntent) // 关键：如果知道是关机重启，可以尝试发送一个有序广播， // 让高优先级的系统组件先处理，但这需要系统级权限，普通应用作用有限。 // abortBroadcast() // 普通应用通常无法中止系统有序广播 } }

2. 紧急保存服务 (EmergencySaveService)：

// 继承自IntentService，它在后台线程执行任务，执行完毕后自动停止。 class EmergencySaveService : IntentService(“EmergencySaveService”) { override fun onHandleIntent(intent: Intent?) { intent?.action?.let { action -> Log.w(“EmergencySaveService”, “紧急保存触发，动作: $action”) // 在这里执行实际的保存逻辑 saveCriticalData() // 例如：关闭数据库连接，提交所有Pending的事务 // 例如：将内存缓存写入文件 // 注意：所有操作必须是同步的、本地的。 } } private fun saveCriticalData() { // 示例：同步写入文件 try { val file = File(filesDir, “last_state.json”) file.writeText(“{\“shutdown_time\”: \”${System.currentTimeMillis()}\”}”) // 强制同步到磁盘 val fos = FileOutputStream(file) fos.fd.sync() fos.close() } catch (e: Exception) { Log.e(“EmergencySaveService”, “保存数据失败”, e) } } }

3. 动态监听前台服务 (ShutdownMonitorForegroundService)：

class ShutdownMonitorForegroundService : Service() { private var dynamicReceiver: BroadcastReceiver? = null override fun onCreate() { super.onCreate() Log.d(“ShutdownMonitor”, “前台监听服务启动”) startForegroundNotification() registerDynamicReceiver() // 可以在这里初始化一些需要长期持有的资源 } private fun startForegroundNotification() { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { val channel = NotificationChannel( “monitor_channel”, “系统事件监听”, NotificationManager.IMPORTANCE_LOW ).apply { lockscreenVisibility = Notification.VISIBILITY_SECRET } // 可设置锁屏不可见 getSystemService(NotificationManager::class.java).createNotificationChannel(channel) } val notification = NotificationCompat.Builder(this, “monitor_channel”) .setContentTitle(“系统服务运行中”) .setContentText(“正在监听关机等系统事件”) .setSmallIcon(R.drawable.ic_system_monitor) // 使用一个合适的、用户可接受的图标 .setPriority(NotificationCompat.PRIORITY_LOW) .setOngoing(true) .build() startForeground(NOTIFICATION_ID, notification) } private fun registerDynamicReceiver() { dynamicReceiver = object : BroadcastReceiver() { override fun onReceive(context: Context, intent: Intent) { Log.i(“ShutdownMonitor”, “Dynamic Receiver: ${intent.action}”) // 同样，启动IntentService处理 val saveIntent = Intent(context, EmergencySaveService::class.java).apply { this.action = intent.action } context.startService(saveIntent) } }.also { receiver -> val filter = IntentFilter().apply { addAction(Intent.ACTION_SHUTDOWN) addAction(Intent.ACTION_REBOOT) // 可以尝试监听其他相关广播，如屏幕关闭、电源连接等，作为辅助判断 addAction(Intent.ACTION_SCREEN_OFF) priority = 1000 // 设置高优先级 } registerReceiver(receiver, filter) } } override fun onStartCommand(intent: Intent?, flags: Int, startId: Int): Int { // 返回START_STICKY，服务被异常杀死后，系统会尝试重启服务（但不保证立即重启） return START_STICKY } override fun onDestroy() { dynamicReceiver?.let { unregisterReceiver(it) } Log.d(“ShutdownMonitor”, “前台监听服务停止”) super.onDestroy() } override fun onBind(intent: Intent): IBinder? = null companion object { private const val NOTIFICATION_ID = 1001 fun startService(context: Context) { val intent = Intent(context, ShutdownMonitorForegroundService::class.java) if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { context.startForegroundService(intent) } else { context.startService(intent) } } } }

4.2 清单文件配置

<?xml version=“1.0” encoding=“utf-8”?> <manifest xmlns:android=“http://schemas.android.com/apk/res/android”> <!-- 声明前台服务权限 (Android 9.0+) --> <uses-permission android:name=“android.permission.FOREGROUND_SERVICE” /> <!-- 声明关机权限（尽管普通应用无效，但保留以示用途，某些定制系统可能需要） --> <uses-permission android:name=“android.permission.SHUTDOWN” /> <application android:allowBackup=“true” android:icon=“@mipmap/ic_launcher” android:label=“@string/app_name” android:supportsRtl=“true”> <!-- 静态接收器，用于兼容旧版Android --> <receiver android:name=“.LegacyShutdownReceiver” android:enabled=“true” android:exported=“true”> <intent-filter android:priority=“1000”> <action android:name=“android.intent.action.ACTION_SHUTDOWN” /> <action android:name=“android.intent.action.ACTION_REBOOT” /> <!-- 某些设备或ROM可能使用其他Action，可按需添加 --> <!-- <action android:name=“android.intent.action.QUICKBOOT_POWEROFF” /> --> <!-- HTC等 --> </intent-filter> </receiver> <!-- 紧急保存服务 --> <service android:name=“.EmergencySaveService” android:exported=“false” /> <!-- 动态监听前台服务 --> <service android:name=“.ShutdownMonitorForegroundService” android:enabled=“true” android:exported=“false” android:stopWithTask=“false” /> <!-- 防止被任务管理器清理时连带停止 --> <activity android:name=“.MainActivity”> <intent-filter> <action android:name=“android.intent.action.MAIN” /> <category android:name=“android.intent.category.LAUNCHER” /> </intent-filter> </activity> </application> </manifest>

4.3 应用初始化与保活策略

在应用的入口点（例如主Activity或自定义Application类）启动监听服务，并实施简单的保活策略。

class MyApplication : Application() { override fun onCreate() { super.onCreate() initShutdownMonitor() setupKeepAlive() } private fun initShutdownMonitor() { // 无论版本，都尝试启动前台服务（动态监听） ShutdownMonitorForegroundService.startService(this) // 静态接收器已在清单中声明，系统会自动管理 Log.d(“MyApp”, “关机重启监听器初始化完成”) } private fun setupKeepAlive() { // 简单的保活：注册一个监听网络状态或时间变化的广播， // 当服务意外停止时，尝试重新启动（需谨慎使用，避免耗电） val keepAliveReceiver = object : BroadcastReceiver() { override fun onReceive(context: Context, intent: Intent) { // 检查前台服务是否在运行，如果不在则重新启动 if (!isServiceRunning(context, ShutdownMonitorForegroundService::class.java)) { Log.w(“MyApp”, “监听服务已停止，尝试重启”) ShutdownMonitorForegroundService.startService(context) } } } val filter = IntentFilter().apply { addAction(ConnectivityManager.CONNECTIVITY_ACTION) // 网络变化 addAction(Intent.ACTION_TIME_TICK) // 每分钟一次，慎用！ } registerReceiver(keepAliveReceiver, filter) // 注意：需要在合适的时机（如应用退出主界面时）解注册此接收器，避免内存泄漏。 // 更复杂的保活策略需结合JobScheduler或WorkManager进行定时检查。 } private fun isServiceRunning(context: Context, serviceClass: Class<*>): Boolean { val manager = context.getSystemService(Context.ACTIVITY_SERVICE) as ActivityManager @Suppress(“DEPRECATION”) return manager.getRunningServices(Integer.MAX_VALUE).any { it.service.className == serviceClass.name } } }

5. 常见问题、排查技巧与厂商适配实录

即使代码写得再完美，在实际设备上测试时，你仍可能遇到各种“玄学”问题。下面是我在实际项目中踩过的坑和总结的排查经验。

5.1 监听完全失效

• 症状：无论是静态还是动态接收器，都收不到关机/重启广播。
• 排查步骤：
  1. 检查系统版本：首先确认设备是否是Android 8.0+。如果是，静态注册失效是预期行为，必须依赖动态注册。
  2. 检查服务存活：对于动态注册，确保ShutdownMonitorForegroundService正在运行。可以通过adb shell dumpsys activity services | grep your.package.name命令查看。如果服务没起来，检查是否成功调用了startForegroundService并快速调用了startForeground。在Android 8.0+，startForegroundService后必须在数秒内调用startForeground，否则会引发ANR且服务被停止。
  3. 检查厂商后台限制：这是最大的“坑”。进入手机“设置”->“应用”->“你的应用”->“电池”或“权限”->“后台管理”。查看是否被限制了后台活动。小米的“神隐模式”、华为的“启动管理”、OPPO/vivo的“后台冻结”等都可能阻止你的服务长期运行。解决方案：在应用内添加检测逻辑，引导用户手动去设置页开启“允许后台运行”、“允许自启动”、“忽略电池优化”等选项。
  4. 检查广播Action：极少数设备或定制ROM可能使用了非标准的Action字符串。可以尝试在Logcat中过滤“android.intent.action”关键词，观察关机时系统到底发出了哪些广播。有时ACTION_SHUTDOWN可能被替换或额外发送了其他广播。
  5. 使用adb命令模拟广播：在设备开机状态下，通过adb发送广播来测试接收器是否正常工作。

     adb shell am broadcast -a android.intent.action.ACTION_SHUTDOWN

     注意：模拟的广播可能无法完全模拟真实关机流程，但可以验证接收器注册和基本逻辑是否正确。

5.2 监听不稳定，时好时坏

• 症状：有时能收到广播，有时收不到，尤其是在设备长时间休眠后。
• 可能原因与解决：
  • 进程被杀死：动态注册的接收器依附于进程。如果应用进程被系统或安全软件“清理”了，接收器自然失效。确保你的前台服务通知持续存在，并且引导用户将应用加入白名单。
  • 省电模式：系统全局的省电模式（如“低电量模式”、“超级省电模式”）会严格限制后台活动。在这种模式下，你的服务很可能被挂起或限制运行。需要在代码中检测省电模式，并提示用户功能可能受限。
  • 使用AlarmManager进行心跳保活：设置一个不频繁的、RTC_WAKEUP类型的Alarm（例如每30分钟一次），在闹钟接收器中检查服务状态并重启。但自Android 6.0的Doze模式和App Standby特性推出后，Alarm也会被推迟。Android 10+对setExactAndAllowWhileIdle也有频率限制。

5.3 收到广播但保存操作未完成

• 症状：日志显示onReceive被调用了，但数据没有成功保存。
• 关键原因：BroadcastReceiver的onReceive方法运行在主线程，且系统只给予很短的时间（通常10秒左右，但实际更短）。如果在其中执行耗时操作，系统可能会强制结束你的进程。
• 解决方案：
  • 绝对异步：使用goAsync()（API 11+）来获取更多处理时间，但依然要快。
  • 转移任务：最佳实践是在onReceive中立即启动一个IntentService或使用JobIntentService.enqueueWork()（兼容旧版）。IntentService会在独立工作线程处理任务，且会尽量完成onHandleIntent中的工作，即使应用进程随后被杀死。
  • 同步保存：对于最关键的数据，在onReceive中直接使用同步、阻塞的方式写入。例如，用SharedPreferences.Editor.commit()而不是apply；用FileOutputStream写入文件后调用FileDescriptor.sync()强制刷盘。

5.4 厂商特定问题与白名单引导代码示例

不同厂商的后台管理策略名称和入口不同。这里提供一个简单的工具类，用于检测并跳转到常见厂商的后台设置页（注意：这些URI可能随系统版本更新而失效，需要持续维护）。

object BatteryOptimizationUtil { fun isIgnoringBatteryOptimizations(context: Context): Boolean { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) { val powerManager = context.getSystemService(Context.POWER_SERVICE) as PowerManager return powerManager.isIgnoringBatteryOptimizations(context.packageName) } return true // 低于M版本无此限制 } fun requestIgnoreBatteryOptimizations(activity: Activity, requestCode: Int) { if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.M) { if (!isIgnoringBatteryOptimizations(activity)) { val intent = Intent(Settings.ACTION_REQUEST_IGNORE_BATTERY_OPTIMIZATIONS).apply { data = Uri.parse(“package:” + activity.packageName) } // 注意：频繁请求此权限可能导致应用被商店下架或用户反感。 // 仅在功能确实需要且解释清楚后使用。 activity.startActivityForResult(intent, requestCode) } } } fun goToManufacturerBackgroundSetting(activity: Activity) { val intent = Intent() intent.addFlags(Intent.FLAG_ACTIVITY_NEW_TASK) when { isXiaomi() -> { // 小米 intent.component = ComponentName(“com.miui.securitycenter”, “com.miui.permcenter.autostart.AutoStartManagementActivity”) } isHuawei() -> { // 华为 intent.component = ComponentName(“com.huawei.systemmanager”, “com.huawei.systemmanager.startupmgr.ui.StartupNormalAppListActivity”) } isOppo() -> { // OPPO intent.component = ComponentName(“com.coloros.safecenter”, “com.coloros.safecenter.permission.startup.StartupAppListActivity”) } isVivo() -> { // Vivo intent.component = ComponentName(“com.vivo.permissionmanager”, “com.vivo.permissionmanager.activity.BgStartUpManagerActivity”) } else -> { // 其他设备，跳转到系统应用信息页，用户手动寻找“电池”或“后台”选项 intent.action = Settings.ACTION_APPLICATION_DETAILS_SETTINGS intent.data = Uri.parse(“package:” + activity.packageName) } } try { activity.startActivity(intent) } catch (e: Exception) { // 组件可能不存在，跳转到通用设置页 intent.action = Settings.ACTION_APPLICATION_DETAILS_SETTINGS intent.data = Uri.parse(“package:” + activity.packageName) activity.startActivity(intent) } } // 简单的厂商判断（基于Build.MANUFACTURER或Build.BRAND） private fun isXiaomi(): Boolean = Build.MANUFACTURER.equals(“xiaomi”, ignoreCase = true) private fun isHuawei(): Boolean = Build.MANUFACTURER.equals(“huawei”, ignoreCase = true) private fun isOppo(): Boolean = Build.MANUFACTURER.equals(“oppo”, ignoreCase = true) || Build.BRAND.equals(“realme”, ignoreCase = true) // realme通常也适用OPPO设置 private fun isVivo(): Boolean = Build.MANUFACTURER.equals(“vivo”, ignoreCase = true) }

在你的应用设置页面或首次启动引导中，可以这样使用：

// 检查电池优化 if (!BatteryOptimizationUtil.isIgnoringBatteryOptimizations(this)) { // 显示一个解释性对话框，说明监听关机需要忽略电池优化，然后调用 // BatteryOptimizationUtil.requestIgnoreBatteryOptimizations(this, REQUEST_CODE_IGNORE_OPTIMIZATION) } // 引导用户去设置后台自启动/关联启动 showDialog(“为了确保关机时能保存数据，请允许应用在后台运行”) { BatteryOptimizationUtil.goToManufacturerBackgroundSetting(this@MainActivity) }

5.5 测试策略

测试关机重启监听非常麻烦，因为不可能频繁重启真机。可以采用以下策略：

1. 单元测试：测试BroadcastReceiver的onReceive逻辑和IntentService的保存逻辑。
2. 集成测试（ADB模拟）：使用adb shell am broadcast命令发送广播，验证接收和后续服务启动流程。
3. 真机有限测试：在少数几台关键测试设备（覆盖不同Android版本和厂商）上，进行实际关机重启测试。测试前，务必通过logcat或写入特定文件的方式记录关键日志，开机后检查日志或文件是否生成。
4. 模拟器测试：Android模拟器可以方便地重启，但要注意模拟器的系统行为可能与真机有差异，尤其是厂商定制部分。

监听Android关机重启广播是一个典型的“原理简单，实现坎坷”的需求。它要求开发者不仅理解广播机制，更要深刻认识Android系统在不同版本、不同厂商设备上的后台行为限制。最可靠的方案永远是：动态注册的前台服务 + 引导用户添加电池和后台白名单 + 在onReceive中极简且同步的持久化操作。同时，要做好功能降级的准备，因为在高限制环境下，无法保证100%的成功率。在实际项目中，我们往往需要将这种监听作为数据安全策略的一部分，而不是唯一依赖，结合定期自动保存等其他机制，共同保障数据的完整性。