Moved several USER_STOPPING registered receivers to listen
to USER_STOPPED, since they don't need to be blocking the
shutdown of the user.
Clear all stale broadcasts when stopping a user, so that we
don't unnecessarily start up processes and deliver stale
broadcasts. This was causing code to run when the user was
already stopped and resulted in crashes when other providers
and services couldn't be started anymore. Hopefully this fixes
many of those races.
Bug: 28371487
Change-Id: Ic35a7a23fa8fe009a53f8bf7545d4dad5fa34134
There is a narrow window of time during user unlock where we're
reconciling user storage and dispatching the "unlock" status to
various internal system services. While in this "unlocking" state,
apps need to be told that the user still isn't actually "unlocked"
so they don't try making calls to AccountManager, etc.
The majority of internal services are interested in merging together
both the "unlocking" and "unlocked" state, so update them.
Clarify naming in AccountManagerService to make it clear that a local
list is being used, which mirrors the naming in MountService.
To match UX/PM requested behavior, move PRE_BOOT_COMPLETED dispatch
after the user is unlocked, but block BOOT_COMPLETED dispatch until
after all PRE_BOOT receivers are finished to avoid ANRs.
Bug: 28040947, 28164677
Change-Id: I57af2351633d9159f4483f19657ce0b62118d1ce
"tm_mon" format should align with "ZipEntry::setModWhen" in aapt.
"tm_isdst" should be initialized, or it will because random value
and cause error in function mktime().
BUG:28021145
(cherry picked from commit bb0eb3f4cb33c077b296a18555a9a1a966ff696b)
Change-Id: Ia39cf63fcd4bb39c24af080562960279106f526c
Pinned stack doesn't have focus, so there's no need for setting extra
elevation to show shadow for focused case.
This removes extra eleavtion for pinned stack, and improves the PIP
animation quality by preventing extra surface size change
at the end of animation.
Bug: 27364161
Change-Id: Id099a78de48b2e038a69600c94454b5cbfe0628f
Because we move the task to the front in startRecentsActivity, we
always overrode the app transition type. Instead, we should remove
this logic and keep a flag whether the animation was prolonging was
finished already. If it was finished already, don't start the
prolonging when starting the transition.
Bug: 27154882
Change-Id: I1cd9e323867726ebd4b131ed5c13c3834d0f1107
- Add minimize state to dump
- If the docked app goes through a configuration change while the
docked stack is minimizing, the window list becomes temporarily empty,
and thus Task.isVisibleForCurrentUserLocked == false. Since we already
check at the beginning of the animation, we need to finish the minimize
animation on the docked stack no matter what happens.
- Adjust the condition when to notify divider controller about app
visibility. It turns out that under some conditions an animation is set,
but the app is not an element of mClosingApps nor mOpeningApps, so we
missed the visibility change of the home task
- Use getTopAppToken instead of getTopVisibleAppToken. When the token is
about to hide, it's already hiddenRequested, so we skipped changing the
minimize adjustment.
Change-Id: Ib9e2e3f6a5da7b7854b49857299a236e47baa6fc
Fixes: 28184044
This ensures that IpManager has a complete copy of DHCP state
before configuring the IPv4 address. That way, when the netlink
notification of the IPv4 address arrives, we are guaranteed to
have all DHCP information (including DNS servers and routes)
available and we will never send the IPv4 address before the DNS
servers.
Bug: 27605330
Change-Id: I732424dfe2408be9e40028563e99d610b541e12d
Since activity manager only issues a configuration change when
we are not relaunching the activity, the optimization to suppress
that on the client side is not needed anymore and only leads to
issues where there is a change in smallest_width but we are not
relaunching the activity because the change doesn't cross a size
threshold.
Bug: 28050773
Change-Id: I303c190bd7390363d1030edcdb2913b7c64c666d
We always update the display info before handling the configuration
change. Thus, we remove this weird interleaving asynchronous beast
of code and handle rotation and density in updateBoundsAfterConfigChange
and everything else in updateDisplayInfo.
Sending an asynchronous message to resize the stack only causes race
condition and issues.
Change-Id: Ifa86f62e816917822a8c1d42d13d4bf1ad9bc5bf
Fixes: 28316517
Bug: 28184044
If we start the forced resizable activity with an existing task,
avoid moving that task to the front. This can cause that a previous
task that was moved to the back gets moved to the front again just
because we started that activity. That's not good.
Bug: 28223489
Change-Id: If8acf31b8be98b82665de1015d5621331c37fb64
We could run into this situation on some devices (eg. clockworks),
the next activity doesn't get launched until we destroy this one.
allResumedActivitiesVisible() will return false if there is no other
activity running at all. Check top running activity and it's visibility
instead.
bug: 28400334
Change-Id: Ib8957e499580a10206fdd4e27da19fbc2bdb5843
