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
With lazy bundle, exceptions thrown by deserialization of custom items
moved from being thrown in initializeFromParcelLocked() (when the bundle
is first touched) to being thrown in getValueAt() (whenever the item is
retrieved), which means they were escaping the defuse logic that caught
those exceptions. So, now also catching these exceptions in
getValueAt(), however, here we can be much less drastic, instead of
erasing the bundle, we can simply remove the bad element.
This also means we don't need to log wtf in initializeFromParcelLocked()
if sShouldDefuse = true but the bundle is not marked as defusable, since
touching the bundle doesn't carry the same consequences as before
go/lazy-bundle. So, I moved that log to unparcel(itemwise = true), ie.
whenever the entire bundle is deserialized on purpose.
Now, 2 types of defusing can happen:
1. If the (custom) item we're retrieving caused the exception, we'll
remove the item and return null.
2. If the exception was raised during partial deserialization, that is,
during the read of the map and its basic types (while skipping custom
types), the map will be left empty. I believe only manually written
parcels would cause this type of exception and if an exception is
raised here it will also be raised in the final destination too,
afaict. Because of this, we can now touch app-provided bundles
without fear of clobbering the data on its way to the final
destination.
Following conversation on previous CL, narrowed exception raised in case
of unknown type to be BadParcelableException.
Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest
Bug: 195622897
Change-Id: I4746140f63482a9ea475aac25897a447737393e4
There are two main usecases for this:
- provide an alternative route to implement features like markSensitive
(which requires only 1 function call per class, rather than a
function call and flag per transaction type)
- support RPC format transactions
Bug: 175814583
Test: atest android.os.ParcelTest, boot, manual
Change-Id: Ibaacc27a125a31e18d4b5889d05d12cc18d05624
* Bundle supports types char, char[], short[], float[] which were
falling back to serializable handling in Parcel because readValue()
didn't have specific support for those types. Adding support in Parcel
to avoid the need for length-prefixing and to improve performance.
Curiously some of those had read/write methods already.
* Updated Bundle to just pull the types above from the map since those
won't be lazy values anymore.
* We were missing a few custom type containers in our list of
length-prefixed types and we were listing Bundle unnecessarily as
length-prefixed since Bundle itself is already length-prefixed and
copies the correspondent section of the parcel internally.
Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest
Bug: 195622897
Change-Id: I1e15d59d883311685ffa32ece1f5a00e01bf6aea
Description:
Added replacements of `readList`, `readParcelable` and
`readParcelableCreator` APIs.
To avoid unexpected types of objects being unparcelled,
ideally clients would use the readTypedXXX() methods that
take the parcelable creator. However, this won’t be an option
for use cases involving deserializing children objects
inherited from non-final parcelable or serializable objects.
Currently out of ~4k parcelable classes, only ~1.5k
are marked as “final” in the platform. Hence it would be
necessary to introduce new replacements that take
an extra Class<T> parameter and before deserializing
we check that the class written on the wire is the
same or a descendant from the one provided as argument.
Doing so could enhance the security of Parcel deserialization,
More details can be found at go/safer-parcel.
Test: atest -d android.os.cts.ParcelTest
Bug: 195622897
Change-Id: Ie9a4cb4c3d6f1805b14df7b703aef43e2993d459
So that the API more closely matches intended usage, as requested.
Bug: 175814583
Test: aidl_integration_test
Change-Id: I2fb5f2d5059d7f9cd9e034a4d0d2e7aa63692067
Log mismatches as wtf to be able track those. Also added unit tests
around kindofEquals() and r/w mismatches.
Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest
Bug: 195622897
Change-Id: I361dd144b23975eedc8b19ed65457a1c5405936e
Tests that rely on this API does not attempt
to parse it, but rather treat this as an opaque
string and upload them.
Test: pass
Bug: 200729012
Change-Id: I025e2602ab506ad009ce48d6329a230f12f1060c
registered receivers to mark themselves explicitly as exported or not
exported.
Test: will add tests with enforcement
Change-Id: I9a16f566c54e389743dcf460734ecdc0b1081768
When we use Bundle's copy constructor we perform a shallow copy of the
underlying map, so lazy values are the same across the original and the
clone. So, if we're accessing the same item backed by a lazy value in 2
different threads, each one accessing a different bundle (the original
and the clone), both would have to synchronize on a common lock.
Although Bundle is not thread-safe, we should keep the expectation that
the client only needs to properly synchronize access to one bundle, not
more. To achieve this, we synchronize on the original parcel held by
LazyValue in get(), this removes the need for the above.
Note that after we produce the lazy values and put them in the map, we
don't have a reference to mParcelledData anymore inside the Bundle, the
only objects holding a reference to that parcel are the lazy values.
Also fixed some stuff in LazyValue:
* Fixed condition inside LazyValue that used mObject == null as
signal for "not deserialized" state since mObject can be null, so
switched to mSource != null.
* Made mSource volatile and adjusted operations to always check it
before, ensuring visibility of itself and mObject via happens-before.
This works because after checking mSource, if that's null, mObject is
guaranteed to be visible and valid, if it's not null, we can use it
since we're in the serialized state and this works even if another
thread deserializes in between as long as we hold on to a reference of
mSource in a local because the parcel is still valid.
* Remove the recycling of mValueParcel, otherwise we'd need locking to
ensure whatever was using it was still using a valid object. Decided
to just remove recycling for now since the plan is to remove
mValueParcel entirely when we add comparison and hasFileDescriptor()
methods that operate on a range to Parcel.
Bug: 195622897
Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest
android.os.BundleTest android.os.ParcelTest
Test: More tests coming
Change-Id: I501c91f505950338b23e7837e55f89b2f63ff93a
Bug: 178981521
Bug: 150670922
Test: Discover and pair with the CSIP supported device, and check the
pairing string in the dialog
Merged-In: I3e99c59e0cb974409291e1b4c28393106784e133
Change-Id: I3e99c59e0cb974409291e1b4c28393106784e133
These two are the only annotations in the android.annotations package
that are not @hide -- they are actually in the public API.
As such, they are not suitable in the annotations library. Move them
back to frameworks/base where the other core java APIs live.
Bug: 186197911
Test: m
Merged-In: Ide01e4e7840bddf1e024e9024771e528d17a1d80
Change-Id: Ide01e4e7840bddf1e024e9024771e528d17a1d80
A test should test the actual behavior as much as possible.
However, if the flag is true, matchesMobile/matchesMobileWildcard
will always return true regardless of the network type and metered.
Thus, remove this flag would be closer to the actual behavior.
Bug: 183776809
Test: atest FrameworksNetTests
Change-Id: I0907a08ca1dd8a14a738db4057ea5ff6a0cd925a
Bluetooth can no longer call SystemConfig and need to use the manager.
Bug: 190440540
Bug: 199279027
Test: Manual
Tag: #refactor
Change-Id: I065ab407c83cd2edf2244e4170496b0979ac562c
For isInbandringing API - it is used in the call journey and would
change the behavior(undeterministic) of the call if not used.
Stop/StartScoUsingVirtualVoiceCall is used in the BluetoothShim layer
specifically for testing and mocking in the Android Apps. Seems
reasonable to keep this as a SystemAPI given that it has no params and
unlikely to be changed.
Bug: 195160939
Tag: #feature
Test: Manual
Merged-In: I02b2e7e5e0be3b462f7c25b655e669e2c7fe47eb
Change-Id: I02b2e7e5e0be3b462f7c25b655e669e2c7fe47eb
