This doesn't fix the problem; I think it is an app problem. It does
improve a bunch of the debugging to help better identify what is going
on, and introduces some checks when adding a fragment to fail
immediately if we are getting into a state when a fragment is going to
be in the added list multiple times (which is pretty much guaranteed
to lead to a failure at some point in the future).
Change-Id: If3a8700763facd61c4505c6ff872ae66875afc8d
Clearly isolated the DreamManagerService and DreamController
responsibilities. DreamManagerService contains just enough logic to
manage the global synchronous behaviors. All of the asynchronous
behaviors are in DreamController.
Added a new PowerManager function called nap() to request the device
to start napping. If it is a good time to nap, then the
PowerManagerService will call startDream() on the DreamManagerService
to start dreaming.
Fixed a possible multi-user issue by explicitly tracking for
which user a dream service is being started and stopping dreams
when the current user changes. The user id is also passed to
bindService() to ensure that the dream has the right environment.
Fix interactions with docks and the UI mode manager. It is
important that we always send the ACTION_DOCK_EVENT broadcast
to the system so that it can configure audio routing and the like.
When docked, the UI mode manager starts a dock app if there is
one, otherwise it starts a dream.
This change resolves issues with dreams started for reasons other
than a user activity timeout.
Bug: 7204211
Change-Id: I3193cc8190982c0836319176fa2e9c4dcad9c01f
When computing the adjusted view bounds, don't constrain the
dimensions by the original estimate. This can result in the view never
getting properly enlarged.
Bug 7240251
Change-Id: I44fc017f8b661121f0042fcd59a4efde70be6bbe
Bug: 7197445
The listener on AccountManager is not sufficient since it only triggers when
primary user's accounts change.
Switch to watching for LOGIN_ACCOUNTS_CHANGED_ACTION for all users.
Change-Id: I63f526aebd70f0ad777490f3e0b6e6894220d26c
...Forground Sometimes Doesn't Take
The main change here is a one-liner in ActiveServices to check the
uid when deciding whether to remove an item from mPendingServices.
This could cause the problem being seen -- if the same service for
two users is starting at the same time, the second one would blow
away the pending start of the first one. Unfortunately I have had
trouble reproducing the bug, so I don't know if this is actually
fixing it. It's a bug, anyway.
The reason so much has changed here is because I spread around
logging and printing of the user ID associated with operations and
objects to make it easier to debug these kind of multi-user things.
Also includes some tweaks to the oom manager to allow more background
processes (I have seen many times in logs where we thrash through
processes because the LRU list is too short), plus to compensate an
additional time-based metric for when to get rid of background processes,
plus some new logic to try to help things like Chrome keep around
their service processes.
Change-Id: Icda77fb2a1dd349969e3ff2c8fff0f19b40b31d3
