* 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
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
Bluetooth can no longer call SystemConfig and need to use the manager.
Bug: 190440540
Bug: 199279027
Test: Manual
Tag: #refactor
Change-Id: I065ab407c83cd2edf2244e4170496b0979ac562c
Due to lazy bundle, we can now have bundles touching the original parcel
(used to create the bundle in the first place) during serialization.
This can lead to races within the same bundle or across bundles when
the same is copied.
Both these cases happen in notification manager when it's about to post
notification for its listeners. In summary, it notifies all the
listeners in oneway calls and the listeners make a call back to
system_server to retrieve the notification. These calls back can race
and lead to the bug observed in http://b/198355758#comment12.
In order to avoid that we use appendFrom(mSource, mPosition) in
LazyValue.writeToParcel() since that method doesn't change or use the
cursor of mSource. We only ever write to mSource before creating all the
LazyValues, so there can't be any r/w races.
Test: 1. Attach debugger to system server and put log breakpoints in
racy lines in Parcel$LazyValue.writeToParcel
2. atest -d CtsHostsideNetworkTests:com.android.cts.net.HostsideRestrictBackgroundNetworkTests#testDozeModeMetered_enabledButWhitelistedOnNotificationAction
3. Observe no crashes
Test: 1. Attach debugger as in previous "Test:" line
2. Create a notification with a parcelable extra, post it
3. Observe no crashes
Bug: 195622897
Bug: 198355758
Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest
Change-Id: I02f890d22910c69e29e791b55d3655962a6dddfd
Expose requestModemActivityInfo in TelephonyManager using the Executor +
Consumer pattern, and modify clients to use it.
Test: atest TelephonyManagerTest#testRequestModemActivityInfo
Fixes: 170427831
Change-Id: I7e8134c8058017b888c324a9f85d473fc3cdd8f5
Merged-In: I7e8134c8058017b888c324a9f85d473fc3cdd8f5
Update ModemActivityInfo to present a nicer API surface and expose it as
a SystemApi. Also change clients in BatteryStats to match the new
surface.
This is part 1. Part 2 will modify the methods in TelephonyManager to
use a more up-to-standards threading model.
Bug: 170427831
Test: atest ModemActivityInfoTest
Change-Id: I762ed949342861c75d94eafce88335e7bd8c9139
Merged-In: I762ed949342861c75d94eafce88335e7bd8c9139
In aosp/1819733 we extracted Parcel.hasFileDescriptor() for types
produced by Parcel.writeValue() and consumed by Parcel.readValue() out
of Bundle into Parcel. It's supposed to handle LazyValue too.
However, we put a check to verify that it was a type supported by
readValue()/writeValue() by retrieving the VAL_XXX type of the value via
Parcel.getValueType(), however, that method throws for LazyValue since
we don't actually write that special type on the wire. However, we still
want Parcel.hasFileDescriptor() to support it, so moving the check into
a last 'else' statement, making sure we don't throw in case the value is
a LazyValue.
Bug: 195622897
Bug: 198433827
Test: atest CtsNetTestCases android.net.cts.CaptivePortalTest#testCaptivePortalIsNotDefaultNetwork
Change-Id: I1e6ec122557c12e74db6890e1631fec3cefe31f6
Allow Parcel data to be dependent on the binder in question. This
exposes the API in Java which is previously only available in native.
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: I134b6e23da83699195a8f075b9f50b6409ecff86
Implement lazy deserialization for custom types in bundle:
* Parcelable (VAL_PARCELABLE)
* Serializable (VAL_SERIALIZABLE)
* Parcelable array (VAL_PARCELABLEARRAY)
* Lists (VAL_LIST)
* Sparse array (VAL_SPARSEARRAY)
* Bundle (VAL_BUNDLE)
This enhances security, makes bundles more robust to deserialization
errors and avoid deserializing unneeded objects in some cases*, for more
details check go/lazy-bundle.
To do that, we prefix those types with their length when writing them on
the wire. Map serialization and deserialization now happens inside
Bundle (instead of calling Parcel's readArrayMapInternal() /
writeArrayMapInternal()) and we use an intermediary object - LazyValue -
that holds information about the position and length of the value we
will deserialize when queried.
So, there are basically 3 states:
1. We received the bundle but haven't queried anything about it (not
even isEmpty()): in this case the original parcel is held inside and
we haven't attempted any deserialization (except for the metadata at
the beginning such as the magic, etc)
2. We queried something on it (eg. isEmpty()): Now we deserialize the
bundle skipping the custom values above (we're able to do this now
with the length written on the wire) and instead placing LazyValue
objects for them in the map.
3. We query one of the lazy values: Now, we deserialize the object
represented by LazyValue and replace it on the map.
Since after (2) LazyValue objects are the only ones holding references
to the original Parcel, when all LazyValues are deserialized, the
original Parcel is available for GC.
Inside bundle now we differentiate between unparcel(itemwise = true) and
unparcel(itemwise = false) where the first also deserializes each item
(such that there are no LazyValues in the map). This is because some
operations such as kindofEquals() need all items deserialized.
I had to break a few methods in parcel into multiple methods in parcel
to be able to control the format in bundle. They are all @hide.
* In quick local experiments, counting the bytes that didn't need to be
deserialized after the change. Roughly 10% of bytes from custom-type
items in Bundle are not deserialized in the testing scenario (if I
haven't messed up the stats :). That's on a sdk_gphone_x86_64_arm64 a
few minutes after boot. Check
https://screenshot.googleplex.com/53uXrrqDMYahzg3, stats collection is
on ag/15403076.
Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest
Test: Boot device
Bug: 195622897
Change-Id: Icfe8880cad00c3cd2afcbe4b92400ad4579e680e
- Rename existing SharedMemory.create and make it public
- Passed file is now detached after creating shared memory and is
not usable any more.
Bug: 188780895
CTS-Coverage-Bug: 197226773
Test: atest com.android.car.internal.test.LargeParcelableJavaStableAIDLTest
(runs only in auto. will add matching CTS tests for non-auto devices)
(This combines two CL in internal tree, so Change-Id and Merged-In id are
different)
Change-Id: I8a634062d10ff0c114f3add1d2a5e8056f17b788
Merged-In: I11381e78580b97982b25a52aa06f2192def7353f
