Properly handle stopping related users
Fixes UserController's mechanism for stopping users along with their
other profile group members, and improves what happens when exceeding
the maximum number of running users.
* The UsersLru will now always list profiles *before* their parent
* This makes sense since parents must be "used" for the profile to run
* This ensures that if we exceed maxRunningUsers, we'll stop profiles
before their parents (i.e. priotize keeping full users alive)
* This ensures that if we exceed maxRunningUsers, we'll count the
number of users we plan on stopping correctly (i.e. no overkill)
* stopUsersLU, which stops a user as well as its "related users",
formerly stopped a parent when called on its profile. This didn't make
sense since stopping a profile shouldn't stop its parent. We change it
to only stop a parent's profiles, not a profile's parent.
This fixes the following bugs:
* when exceeding maxRunningUsers, a user with profiles was much more
likely to be killed, even if it was the main user
* the stopProfile API would attempt to kill its parent too (!)
* applying quiet mode to a profile of a background user would attempt
to kill that background parent user too
* Adds more documentation explaining a bunch of this
Issues NOT tackled in this cl are:
* The system user's profiles are still not stopped when maxRunningUsers
is exceeded
* When exceeding maxRunningUsers, we still don't prioritize keeping
difficult-to-restart profiles (with separate challenges) alive
* The entire notion of "force==true" is left alone, even though it
doesn't make much sense
Test: atest UserControllerTest#testRunningUsersListOrder_parentAfterProfile,testRunningUsersListOrder_currentAtEnd,testStopProfile_doesNotStopItsParent
Test: atest UserControllerTest
Bug: 324647580
Bug: 310249114
Change-Id: Ie08342bb77544117cab4423b543af74cbeb109e2
2 files changed