IssueTracker

For the statement an app that mostly works in background does not mean its unimportant for the user, actually if it's important to the user, it should try to stay in the foreground, i.e., using a foreground service. We're squeezing the capability of running arbitrary amount of time for background apps. Look at the app restrictions since Android O, i.e., background services will be stopped by the system after 60s. So if an app is really offering critical functions to the user, it should try to stay in the foreground.

For the phantom processes, it's really a grey area, where the system does allow this kind of processes, but it's not formally supported, and it's not tracked by the system previously - it's going to hurt the overall system performance, as in resource-limited environment, other processes could be starving because of it. Thus we can't let the number of such kind of processes grow arbitrarily. The 32 may or may not be a good number, at least it's in par with the max cached processes, it's hard to justify what number is the perfect one though. I'd also be un-favor with the idea of introducing the per-package limit - from the system health point of view, it doesn't make sense to me.

For the battery optimizations disabled, this is orthogonal to the problem here I think. The battery optimization is more about the controls about background activities like Jobs/Alarms which could impact the battery negatively, while the problem here is more about other system resources such as CPU time and RAM.

For the cases like McAfee Security app, as you also show, the order of the killing is basically based on the parent process's oom adj score - if you app is killed before McAfee, that means it has a better oom adj score.

it should try to stay in the foreground, i.e., using a foreground service.

By background, I meant not visible like a social media app, and minimized to notifications. The TermuxService already is a foreground service and still its processes are getting killed. It normally has an oom adj of 200, while McAfee app also is a foreground service, but is usually at 100 oom adj, likely because of additional connections, and hence it survives, while Termux does not. Normally the heuristic of giving priority to McAfee would be fine-ish, but the heuristic is still just a guess at what is more important. What the OS's guess is of what's more important is not always what's more important for the user. An OS can't decide such a case. I ask a user, what he would rather have killed?, the Termux app that has important on-going work for him, which has session data that will be lost if its killed and can't be reproduced or like a backup operation going on that will have to restarted from scratch, costing with more CPU + battery + network bandwidth usage later, or would he rather have the McAfee app killed, that can just be restarted later and continue its monitoring again, without permanent data loss, since scans are reproducible. Even if loss was permanent for the later case, it may not be important to the user. I'm pretty sure the answer will be Termux for lot of users, if not most. I don't think one would hear many complaints of "Oh no, my antivirus got restarted and its scan data got lost!". Wouldn't it be better that the user gets to decide what the OS obviously can't decide. Moreover, as an app developer, the only choice would be to create useless connections to try to lower the oom odj to compete with MacAfee app, which would then waste OS resources and even that would be playing russian roulette.

The 32 may or may not be a good number, at least it's in par with the max cached processes, it's hard to justify what number is the perfect one though. I'd also be un-favor with the idea of introducing the per-package limit - from the system health point of view, it doesn't make sense to me.

How about, since 32 may not always be a good number, or will be different for each device or even each user, add a configurable option in android settings, or perhaps developer settings, like it is for cached processes, with a disable completely option as well for power users. Although, this doesn't solve the excessive usage killing issue.

it's going to hurt the overall system performance, as in resource-limited environment

I have a LG G5, with Snapdragon 820 and 4GB RAM + 2GB swap in /data partition, so its an old device but it runs apps relatively fine even today, with shell processes running through out the day. Some shell processes do take extra CPU and RAM usage, like daily compression+encryption backups, but those last a few minutes, and I as a user, I am completely fine with getting slow downs for a few minutes and don't want OS to kill such processes. I also have longer backups to the cloud, that run for over an hour during the night, with even more CPU usage, and they run without causing any user experience loss since I am not even using the phone and its on charging so battery is not an issue either. With the new design such things are not possible reliably. One would not want to wake up and find out that the OS decided to randomly kill their backup process during the night to save resources. I also use Activity State Changes Tasker Project that monitors every activity transition I do (in user space, not OS), and which happen quite often. Transitions are being monitored by multiple logcat processes and each transition runs dumpsys command as well to check fullscreen mode. I have never noticed any noticeable lag because of all that, in fact I have to put delays of like 1-2s because the tasks are much faster than required. The Tasker app barely even shows in battery usages in android settings. Other users on r/tasker have hundreds of event based tasks running all the time without any noticeable performance loss or battery usage.

So the argument that phantom processes will harm user experience is not always true. The r/tasker and r/termux users have actively been using such processes without issue for years. Moreover, every user may not even want an even faster OS/device, but a reliable one that is actually useful for his daily work, instead of just being faster. Devices are fast enough today, with batteries large enough too.

I am also not sure how many android OS devs experiment with such stuff in their daily life, who can provide more usable stats on this, even I don't get much time now. Do you guys have any such stats collected from such devs or done as part of development itself, like how killing normal phantom processes (not rogue) of apps like Termux and Tasker actually noticeably improved user experience and system performance for other apps. Those would be interesting to look at.

Yes, I completely agree that phantom processes can decrease system performance in some cases, specially like the case above with McAfee, but the user should get to decide if he is fine with a certain app causing a performance loss, hence the request for an exemption. Moreover, the current design in fact trimmed rogue logcat processes from 100+ to 32, but it also killed the bash process that wasn't even using much CPU and was useful to the user and the design prevented termux from actually running anything, so from a user perspective, the collateral damage is too high.

The battery optimization is more about the controls about background activities like Jobs/Alarms which could impact the battery negatively, while the problem here is more about other system resources such as CPU time and RAM.

Okay, fair enough. But from a user point of view, more CPU usage would be proportional to battery usage and it would have been easier to use the same permission. But if you want to introduce another permission "Disable resource optimizations", that would be acceptable too. Moreover, the apps that already had battery optimization disabled would automatically also get to use CPU unconditionally and bypass phantom process restriction if same permission was used, so that is probably not something one may want and a separate permission is likely more ideal.

The permission check could be added to ActivityManagerService.checkExcessivePowerUsage() before monitoring CPU usage and before bookeeping a phantom process in PhantomProcessList.getOrCreatePhantomProcessIfNeededLocked(). It would be really great if such an exemption was added for specific apps. The power users would be really grateful that they get to live another day and enjoy their device like they want to.

In terms of the oom adj score McAfee vs. Termux, I guess McAfee has a binding from a higher priority processes, such as the system. As you know, the Android OS doesn't have the intelligence to determine which one is important to the user - it has no idea what this app is for, an user could say the Termux is more important to them, while the other user could say McAfee is more important. It's not scalable for the Android OS to ask user in terms of the importance for every single app. Remember, user perception/interaction is a resource too.

The number 32 is AOSP definition, OEMs could alter this number if they like, there is no any hard requirement on this. I'd say we could explore the option to add a configuration in the developer options for it. But again, this kind of thing is never formally supported as an Android feature, I'm not sure if this Settings makes sense in this context.

However I'd disagree to associate it with the battery optimization settings, as aforementioned, they're orthogonal problems. Actually for most of the users, they don't have an idea about what the turning off battery optimization would actually mean to them. Apps without battery restrictions, don't mean they could do whatever they want. All of the Android OS users, should be protected from buggy or malicious apps - we do have seen buggy apps with native executables eating up the system resources. I'd also disagree with the statement Devices are fast enough today, with batteries large enough too, it's never our goal of stopping making faster device and longer battery life.