In extreme cases the list of recent tasks can grow beyond the size
of a single Binder transaction. This change moves over to
ParceledListSlice which handles chunking any large results.
Bug: 29635557
Change-Id: Iaf1227234f5f8c9451f73a6a5c1dc89f2067f05f
In the past, if an app never renders to a SurfaceView, it will be
invisible despite having FLAG_OPAQUE. This means an app could leave a
totally empty SurfaceView (never drawing in to it) on top of a second
SurfaceView, and expect the second one to be visible. This is probably
buggy app behavior because FLAG_OPAQUE means if they ever draw anything at all
in to the top SurfaceView the bottom one will become totally invisible.
However this has worked in the past, so we have to preserve things for
apps. To accomplish this we ensure only the bottom most visible
SurfaceView for a given AppToken will receive a background. We achieve
this by synchronizing through the app token whenever visibility or
layering of a SurfaceView changes.
Bug: 29580298
Change-Id: I0023326323cb961b56404fd49093384e7b72aa54
Add missing attribute to the base Theme to ensure the context menu
does not appear completely invisibly.
Bug: 29796385
Change-Id: I4f50579622e97656e09a5ddb6e13313f84efc972
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
It must call updateWhitelistManagerLocked() because the app might have
other services with the whitelistManager set, in which case the process
record should not have whitelistManager reset.
Fixes: 29480440
Change-Id: I268278c646aaa89a352f02178b294c02c3c11d35
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
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
