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
When removing the ContentObserver wrapper from our internal
bookkeeping we were using the wrong key. That led to future
re-registrations thinking they were reusing a currently-
registered observers, but instead never getting onChange()
notifications.
Change-Id: Id3111db057ae63194049d7d48d45b75be6bb0000
If disabling Bluetooth times out, wait for an additional amount of time
to ensure the process is shut down completely before attempting to restart.
Bug: 29738770
Change-Id: I43dec35a1e03d12cb07863babea97d55baa32528
We can't update this in updateOomAdjLocked(), because we very
deliberately only iterate through services in there as needed.
The correct thing to do is update the process as services/connections
are associated with it, so do that.
Now basically all of the logic for tracking the state is in
ActiveServices, as we bind and unbind services and add and removing
them from process records. It's a little messy because we don't
have a central place for removing them from process records, which
should be cleaned up in the future.
Part of fixes for issue #29480440
Change-Id: Iac96f002a5b4e3b0277df244ff7b90f59a6e8440
fixes: 29771171
This is a regression from HWUI_NEW_OPS, a roundOut
was missing in the new path that was in the old one
Change-Id: Ibf223d550bb5525781864dd9b7f7cd6d73adb98b
State of dismiss view was wrong when the panel was closed, thus, we didn't
apply our logic for smooth panel deceleration anymore.
Bug: 29579394
Change-Id: I79718517e776adad092457aba6db18219998fde1
While performing ensureActivitiesVisibleLocked we should only
resume activity in focused stack. Otherwise we can get several
resumed activities at the same time.
Bug: 29619461
Change-Id: Id65fe1a29841ee3166694bfb6a8236151b9fc7ec
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 8e8d23214a71d8813ebd3676b192924c530cb913)
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
