Since all pending intents are stored on a Set in the Notication object,
there is no need to individually check for specific pending intents.
BUG: 29480440
Change-Id: I27a18bb535a9a4bb6cb4e76bdc189e6c315a684a
Exception when targetSdkVersion is a letter API [eg 'N']. While this
is technically not according to the external docs, it's the behaviour
with prior platforms.
Bug: 29817839
Change-Id: I8382909dbe62de7b2ddfb7995ce11d5c2f43372e
We need to make every peniding intent that went in the notification
system to allow special handling of such intents when fired by a
notification listener. If a pending intent from a notification
is sent from a notification listener, we white-list the source app
to run in data saver mode for a short period of time. The problem is
that actions and the notificaion can have extras which bundles may
contain pending intents but the system cannot look into the bundles
as they may contain custom parcelable objects. To address this we
keep a list of all pending intents in the notification allowing
the system to access them without touching the bundle. Currently
the pending intents are written to the parcel twice, once in the
bundle and once as the explicit list. We can come up with a scheme
to optimize this but since pending itents are just a binder pointer
it is not worth the excecise.
bug:29480440
Change-Id: I7328a47017ca226117adf7054900836619f5679b
Previously the DisplayMetrics passed to a new ResourcesImpl
object would be generated from the default DisplayAdjustments.
We now use the correct DisplayAdjustments for the ResourcesImpl
and make sure to update them for things like rotation changes.
Bug:29619314
Change-Id: If2ba0d7670a4554dcd3fde9766e2337f20a191fd
(cherry picked from commit 8e8d23214a)
Fix a regression where a change in insets would forceLayout on the
view hierarchy but not run the measure/layout as a result. This would
cause layout requests to become stalled until a window-level relayout
event.
Bug 29634368
Change-Id: Ia3f32f5891c8b32c06c13f95ebd0572233572b04
When we want the WindowManager to clip our requested width/height
to the display frame, we need to pass DISPLAY_CLIP_VERTICAL/HORIZONTAL.
It seems this behavior was unintentionally applied without this flag
in previous releases.
Bug: 29602363
Change-Id: Ib98060e36efde0dbaabb59a758da5374035dbb62
Bug: 29586513
Also gives BackdropFrameRenderer a direct-destroy
of Choreographer since it's hammering on new Threads
and we don't want to wait for the GC to release
FDs.
Change-Id: Id2ec0af2ee4d5304961c4ab87a104ccb92f35fc2
When an app is being uninstalled for a specific user, only kill the
app under that user; leave the app running under other users.
Bug: 28875343
Change-Id: Ie60753cfd22df10a2b17d8c3732b6f19d2fe1fb9
I really have no idea how this can be happening (we check
for a null intent before posting the args), but add another
check before dispatching to try to avoid it.
Change-Id: Ic704850c9750b6a078c49ea628189be568031086
Bug: 29547000
Instead of shifting the window off screen fall
back to the UI-thread calculated values. This fixes
a race issue around tear-down where we stop
drawing long before our window is actually no longer
visible, as well as fixes a funky issue with
PRESERVE_GEOMETRY during first draw.
Change-Id: I792d1966f5aaee1e703295ae79166c723b97a1dc
Apps from different developers will now receive a different
ID for the same dynamic sensor. Additionally, all apps
will now receive a different/new ID for the same dynamic
sensor after a factory reset.
Bug: 28775590, 29547335
Change-Id: I15b48b974cbb1d53cc33dfdb7b9eb5f1b562190c
In getPersistedUriPermissions, use granted userId instead of the calling
userId to look up provider info.
Bug: 29058113
Change-Id: Ia637be414f9ef3b8e9bce13bb56bd335cfb28ac7
