When PreferenceScreen contains the Intent tag with
the extra tag, the parsing of xml file is failed and
causes the render problem on Layout editor.
Test: N/A
Bug: http://b.android.com/233302
Change-Id: I987de7aa125299d46fc1b7670f07f3dd4427ee21
Yum!
Also needed to have a Context.revokeUriPermission() variant that is sane,
so reasonable CTS tests can be written.
Test: new ClipDataJobTest added.
Change-Id: Ia3135ea788a6e32c971bae7dab3a844d0ef4139c
Rather than require an a-priori Notification be supplied in order to
start a service directly into the foreground state, we adopt a two-stage
compound operation for undertaking ongoing service work even from a
background execution state. Context#startForegroundService() is not
subject to background restrictions, with the requirement that the
service formally enter the foreground state via startForeground() within
5 seconds. If the service does not do so, it is stopped by the OS and
the app is blamed with a service ANR.
We also introduce a new flavor of PendingIntent that starts a service
into this two-stage "promises to call startForeground()" sequence, so
that deferred and second-party launches can take advantage of it.
Bug 36130212
Test: CTS
Change-Id: I96d6b23fcfc27d8fa606827b7d48a093611b2345
(cherry picked from commit 79047c62b58fb0a0ddf28e2b90fe4d17e05bc528)
In some cases, if an error happens, no session will exist in
BridgeRenderSession.
Test: Added small regression test
Change-Id: Ic9be381767626766395c65044542c197ed7649e7
In many cases, throwing an exception will stop the inflation or
rendering of a layout. Sometimes, we could recover from some of the
failures and render a layout that is "usable".
I've done a first pass trying to follow the following rules:
- Try simple recoveries by choosing sensible defaults. Not trying
complex recoveries.
- Only recover if the exception is not part of the class behaviour.
Avoided removing declared exceptions or exceptions that are expected by
the framework.
- I've kept assertions in place so, in most cases, the behaviour will
be almost identical to the previous one with assertions enabled.
Test: Checked with existing tests
Change-Id: I0001fdd3c808cf405c4eb8d734b9bbe63493e05c
Rather than require an a-priori Notification be supplied in order to
start a service directly into the foreground state, we adopt a two-stage
compound operation for undertaking ongoing service work even from a
background execution state. Context#startForegroundService() is not
subject to background restrictions, with the requirement that the
service formally enter the foreground state via startForeground() within
5 seconds. If the service does not do so, it is stopped by the OS and
the app is blamed with a service ANR.
We also introduce a new flavor of PendingIntent that starts a service
into this two-stage "promises to call startForeground()" sequence, so
that deferred and second-party launches can take advantage of it.
Bug 36130212
Test: CTS
Change-Id: I96d6b23fcfc27d8fa606827b7d48a093611b2345
This Intent will be used in Settings to show the settings UI for the
Ephemeral resolver. Settings can get the correct component to send the
Intent to by calling
PackageManager.getInstantAppResolverSettingsComponent
Bug: 35918998
Test: Boots
Change-Id: I0edcf85704f2c19e0ee27f91b6ef057d52e32778
(cherry picked from commit aa49cb86e6d5f23d82c97db32c848bc4ea2b81bc)
This Intent will be used in Settings to show the settings UI for the
Ephemeral resolver. Settings can get the correct component to send the
Intent to by calling
PackageManager.getInstantAppResolverSettingsComponent
Bug: 35918998
Test: Boots
Change-Id: I0edcf85704f2c19e0ee27f91b6ef057d52e32778
Do not dispose Bridge on tearDown. The concept of disposing the Bridge
only made sense when we were loading it dynamically. Some classes have
static initializers that will fail after the dispose (like Typeface).
Test: N/A
Change-Id: I9c934432232bda02a4d26425587096fb6dc957b0
Updates the resource handling after the changes to the ResourceUrl API
changes.
Test: Existing tests should pass
Change-Id: I314a20673cf94e4ef27e9712d3fa7b6f69bba796
There is some flakiness in View#onConfigurationChanged callback -
if ViewRootImpl receives config update earlier than ActivityThread,
it may not detect the configuration change and skip inner updates.
Also now ViewRootImpl assumes that it receives the global config as
a param, but instead it gets merged config from WM. This means that
ViewRootImpl#sConfigCallbacks was sending incorrect values to the
recipients.
This CL switches to sending global and override configuration to the
client separately. Also in case if there is a corresponding activity,
it first updates it and waits for update callback to ViewRootImpl.
This way global config and override config for activity will always
be set first and resources will be updated before inner state of
ViewRootImpl is updated.
Bug: 35870157
Bug: 34164473
Test: android.server.cts.ActivityManagerDisplayTests
Test: testOnMovedToDisplayCallback
Change-Id: Ic9e7541cf25ecfac6ec90e48f7efb0ece91f657e
repositionChild, performDeferredDestroy, and SurfaceControl with
background were all only used by SurfaceView and are now no longer
required in the wm.
Test: Only red.
Change-Id: Icb773572e6d6202f78a6d23b2431fbfacbe272c6
