Donate to e Foundation | Murena handsets with /e/OS | Own a part of Murena! Learn more

Skip to content
Commit bdf5164a authored by Adam Bookatz's avatar Adam Bookatz
Browse files

Delayed locking is only for mDelayUserDataLocking

There are now two types of delayed locking scenarios:
* a device is configured so that all users have this property
* a particular user type has this property, but not all users

The former is governed by mDelayUserDataLocking, and has the additional
property that background users are generally not allowed; they are
stopped immediately upon user switch.

The question is: when should such users be locked?
Currently, this happens when the number of such unlocked users reaches a
maximum value which is (inappropriately) coupled to mMaxRunningUsers.
This feature was purposefully chosen for mDelayUserDataLocking. However,
it doesn't necessarily make sense for other scenarios, so we make it
specific to the mDelayUserDataLocking scenario.

Note: This means that "delayed locking" really means "left unlocked". It
isn't necessarily true that the user will ever be locked. On the other
hand, that was also the case before, since if max wasn't exceeded, the
user wasn't locked.

Test: atest UserControllerTest
Change-Id: Iffc9a35415e9616ea53c0adce0ec352297c71e70
parent e27fe837
Loading
Loading
Loading
Loading
0% Loading or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment