By using ActivityInfo.Config to annotate the return type of
Configuration.diff, it not only solves the wrong document but also
makes the documentation of Configuration.diff consist with
the documentation of Configuration.updateFrom.
The final result is the following.
```
Returns a bit mask indicating which configuration values have changed.
Value is either 0 or a combination of ActivityInfo.CONFIG_MCC,
ActivityInfo.CONFIG_MNC, ActivityInfo.CONFIG_LOCALE,
ActivityInfo.CONFIG_TOUCHSCREEN, ActivityInfo.CONFIG_KEYBOARD,
ActivityInfo.CONFIG_KEYBOARD_HIDDEN, ActivityInfo.CONFIG_NAVIGATION,
ActivityInfo.CONFIG_ORIENTATION, ActivityInfo.CONFIG_SCREEN_LAYOUT,
ActivityInfo.CONFIG_UI_MODE, ActivityInfo.CONFIG_SCREEN_SIZE,
ActivityInfo.CONFIG_SMALLEST_SCREEN_SIZE, ActivityInfo.CONFIG_DENSITY,
ActivityInfo.CONFIG_LAYOUT_DIRECTION, ActivityInfo.CONFIG_COLOR_MODE,
and ActivityInfo.CONFIG_FONT_SCALE
```
Test: make docs
Test: review reference/android/content/res/Configuration.html in
out/target/common/docs/online-sdk-docs-docs.zip
Fixes: 171738297
Bug: 171716892
Change-Id: Iaa2ac25bc1269e4a9a625cce386f51984ffff923
Android T doesn't exist yet, removing the link.
Test: presubmit, comments only, should just be "is build fixed"
Bug: 202151792
Change-Id: I2123f804aaed39eb7d31f25058c59a3c1df4d7d1
and put a warning where it's not possible. This is to make sure we know
when to touch bundles provided by apps.
In this CL:
* deepCopy() now doesn't deserialize lazy objects before copying. It
doesn't copy them either, it merely passes them into the new map as
the same reference. This works because we implemented fine-grained
locking into each lazy value, so concurrent access won't be a problem.
Furthermore, LazyValue caches the deserialized object, so we'd still
honor the contract of deepCopy() that "Other types of objects (such
as Parcelable or Serializable) are referenced as-is and not copied in
any way". I had to perform one extra check in the synchronized block
in LazyValue to guarantee this (double-checked locking), I explain
that in the comments.
* Removed filterValues() and codepaths that used it. This was created
with the purpose of removing items whose classes weren't available to
the system to prevent crashes coming from full deserialization. This
is not a concern anymore with lazy bundle, hence we can remove the
codepaths altogether (see email for more details).
* Put warnings in javadoc of getMap() and PeristableBundle().
Test: Boots
Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest
Bug: 195622897
Change-Id: I14bb6a7874814f42cbcc6b5fd372c42752aa74c8
registered receivers to mark themselves explicitly as exported or not
exported.
Test: will add tests with enforcement
Change-Id: I9a16f566c54e389743dcf460734ecdc0b1081768
Attribution source constructor are hidden api
Add a Builder option to take a AttributionSource as parameter
Test: atest BluetoothInstrumentationTests
Bug: 195144968
Tag: #refactor
Ignore-AOSP-First: No such thing on aosp
Change-Id: I901c8afff6a40bd8484fd8e10baf290aa483c280
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
(cherry picked from commit 1168d9d014)
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
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
Its existence allows implicit readParcelable calls to invoke a Parcel
operation with mismatched read/write data sizes, allowing someone to
swap out the data on a reparcel.
Internal classes will use writeIntentInfoToParcel, so this is safe to
remove.
Bug: 191055353
Test: atest com.android.server.pm.test.parsing.parcelling
Change-Id: I44faa635faf8a77894a3dda8adf89c10064e53f1
(cherry picked from commit 75214cc510)
