Try to suspend the process--墓碑模式探索 #455
Comments
|
目前已知问题: 也许要写Xposed模块hook相关操作才能搞定上面的问题，但要处理后台自启，广播，wakelock，alarm，想想就麻烦，期待作者出暴力压制模式。目前thanox的权限管理够好用了，要是能压制后台，原生系统就更省电了。 |
|
都是人才啊，我会抽时间学习研究一下。 |
|
我编辑了一下这个issue，调整了一下代码格式化。 |
|
最近我恰好在探索相关内容，但无奈自己没有安卓开发的能力，目前仅能做到脚本级别的冰冻后台（效率极度低下，基本就是暴力轮询）。Thanox在安卓平台层面应该能更好地处理相关功能实现。 @countrysideboy 你应该用到了cgroupv2的freezer功能，这个功能要求内核版本大于5.4、或者OEM将相关功能移植回低版本内核。而如果你的内核本来就支持了cgroupv2的freezer，那么你可以前往开发者选项 -> 对缓存应用暂停执行(Suspend execution for cached apps) 相关功能分析： https://juejin.cn/post/7078957393446453285
@Tornaco cgroupv2 freezer有较高的内核版本要求，请考虑一下如果cgroupv2 freezer不可用的时候fallback回cgroupv1 freezer（支持这个的设备应该更加广泛） freezer冻结和解冻请以整个应用为单位来进行，不然可能发生异常，比如应用的其它进程的异常捕捉认为应用未响应了于是尝试重启应用（脚本里的逐个pid冰冻是有问题的）。更好的做法是创建一个新的cgroup，并以应用包(或uid)为单位划分，冻结时将整个节点冻结而不是单独一个一个pid来。 最后，如果有其它通讯平台的联系方式可能会更方便些。 |
|
看来研究得很深入啊。一开始我是直接冻结整个uid 而非pid，但是发现应用异常退出后，无论是否解冻，app都无法再打开，很奇怪，才转而冻结pid |
|
至于kill -19的方式，可能比较通用，但会anr，我试过去hook相关函数但没有成功。 另外就算能冻结成功，唤醒锁，闹钟，广播需要解决，不然还是会被关联唤醒。 |
|
通过Hook安卓系统屏蔽ANR |
|
This comment was marked as outdated.
This comment was marked as outdated.
|
OP_WAKE_LOCK应该是没用的 |
初步测试了一下，不使用NoANR模块好像可以，thanox作者似乎有处理这个问题。 |
|
有看过/data/anr的日志吗 |
|
也不知道Thanox怎么阻止的广播，我的NoANR是在分到APP之前去掉了广播，但是已经在执行的广播没去干扰，看这个情景模式也是延迟了15s，前台广播超时好像是10s，这样应该不存在后台后还有广播在执行了 |
昨天我把文件清空了，要测久一点才能确认了 |
|
冻结APP之后，直接锁屏，触发息屏广播，过个几秒，看看/data/anr有没有日志，如果有就是广播阻止的不彻底，如果没有，广播就成功阻止了，然后还有服务的ANR，就是挂后台，挂久一点，如果没有出现，那就没啥问题了，提供者的ANR我没看过了，NoANR去掉广播之后，屏蔽NoANR就没有任何问题了，所以我就没继续研究了 |
|
用Thanox的阻止广播还有服务和提供者，会导致比如美团支付使用支付宝，而支付宝以及被阻止了，就会显示找不到支付宝 |
是吧，我试了下闲鱼跳转淘宝授权登录，好像也不行 |
测试了几下，暂时没发现有文件。 |
|
还有就是，感觉15s延迟是不是太久了，进入后台那一会是最活跃的，如果改成3s还能不能正常，会不会就触发ANR了 |
我试试。等待时间久些，是希望程序能进缓存。之前测试，短时间内发送make-uid-idle没有效果，要有那么一段时间后执行才有效 |
发现如果直接把全局变量的软件取消后会出现奇怪的问题 比如qq和微信是连不上网 接不到新消息，停止应用和重新开机都不行恢复，只有停止冻结的那个情景模式，而且解冻的那个情景模式得开启，再打开一次软件才恢复正常，如果有人看到这个问题，请使用这个方法恢复app。 |
|
这个问题就是阻止广播还有服务以及提供者导致的，你可以关闭冻结脚本，开一遍被冻结过的脚本，然后移除冻结名单 |
This comment was marked as outdated.
This comment was marked as outdated.
这个阻止广播还有服务以及提供者还会因为开关vpn之后网络异常, 副作用挺大的 , 比如软件开着vpn 回到桌面, 关闭vpn,15s后再打开软件,软件依旧无法上网,需要重新打开vpn之后才能正常连接网络 |
This comment was marked as outdated.
This comment was marked as outdated.
|
现在thanox能实现识别显示在应用上层的服务和前台服务以防止这些应用被墓碑吗 |
不清楚，暂时没找到方法 |
This comment was marked as outdated.
This comment was marked as outdated.
请不要把国内中文社区的抬杠文化搬到github。我一直都是在给出信息，尝试在帮助大家。
当我们通过各种方式，包括但不限于：thanox乖巧模式、冻结应用、绿色守护、thanox情景模式脚本等方式，减少、降低乃至停止了应用在后台的服务和唤醒，那么应用在后台就没有计算，没有cpu使用，也不会有网络开销。 其次，手机的基带耗电这件事，从10年前就有这方面的新闻和研究。具体的来讲，1.用户手机终端与信号塔基站越远、信号越弱，耗电越高。2.普遍的来讲，2G<3G<4G<5G。3.不同的信号频段的连接耗电也不同。4.不同的运营商的在手机和信号基站两边的配置、优化也影响耗电。5.不同的soc芯片，基带耗电也不同·。只能说，如果想要基带省电，可以根据自己的情况，自己调整设置3G/4G/5G。我前面最开始说的就是这个意思，限于手机回复，没说得很详细。根据我实际测试和网上的网友反馈，在信号强度都相对较好的情况下，5G换到4G、4G换到3G都是能有明显省电的。不推荐2G第一是因为2G下的SMS有安全缺陷，会被攻击，第二是因为现在2G几乎没有了。我之前没有说得很详细，还有一个原因是5G和4G分别有对应的VoNR和VoLTE，如果5G换到4G，或5G/4G换到3G，就会丢失这个功能，那就需要用户自己考虑自己的需求自己判断如何使用。 第三，一般手机休眠状态下，经过手机系统和用户手动设置的对于流氓软件的压制，后台的网络流量不会太多：一般都是微信这样的保持长连接，时不时发送几个小packet。这种情况下的应用网络流量，即便走的手机信号基带，也不会明显增大基带耗电。在这种情况下，主要的基带耗电在于维持手机信号，少许的网络流量的增加耗电与之相比可以忽略不计。如果是像手机网游那样一直传输数据，或者有应用在后台不断上传下载文件/数据，那么才会明显增大耗电。因此，你的情况不代表别人的情况。 第四，大部分人的使用场景是平时户外用流量，室内连wifi。而手机休眠大部分情况是室内。所以wifi下无需考虑应用后台流量走基带耗电。另一方面，既然在这个issue讨论，那么大家都是尽量限制应用的后台活动。你把活动限制住了，也就没有网络资源消耗了，也就没有基带耗电了。根据你的反馈，很有可能你手机上的应用在后台的活动比较多，网络资源使用比较多，超出了正常合理的（此处合理以google的推荐标准为准）活动量和网络使用量。那么正当的应对策略应该是限制这些应用的后台活动：把不必要的活动限制掉了，自然也就没有那么多网络使用，剩下的那一点push notification的流量还不至于有明显耗电。 最后，有什么想法，建议首先google搜索一下，自己研究一下。不要上来就开喷。github是用来分享知识合作建设的，不是用来抬杠的。然后，回复你最初的思路：“让APP认为系统无网络”没有实际操作价值。 |
您可真行，您自己正在干的事不让别人干？
凡事想当然然后反咬对方应该多Google多研究？ 您上面这堆废话大部分与我的论点毫无关系，例如您反复扯3g/4g/5g网络切换这跟我的观点有任何关系吗？您是不是认为字多就能占理？ 您的讨论于我、于其他用户有价值，我不至于屡次三番劝您认真看完再回我，我是最后一次请您不要再回复一些和我的观点毫无关系的内容了，也请您不要反咬。您第一次回我时的内容就非常莫名其妙，后面更是变本加厉，要说喷也是您在喷我。 |
他的意思应该是APP后台联网的确会导致耗电，但是在正常合理的情况下APP的这一部分耗电不管走WIFI还是走流量都没有区别。 关于拔sim卡的问题，他也解释了：拔sim卡的确能省电，但这不是因为APP的网络请求走WIFI导致省电或者说APP的网络请求减少导致省电，而主要是因为手机不插sim卡无需连接电信信号减少了功耗（我并未实际测试，不确定这个说法的正确性） 最后，就我个人而言，您二位说的都很有道理。 最后的最后，感觉您二位压根没在一个频道上😂，大家应该都多点耐心才是。 |
大家都在讨论。我给出的内容都是informative，没有人在喷你。 |
|
@simplerick-simplefun @Gokou-Ruri 两位都是高手，我觉得说的都有道理。抛去基带待机耗电及流量耗电，我有点怀疑，是不是一些流氓SDK（那些分析引擎），检测到手机有sim卡，认为这手机更有价值就更活跃地在获取信息？未来想折腾一个方向，就是伪装（非全局，只针对应用）电量不足、无sim卡无服务、内存不足，以此验证猜想。 |
This comment was marked as duplicate.
This comment was marked as duplicate.
|
使用最新版本的在线情景模式规则noactive，出现报错，看起来好像是break不支持解析，大佬帮忙看下是啥问题 |
|
@rc2md3 这是正常的，break是想跳出情景模式，但是实际上不支持，不过报错也可以中断执行 |
原来是这样跳出的，谢谢 |
|
用的最新的情景模式, 大概率发现twitter一有新消息弹窗就会卡死. 启动后提示新消息弹窗的状态(这时卡死) 正常状态 |
试一下这个思路： |
|
@uniking @simplerick-simplefun 再加一个情景模式感知fcm推送？我想下怎么处理好一些 |
其实从现实的角度考虑，没有必要在手机解锁的情况下对一些app进行冻结。尤其是有及时消息功能的应用。 所以设置成自动冻结，然后加一个情景模式，手机解锁后自动把自定义列表中的app拉起解冻就好了。 微信是一个特例，即便手机解锁微信在后台仍然消耗会大一些，因为腾讯用微信去给别的app推送消息，而且那些群、公众号等等即便设置成消息免打扰，微信也会实时拉取新消息。但是存在锁屏后微信语音视频通话的场景。我目前没有想出可以在锁屏后微信语音视频通话完结后自动冻结微信的办法。可能视频可以检测前端应用，但是黑屏下的语音通话怎么解决？ |
|
就刚开始使用情景时卡过两次, 到现在也没出现过, 可能概率很低, 可以不用管了. 效果很好, 给好评. 我微信主要后台接语音, 不能墓碑. 想熄屏语音后再墓碑的, 是不是可以看语音activity组件退出后在墓碑? |
|
可不可以给微信等聊天软件弄个专用情景, 学习android的doze, 后台后每隔墓碑2分钟, 给20秒出墓碑的时间.这样聊天不会漏, 语音视频最多延迟2分钟,拨过去就好了. |
|
反馈个问题, 腾讯新闻主进程压不住, 其他进程已经stop了. OnePlus7Pro:/ # ps -A |grep new |
请问安卓版本是？用的是顶楼最新合并版的脚本吗？另外是否有等待45秒？晚点我也去装个客户端试试 |
android 11, lineageOS18.1, 用的最新的那个, 等了4,5秒, 腾讯新闻的其他进程已经停止了. app从应用宝下的. |
|
@uniking 试下在线规则里最新的单合并脚本？我在安卓13下测试了，主进程可以压住，某安下的程序。等待四十五秒后，看下是始终压不住，还是一开始可以后面又不行了？ |
我shell下敲kill命令, 信号20对主进程不管用, 信号19可以让主进程stop, 我系统的事? |
OnePlus7Pro:/ # ps -A |grep news |
其他应用没这个问题, 唯一的解释可能是腾讯新闻捕获了SIGTSTP但没有停止, SIGSTOP强行让它停止了. |
这可能是个兼容问题, 我自己改成了su.exe("kill -s 19 " + proc.pid);, 已经压住了. |
|
@uniking 了解一下，是否使用了最新的脚本？是使用全局变量（pause）的添加app列表的方式，还是在app详情里面加入电量限制？ |
20220728更新的脚本, 两处添加程序的地方都添加了. 问题不是这个, 而是SIGTSTP在我手机上对腾讯新闻主进程无效, 改成SIGSTOP就可以了. |
有空试下把sendSignal(proc.pid,20)这一句，改成sendSignal(proc.pid,19)，看看是否可行？ |
不行, 直接改成19所有应用都停止不了了, 应该是没权限执行SIGSTOP, 所以我使用了su. |
|
@uniking 好的，后续我尝试在脚本最前面弄个变量来选择用api还是su.exe方式。 |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
如题，觉得目前的乖巧模式的不太压得住流氓们，app切换到后台后仍然占用cpu，于是探索使用冻结进程的方式，看作者大神后续能否增强(需要那种前台能用，后台压得死死的，切换回前台又恢复之前的会话)
在全局变量中添加 pause，把要压制的app添加进去；或者在目标应用详情，将电池设置为受限(为了检验效果，脚本与乖巧模式互斥，会自动关闭乖巧)
20220729更新：
1.修复未添加全局变量pause时脚本出错的bug;
2.添加参数自定义调整功能，其中DELAY = 45000，对应实现应用切回后台进入墓碑的等待时长（毫秒）；修改为SU_EXE = 1，则使用kill -19命令来压制进程，需打开su插件支持（默认SU_EXE = 0，使用系统api进行压制，无需su插件）。
情景模式脚本
[ { "name": "ForceIdle: auto pause or continue App", "description": "通过全局变量[pause]添加应用列表，或设置电池用量为受限，对回到后台的应用强制压制(墓碑)。\nForce pause the app while it switchs to backgroud, you need to pick app list in the global val name [pause].", "priority": 1, "condition": "frontPkgChanged == true", "actions": [ "if(thanos.getActivityManager().isBlockAllService(to)){thanos.getActivityManager().setBlockAllService(to,false)};", "if(thanos.getActivityManager().isBlockAllReceiver(to)){thanos.getActivityManager().setBlockAllReceiver(to,false)};", "if(thanos.getActivityManager().isBlockAllProvider(to)){thanos.getActivityManager().setBlockAllProvider(to,false)};", "if(context.getSystemService(context.APP_OPS_SERVICE).unsafeCheckOp(android.app.AppOpsManager.OPSTR_RUN_ANY_IN_BACKGROUND, thanos.getPkgManager().getUidForPkgName(to), to) == android.app.AppOpsManager.MODE_IGNORED || (thanos.getProfileManager().isGlobalRuleVarByNameExists(\"pause\") && globalVarOf$pause.contains(to))){foreach(proc:context.getSystemService(context.ACTIVITY_SERVICE).getRunningAppProcesses()){if(proc.processName.contains(to)){android.os.Process.sendSignal(proc.pid,18);}}; context.getSystemService(context.APP_OPS_SERVICE).setMode(android.app.AppOpsManager.OP_WAKE_LOCK, thanos.getPkgManager().getUidForPkgName(to), to, android.app.AppOpsManager.MODE_DEFAULT); context.getSystemService(context.USAGE_STATS_SERVICE).setAppStandbyBucket(to,android.app.usage.UsageStatsManager.STANDBY_BUCKET_RARE); if(thanos.getActivityManager().isPkgSmartStandByEnabled(to)){thanos.getActivityManager().setPkgSmartStandByEnabled(to,false)}; if(thanos.getActivityManager().isPkgBgRestricted(to)){thanos.getActivityManager().setPkgBgRestrictEnabled(to,false)}};", "DELAY = 45000; if(context.getSystemService(context.APP_OPS_SERVICE).unsafeCheckOp(android.app.AppOpsManager.OPSTR_RUN_ANY_IN_BACKGROUND, thanos.getPkgManager().getUidForPkgName(from), from) == android.app.AppOpsManager.MODE_IGNORED || (thanos.getProfileManager().isGlobalRuleVarByNameExists(\"pause\") && globalVarOf$pause.contains(from))){context.getSystemService(context.APP_OPS_SERVICE).setMode(android.app.AppOpsManager.OP_WAKE_LOCK, thanos.getPkgManager().getUidForPkgName(from), from, android.app.AppOpsManager.MODE_IGNORED); thanos.getActivityManager().setBlockAllService(from,true); thanos.getActivityManager().setBlockAllReceiver(from,true); thanos.getActivityManager().setBlockAllProvider(from,true); actor.delayed(DELAY,\"if(activity.getFrontAppPackage()!=from){if(thanos.getActivityManager().isPackageIdle(from)==false){context.getSystemService(context.ACTIVITY_SERVICE).getService().makePackageIdle(from,android.os.UserHandle.USER_ALL)}; if(activity.isInactive(from)==false){activity.setInactive(from)}; context.getSystemService(context.USAGE_STATS_SERVICE).setAppStandbyBucket(from,android.app.usage.UsageStatsManager.STANDBY_BUCKET_RESTRICTED); SU_EXE = 0; foreach(proc:context.getSystemService(context.ACTIVITY_SERVICE).getRunningAppProcesses()){if(proc.processName.contains(from)){if(SU_EXE == 1){su.exe(\\\"kill -19 \\\" + proc.pid);};if(SU_EXE != 1){android.os.Process.sendSignal(proc.pid,20);};}}}\")};" ] } ]The text was updated successfully, but these errors were encountered: