Android应用被杀死时如何启动BroadcastReceiver及处理后台事件

针对你开发Target SDK 34（Android 14）应用时遇到的问题，结合系统限制给出具体解答：

1. 应用被杀死时能否启动BroadcastReceiver或其他组件？ #

• 注册在Manifest中的隐式BroadcastReceiver（比如监听CONNECTIVITY_ACTION）在应用被杀死后完全无法触发，Android 8.0（API 26）起就限制了大部分隐式广播的后台接收，Android 14进一步收紧了规则。
• 仅少数系统级隐式广播例外（如BOOT_COMPLETED），但需要申请RECEIVE_BOOT_COMPLETED权限，且应用必须被用户手动启动过一次才能生效。
• 显式广播可以触发组件，但前提是应用进程未被系统彻底清理，且需要通过PendingIntent等方式触发，无法实现无触发源的自动启动。
• 动态注册的BroadcastReceiver在应用被杀死后会随进程销毁，完全失效。

2. 应用终止后重连WebSocket的最佳实践 #

结合Android后台限制，推荐以下组合方案：

• WorkManager：使用OneTimeWorkRequest或PeriodicWorkRequest，配置NetworkType约束（如NetworkType.CONNECTED），当网络恢复时触发重连任务。WorkManager会自动适配系统调度规则，即使应用被杀死也能在满足条件时执行任务，且支持指数退避重试（避免频繁消耗资源）。
• FCM消息触发：当服务器需要客户端主动重连时，发送FCM Data消息（而非Notification消息），应用被杀死时仍能触发FirebaseMessagingService的onMessageReceived回调，在回调中执行WebSocket重连逻辑。
• Foreground Service（辅助方案）：若需要长期保持WebSocket连接，可使用Foreground Service并设置START_STICKY，但Android 12+需要申请POST_NOTIFICATIONS权限，且系统仍可能在资源紧张时杀死服务，需配合WorkManager或FCM实现重启逻辑。

3. 监听网络变化、接收FCM消息等事件的可行方案 #

• 网络变化监听：
  放弃CONNECTIVITY_ACTION广播，改用ConnectivityManager.NetworkCallback动态注册监听网络状态。若需应用被杀死后监听网络恢复，搭配WorkManager的NetworkType约束，当网络满足条件时触发对应任务。
• FCM消息接收：
  • Notification消息：应用被杀死时会由系统展示通知，用户点击后唤醒应用，可在启动逻辑中处理后续操作。
  • Data消息：无需用户点击，应用被杀死时会触发FirebaseMessagingService的onMessageReceived，可在此回调中执行重连、数据同步等后台任务（注意任务需轻量化，避免长时间阻塞）。
  • 高优先级FCM消息：可强制唤醒应用进程执行任务，但需合理使用，避免被系统判定为滥用。

4. 能否启动Activity、全屏通知等进行界面提示？ #

• 启动Activity：
  应用被杀死后，后台自动启动Activity在Android 10（API 29）起被严格限制，仅允许少数场景：用户点击系统通知的PendingIntent、应用处于前台任务栈时、或持有SYSTEM_ALERT_WINDOW权限（需用户手动授予，Android 14对该权限的使用场景进一步限制）。无交互触发的后台启动Activity会被系统直接拦截。
• 全屏通知：
  可使用高优先级通知并设置全屏PendingIntent，但Android 12+需要用户授予通知的“全屏提示”权限，且仅适合紧急场景（如来电、告警）。普通场景下，推荐使用常规通知引导用户点击打开应用，这是合规且用户友好的方式。

内容的提问来源于stack exchange，提问作者Yatin Batra