fcmfix
fcmfix copied to clipboard
HyperOS下,应用在后台一段时间后就无法接收通知了
先说现象:已停止的应用可以被fcmfix唤醒并接收通知,但是唤醒之后如果在后台经过一段时间,APP便无法收到通知了,但是APP的状态还是为正在运行(通过FCM Diagnostics可以看出fcm这边还是收到了通知,但是提示No response to broadcast from xxxx
)。如果我手动把APP结束运行,那么下次来通知的时候APP又能被fcmfix唤醒并接收通知了。
推测是HyperOS millet墓碑机制改动,APP在后台一段时间后,状态虽然为正在运行,但实际上已经被墓碑了,没有后台活动了,通知也接收不到,目前只能通过将省电策略从智能限制改为无限制才能解决被墓碑的问题。但是别的模块例如MIUIGMS的做法又太暴力,MIUIGMS的做法是为所有勾选的应用保留后台,相当于这些应用一旦被唤醒就始终保持在后台运行,这样会带来极高的耗电。
如果目前的fcmfix能做到唤醒的时候将APP从墓碑中拉出来(例如模拟在前台打开此APP),这样应该可以正常接收通知了。
墓碑的有可能,反馈的截图确实好多都是no response的(和没有自启动权限的表现一致),现在fcmfix没有对墓碑机制做处理。
已停止的应用可以被fcmfix唤醒并接收通知
顺便问一下这个已停止的应用可以被唤醒是有没有给自启动权限的?
和没有自启动权限的表现一致
实际上是因为APP的状态已经为正在运行(只是疑似被墓碑),所以没办法被重复拉起吧
顺便问一下这个已停止的应用可以被唤醒是有没有给自启动权限的?
不需要给自启动权限就可以被唤醒,但想不被墓碑就得把APP的省电策略从智能限制改成无限制。 但完全不被墓碑的话,耗电又很高,所以要是有办法从被墓碑的状态拉起就好了。
主要是想确认下现在的自启动绕过有没有作用。 确认是墓碑机制的问题的话就可以单独做额外的绕过hook就好了。
主要是想确认下现在的自启动绕过有没有作用。 确认是墓碑机制的问题的话就可以单独做额外的绕过hook就好了。
说起来仓库那个PR,我提取了一部分代码合并后我这边能正常唤起各种fcm消息,目前用主仓库的ci版本拉不起来……
主要是想确认下现在的自启动绕过有没有作用。 确认是墓碑机制的问题的话就可以单独做额外的绕过hook就好了。
说起来仓库那个PR,我提取了一部分代码合并后我这边能正常唤起各种fcm消息,目前用主仓库的ci版本拉不起来……
那个感觉是哪里拷过来,看起来是把所有应用的省电限制都放开了,我得改一下再合
主要是想确认下现在的自启动绕过有没有作用。
这个是有的
@kooritea 加油啊,大佬
似乎只要卡片还在后台,等一段时间就会进墓碑,然后就拉不起来了
似乎只要卡片还在后台,等一段时间就会进墓碑,然后就拉不起来了
原来这么早就有问题了吗,请问你们临时解决的办法吗,我也是刚刚才升级澎湃,好难受啊
停止的应用能fcmfix拉起通知,被millet墓碑冻结的通知不了,MIUI14可以。肯定澎湃改动了墓碑,作者还没有完全适配。你有临时解决办法吗
停止的应用能fcmfix拉起通知,被millet墓碑冻结的通知不了,MIUI14可以。肯定澎湃改动了墓碑,作者还没有完全适配。你有临时解决办法吗
我目前是通过thanox的情景模式来临时解冻应用。但是用这个软件不知道会不会增加耗电。
尝试用最新的发布
尝试最新的发布
更新了吗?感谢!辛苦了!!