In some cases it is possible for activity manager to request
a resumed activity to stop when it's visibility changes. This
is a valid transition, however we need to make sure to pause
the activity on the client side before stopping it so lifecycle
transition works as expected.
Bug: 28574036
Change-Id: I759b38bbd1c9c3bb0475759bcb638d8223fa504d
When voice interactor goes null or changes, cancel all existing
active requests and clear them so that they can be re-submitted.
Bug: 28487567
Change-Id: Ibcf024efcc81ff18ef3babfa9a169292207bc816
Allow all application classloaders to load native
libraries from anywhere under /data
Bug: http://b/26954419
Change-Id: I8a808bcdf4a00f7d40b513d4e2ca3d1e76c0909f
Allows callers to opt-out of blockading network traffic during boot and
on VPN app failure.
Bug: 26694104
Change-Id: Ibfbd43ad09a25f2e38053fcd6306df3711f8bde2
When entering split-screen mode by long pressing the recents button, the
top task in the fullscreen stack is moved to the docked stack and the new
top task is the fullscreen stack is considered visible for a short amount
of time until sys-ui launches the recents activity. This causes the new
top activity in the fullscreen stack to be relaunched due to configuration
change.
To fix this sys-ui now sends an hint to activity manager to move the home
stack forward so that it can be on-top of the fullscreen stack and makes
it invisible before recent is launched and animated in.
Bug: 28470261
Change-Id: Icfd85e932fe913dfb498752b5878cc7c690fd559
When a job will eventually run in the foreground, the internal
scheduling needs to ignore any background network restrictions when
satisfying constraints. This also means the job should ignore the
current device doze state, since the requesting app could get the
same behavior by starting their own foreground service.
Always dispatch network policy changes to ConnectivityService first
to ensure that it has up-to-date information. Fix bugs around data
saver that were causing networks to not be marked as BLOCKED for
background apps; before this fix apps would have been spinning in
internal connectivity loops, thinking that the network was actually
connected when the kernel was actually blocking their traffic.
Offer new ConnectivityService method overloads to ignore the blocked
state for a specific UID.
Print unsatisfied job constraints to aid debugging.
Bug: 26571724
Change-Id: Iaaa17933e6dc1bf6d3dff26d0bfc12222e51e241
Ensures each action gets at least its minimum width to prevent
an overly long action from squeezing out the others.
Change-Id: Ifb6253051b556bbab4738abef12dad0bb6f3c3d6
Fixes: 27996783
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
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
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
ViewRootImpl may be null at this point if
we didn't preserve. Sorry about the churn.
Bug: 28413589
Change-Id: Iebfd819490252b52332d94ccefbddfae160087cf
To be able to reuse this code when creating a classloader for
the system_server.
Bug: http://b/27245894
Bug: http://b/27702070
Change-Id: I928175a39a1beb0446d863a5b8f5edf94686e768
(cherry picked from commit 5d7d777fa6)
We're really only interested in tracking down when the system UID
tries touching missing data paths, since it's the only one with enough
permissions to mkdirs() directly without going through installd.
Without the guard added in this CL, we'd end up logging for direct
boot aware apps that tried obtaining CE paths while locked, which is
perfectly valid.
Bug: 28272737
Change-Id: Id24f3160f61d8ad8047d5c551bc6a91c868bd301
This change takes an app's shared libraries specified by <uses-library>
and passes it through to dex2oat to be used during compilation.
Part of a multi-project change.
Bug: 26880306
(cherry-picked from 7b331b6a8a)
Change-Id: I523b1b74775e7ed27072498509e743f1f10b1164
Framework edition
In some cases restartLoader calls that happen in quick succession
could cause the new loader to become stuck and never run. Treat loader
restarts for loaders that have not yet started the same as starting a
brand new loader.
Bug 27437287
https://code.google.com/p/android/issues/detail?id=56464
Change-Id: Ia4e276fc8e63d43b9c52c6155cea827b194d8b19
- Supply the appropriate HUN view
- Make sure we can properly parcel and unparcel the Style
Change-Id: I86c70b9c41689da98f45219b244aac0dec461002
Fixes: 28400885
- If a notification is updated, make sure that the focus
is kept even when the change cannot be applied inline.
- Make sure to update the pending intent to match one
of the new actions in case the old one is no longer
valid, and to prevent sending text to the wrong action
unintentionally.
- Keep focus when switching between heads-up and expanded.
- Prevent the action container from becoming transiently
gone during reapplying.
Fixes: 27357771
Change-Id: Ie9f49935827f6efb15b73f8d686f0c110448456a
When reusing a ViewRoot and DecorView as we do with preserveWindows
there are two issues with SurfaceHolders. First, we update the
SurfaceHolder callbacks when we call ViewRootImpl.setView. In the
case of preserved window relaunch, the DecorView is reused and there is
no call to setView. We need the ActivityThread to notify the ViewRoot
that something has changed. Secondly, we were assuming the only time
a new surface would be created for the purposes of SurfaceHolder
notification was when we previously did not have a valid surface.
Instead we need to check if the native Surface object has changed each time we
get a result from relayout.
Bug: 28331264
Change-Id: If1b4aab9b2ba579fa040e2a3ab4471842476d82f
We shouldn't profile *any* packages loaded by the system_server, not
just the system_servers own ("android") package.
bug: 28241500
Change-Id: I5f3f477b40c758030a5bdc8e97d17cab6e68e204
