Cannot use both `{@docRoot}` and leading `/` when specifying URLs
Bug: 197663210
Change-Id: If6762b95a3d6991b4732684853d974a06da032bc
Test: make ds-docs
Exempt-from-Owner-Approval: Docs-only change
The system is overwhelmed by an enormous label string returned by
the load label api. This cl truncates the label string if it exceeds
the maximum safe length.
Bug: 67013844
Test: atest PackageManagerTest
Change-Id: Ia4d768cc93a47cfb8b6f7c4b6dc73abd801809bd
- Allow source to specify an instance id for the drag instance
(we'll create one otherwise if not specified)
- Log start/drop/end as per go/dragdrop_splitscreen_logging
Bug: 191686897
Test: statsd_testdrive -terse 90
Change-Id: I215208777e3627859079abac90520b1772478c5e
renamed to avoid conflict with existing copy in the R framework.jar.
The framework.jar copy was removed during S development
Bug: 195608856
Test: build
Test: cts-tradefed run cts -m CtsMediaTranscodingTestCases
Change-Id: I40ab066cd61be8d278f21cc788016f2edd6bb86e
AttributionSource checks calling UID on unparcel (so the check is not
necessary), and some ContentProviders may clear calling identity.
Test: Manual
Fixes: 188755312
Change-Id: If629eea3ba8c1a57fd4b7aff0fec2c0acb5f69be
The system is overwhelmed by an enormous label string returned by
the load label api. This cl truncates the label string if it exceeds
the maximum safe length.
Bug: 67013844
Test: atest PackageManagerTest
Change-Id: Ia4d768cc93a47cfb8b6f7c4b6dc73abd801809bd
Merged-in: Ia4d768cc93a47cfb8b6f7c4b6dc73abd801809bd
Parcel implementation would crash the system server otherwise.
Any exception is OK as it'll cause the cache to be invalidated.
Crash is not OK.
Bug: 194632313
Fixes: 194632313
Test: atest PackageParserCacheHelperTest
Change-Id: I58a4496b4646e172e6c3aee9ea17854a7ef55eaa
This feature will allow OEMs to opt-in specific devices/builds to per-app compat overrides.
Bug: 188500456
Test: N/A
Change-Id: I00108d163f752d23c380496ccac971cf0fcfe0f6
We trust any incoming value from the system UID, so we should also
trust values coming from the root UID, which includes many shell
commands such as "svc".
Bug: 193659633
Test: atest BluetoothInstrumentationTests:com.android.bluetooth.btservice.AdapterServiceTest --rerun-until-failure 100
Change-Id: Ied07731345f08fc3c4df465a3773e35c8df7c59a
The Bluetooth stack is just one example of an application that makes
self-calls through public APIs, which makes it very difficult to
unconditionally validate AttributionSource arguments.
(The AttributionSource is correctly defined the first time a remote
caller enters the Bluetooth stack, but we've found many cases where
Bluetooth stack calls back into itself without clearing the Binder
identity, causing validation chaos.)
This change is an attempt at gracefully solving this by performing
validation automatically as part of unparceling an AttributionSource
the first time it enters a process. This strategy isn't perfect,
since transporting an instance inside a Bundle would risk
unparceling much later, possibly long after the calling UID
information has been discarded. We're rationalizing that this risk
doesn't exist since AttributionSource was only added a few months
ago, and isn't being used in this way.
We still intend to circle back and provide a better strategy in a
future release for transporting AttributionSource across AIDL which
will handle the nuances of self-calls.
Bug: 188391719
Test: atest BluetoothInstrumentationTests
Change-Id: I10b198cfcd8f361e19d52f86deb7f10f05fec891
For cases where the attribution soruce doesn't need to be
registered as trusted we are now using a shares static
token since the only purpose of the token in these cases
is for watching the source process dying as opposed to that
and security for registered cases.
bug: 192415943
Test: CtsPermissionTestCases
CtsPermission2TestCases
CtsPermission3TestCases
CtsPermission4TestCases
CtsPermission5TestCases
Change-Id: I93fde9ca1cacada7929761533dcae11b2736ce1e
We've seen evidence of a Binder leak, and our hunch is that it's
caused by one of these anonymous "new Binder()" sites. Adding
descriptors will help us identify the leak cause.
Bug: 192415943
Test: atest BluetoothInstrumentationTests
Change-Id: I30cd15f084cf50f67edd833b27b853c4b22e1db1
- Previously we were adding the activity info to the ClipData, but
that data is provided to non-intercept windows when the drop happens
and can be retrieved using reflection. The intention was only to
provide this activity info to the shell global intercept window
for invoking split.
Instead of baking the info into the ClipData, we pass the resolved
info along side the data and only construct a ClipData with the
additional info for the intercept window.
Fixes: 191057499
Test: atest DragDropControllerTests
Change-Id: I2ccc9f1f666ff2a388f22b6e6a7b5eea3102964c
