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
Add functionality to capture/intercept installd communication, and
use this to return the full communication for dexopt. These parameters
can be used to drive otapreopt_chroot directly.
Keep the old direct invocation alive until devices have transitioned
to a service that exposes this API.
In preparation for renaming of A/B OTA artifacts to include target
slot names.
Bug: 25612095
Bug: 28069686
Change-Id: I14728ee1266f3882cada8f08dd21891ed5f7a0cb
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
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
- Don't publish shortcuts when their target activities are not main.
- Only scan manifest shortcuts for main activities.
- When an app is updated, remove shortcuts that no longer belong to
valid main activities.
- Also re-publish manifest shortcuts after 'clear data'
- Also listen to PACKAGE_CHANGED and disable/re-publish shortcuts
properly.
Bug 29355786
Bug 29582255
Bug 29601844
Change-Id: I6c701ce669cf30a227bc2af4aa01de467ef73e3a
+ Rename functions in ProtectedPackages.
+ Add a Set in ProtectedPackages to store protected package.
Bug: 29116229
Change-Id: Ib7dd93a158c09ebbf70f4d57c1afbd2c5102edbd
Muting ringer and media volume and turning off the flashlight
before starting a new session. Also, resetting the configuration of any
new demo user to the configuration of user 0 on the device. Moved
RetailDemoModeService and RetailDemoModeServiceInternal to more
appropriate new packages
Bug: 29519612
Change-Id: Ib65f89ce61afab2d2f1b2dd0c761f5d35a466181
It turns out that we can let the system to call
InputMethodService#exposeContent(InputContentInfo, EditorInfo), which
added in my previous CL [1], during the IME is calling
InputConnection#commitContent() as follows.
[IME]
InputContentInfo contentInfo = new InputContentInfo(
contentUri,
new ClipDescription(description, new String[]{mimeType}),
linkUrl);
getCurrentInputConnection().commitContent(
inputContentInfo,
InputConnection.INPUT_CONTENT_GRANT_READ_URI_PERMISSION,
null);
[App]
try {
contentInfo.requestPermission();
// Load inputContentInfo.getContentUri() here.
} finally {
contentInfo.releasePermission();
}
This gives us flexibility to let InputConnection#commitContent() do all
the magic for IME developers like other APIs such as
Context#startActivity(), rather than asking them to call one more API to
grant a temporary URI permission like a scenario where
Context#grantUriPermission() is used.
[1]: I2772889ca01f2ecb2cdeed4e04a9319bdf7bc5a6
25e0813e6e
Bug: 29450031
Change-Id: I99536cd58c9984af30b0bafb4a1dd25a26634a2d
