Tools need all of the valid constants to handle legacy apps; even
though we want developers to use the new constant names.
Bug: 29824931
Change-Id: I5f8055d50d1d3f32cfbed7459d8a497cfbd3661e
Screenshots are written to shared storage, which isn't available
until after the user unlocks their device for the first time. So
instead of showing a misleading animation and then the "failed to
persist" notification, skip the screenshot completely when storage
is locked.
Bug: 27208608
Change-Id: I654c6688f68b2395f6e6065aa716551948f302b3
Awhile back, we switched to running PRE_BOOT receivers after the user
is unlocked. Since these receivers include providers like Contacts
and MediaStore that can take a long time to upgrade, it may result in
apps like Dialer or Photos appearing to hang, so we need to help the
user understand that the system is still upgrading in the background.
Bug: 28164677
Change-Id: I18448534b6067f8508b1ffb2d43c106c02c265a0
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
Multiple users can be running foreground if work profile is enabled,
so we need to send broadcast to all of them.
Bug: 29788027
Change-Id: I80b21c97cec857bebc5fd05f0c04ca134542b4d3
The code sample in the "Load a Scaled Down Version into Memory"
section on the "Loading Large Bitmaps Efficiently" page now handles
corner cases correctly when determining how to downscale an image by
a factor that is equal to a power of 2.
Bug: 25944661
Change-Id: I971f90fb5d153abec4bc1d96ae465e3910e82efa
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
