API29下应用被杀/未启动时FirebaseMessagingService的onMessageReceived不触发问题

问题一：应用处于非存活状态时是否完全无法接收FCM通知？ #

• 并非完全无法接收。FCM本身的设计逻辑就支持在应用非存活状态下送达通知：当请求体携带notification字段时，只要系统未切断FCM的系统级推送通道，FCM SDK会直接通过系统层拉起应用进程，自动完成通知展示，甚至不需要你的自定义MyFirebaseMessagingService处于运行状态。
• 你之前调整stopWithTask属性、拆分独立服务仍无法接收，核心原因通常不是代码逻辑问题，而是当前设备的定制ROM触发了后台限制：国内多数安卓系统会在应用被滑出最近任务后，切断未加入自启动白名单应用的推送长连接，直接拦截FCM的唤醒广播，这才是非存活状态收不到通知的主要诱因。
• 需要注意的是，如果将通知内容全部移到data字段、不携带notification块，FCM在应用非存活时不会主动拉起进程，这种场景下的送达率会进一步降低。

问题二：API29（Android 10）版本下，有什么合规合理的方案让应用在被滑动清除后台任务时稳定接收推送？ #

• 首先要明确：不存在可以完全阻止应用被系统杀死的合规技术方案。任何尝试通过双进程守护、隐藏前台服务等方式绕过后台限制的操作，要么会被应用商店判定为违规，要么会被系统直接强制清除进程，完全不符合开发最佳实践。所有合规方案的核心都是尽可能利用系统预留的推送通道豁免能力，降低后台被杀的概率。
• 第一步：修正当前Manifest中服务的冗余配置。你现在为MyFirebaseMessagingService添加的LAUNCHER、DEFAULT两个category标签没有实际作用，正常的MessagingService仅需要保留com.google.firebase.MESSAGING_EVENT的action配置即可，冗余的intent-filter配置不会提升唤醒优先级，反而可能被系统识别为异常服务。
• 第二步：合理利用FCM的系统级通道能力。API29对后台服务的限制规则中，特意为系统级推送服务预留了连接豁免权限——只要你发送的是携带标准notification字段的FCM消息，即使应用被用户从最近任务滑出，系统也会允许FCM保留长连接、完成通知唤醒，不需要你自行编写保活逻辑。
• 第三步：适配国产ROM的特殊限制。对于国内定制系统，唯一合规可行的提升送达率的方式，是在应用内通过引导页提示用户，将应用加入系统自启动白名单、关闭电池优化策略，不存在其他可以绕开系统限制的取巧方案。
• 注意：尝试通过常驻前台服务的方式保持应用运行，在API29上会被强制要求展示不可移除的常驻通知，会严重影响用户体验，不推荐采用。

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