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
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)
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
Make sure that when our Resources get updated, that DisplayAdjustment
and Display properly reflect the potentially new screen dimensions.
Bug:28388969
Change-Id: I340550ea094ece87abc8790dd46aaa60ab3cedd3
This allows WebView to add itself to the ResourcesManager and
remain their even after configuration changes and multi-window
changes.
Bug:29112218
Change-Id: I2cb131ae2c61fb58c48babafdd46c1882be96aa9
Get the canonical identity and metadata about the package from the
Package Manager at time of usage rather than rely on the caller to
have gotten things right, even when the caller has the system uid.
Bug 28795098
Change-Id: I215786bc894dedf7ca28e9c80cefabd0e40ca877
Because it's not guaranteed to use any builder at all,
there is another case where the SmallIcon could remain null.
We are now checking this lazily instead of ahead of time.
Change-Id: I7a0feff6911b2bce6707427259d3423131a26e32
Fixes: 29255365
This method is called by AM with the lock held, so can't take the
DPMS lock.
It still takes a different lock, but we don't call into the external
world while holding this lock, so this is fine.
Bug 29242568
Change-Id: Idbecdd7d97385ca66c693903443471fdbae833e6
When using setLatestEventInfo the icons would not be shown
at all anymore, leading to a crash if they were grouped.
This CL makes sure the smallIcon is always set even for those
legacy apps.
It also fixes the usage of setShow when, as legacy apps wouldn't
have the time anymore.
Change-Id: I2645175b2adabcedbbfec7a502b89d143d2b9bd3
Fixes: 29255365
Fixes: 27430676
Fixes a bug where the action bar would get cut off slightly
resulting in a bad transition when transforming between action
bars that were correct and those that were cut off.
Fixes: 28935363
Change-Id: I7d8eeb5e5fa545820a8979ea09816b330bdb384b
Fixes a particularly bad transition in the case where there
is one incoming message to a group.
Change-Id: Ieddece4a496292a69e14cdcd74d94986938d8223
Fixes: 29043489
- Fixes a bug where we would not update the
overlay restrictions if the VR listener we are bound to
changes bug the VR enabled state doesn't.
- Also fixed a case where the notification listener access
and location permission were not granted/revoked for the
correct user. For example, if a vr activity in one user calls
a VR activity in another (possible for cross profiles) we end
up not revoking the special access for the vr service in the
first user. The notification listener setting was also updated
for the system user instead of the user for which we grant/revoke
specal access.
- Properly remove the overlay restrictions for the old user
if we transition from a vr actiivty in one user to a vr activity
in a profile of this user.
Bug: 29273985
Change-Id: Ib1de6f2f5445001ac61edca5c77ea3a066544307
The infrastructure is here but not yet fully plumbed, so gracefully
provide the historical behavior until the rest is in place.
Bug 29220492
Change-Id: I36feaf68099d85e4ae11a5262002ee85346703ed
The ContextThemeWrapper's configuration override must also
be applied to ResourcesManager during a configuration change.
Bug:27644297
Change-Id: Ic126308b753979c18801d422a8243aa4daf45147
Referrer information is passed as an intent extra to each Activity,
therefore if that intent contains a custom parcelable unmarshaling
the intent extras will fail in a call to getReferrer. Insulate apps
from this concern and log a warning when it happens.
Bug 28972438
Change-Id: I37dbc033bfcfe816e4b58b382c012854fbed943b
ApplicationInfo is mutable and unfortunately some apps do actually
modify the flags. Due to the lazy loading nature of the network security
config this may lead to issues. Instead cache the needed flags and
resources at application startup.
Bug: 29063413
(cherry picked from commit 276ee969be)
Change-Id: If638a716fd903b4e9dbabcbecb38bd4e26fef08c
