am: bca6ffddd8
* commit 'bca6ffddd8e9db7f89565a13cc3322e8dbbfdc2a':
Make sure all Notification actions are shown
Change-Id: I221b6755607d55b8e8f2d14ae75017adc08c97cc
am: 798a860efb
* commit '798a860efb0c599448483d5a8e6a9429777c5bc5':
Make sure all Notification actions are shown
Change-Id: I094ba82280047da811da0e65e1a2e6d38f88497f
am: c09542b84e
* commit 'c09542b84ed974b5f74bdc67937cefe3cf527e19':
Add api to WearableExtender for setting and getting the dismissal id. Bug:27696581
Change-Id: Id1d0131b1e2ef55863d917d7b647694e57a17419
am: f4810f5506
* commit 'f4810f5506203ac03439d1ed6e33e021540568f8':
Add api to WearableExtender for setting and getting the dismissal id. Bug:27696581
Change-Id: I3a16e15adaf26be3528224c265be9a0e82957a38
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
am: 98d57313f2
* commit '98d57313f247a80928b6358dda05a16c3b4000dc':
Flag to mark foreground jobs, fix data saver.
Change-Id: Id863d0ff4f8e7f13049231298feaab9839b4667c
am: 9a977b7d45
* commit '9a977b7d45df0d3d59c5eec7f9534c3bd5fcd91d':
Flag to mark foreground jobs, fix data saver.
Change-Id: I908d725a84e9590d0da38a586b066a63473d4f28
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
am: 4398aad
* commit '4398aad9542ff58df6ac2aa38f5e31f18021a306':
Show forced resizable based on top activity
Don't move forced resizable info activity to the front
Change-Id: Ib5a88c47ef73b461fb1d09b45e4763b0d6512666
am: 1601067
* commit '16010672874c7fbacd248c87a31396f7d8222334':
Show forced resizable based on top activity
Don't move forced resizable info activity to the front
Change-Id: Ifa8fb6f3c0c98a74b959be82a523dd4987a0d9d5
am: 831ecc8
* commit '831ecc81f982282bdcc2121c2fa3ece22ac997e0':
Show forced resizable based on top activity
Don't move forced resizable info activity to the front
Change-Id: Ib61028c751a31b437fb459bd094c2fedadd40abe
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
