This method clears the calling identity of a kernel
binder call. However, there is now a generic API to
disallow the use of kernel binder calling identities.
This is used by RPC binder calls in order to ensure
that code doesn't accidentally assume the default
(<pid>, <uid>) calling identity means that the call
originated from another process.
In the C++ layer, this API is attached to
IPCThreadState. In the future, we could consider
expanding the scope of this API to code and restore
many types of calling IDs, but the current return
type may not have enough space, and I want to
push people away from thread locals (globals)
for now.
Bug: 237245600
Test: N/A
Change-Id: I6e293814769cbd3c41e72afd95385af31ceb099f
Upon deserialization, various APIs would check that the passed in class
was assignable from the creator's enclosing class - which was assumed to
always be the Parcelable type.
This assumption is not always true, so updating the check to explicitely
store the parcelable type
Fix: 232589966
Test: m && atest ParcelTest && atest BundleTest
Change-Id: I59b650a854944e9020615a65798c5e54f5540aaa
Detect recycle called twice always (and when DEBUG_RECYCLE is on, we
detect recycle called twice or called zero times, and we show a stack).
Bug: 231799394
Test: manual (calling recycle twice)
Change-Id: I1dd9f392ee916edd9c598085a1c19dbdd3ce957f
Merged-In: I1dd9f392ee916edd9c598085a1c19dbdd3ce957f
Follow up to ag/18795008. Adding tests for new behaviour.
As it is not possible to directly check on the bundle if the parcel has been recycled,
we inject a spy into it. Mocking static methods is not possible in
FrameworkCoreTests, so we introduce a new test class in
FrameworksMockingCoreTests which is run when any parcel or bundle source
file changes.
Bug: 233216232
Test: atest BundleRecyclingTest
Change-Id: If691b68a8db1f0110d131ec620935f566cc9367b
Add clarification that this flag can only be applied by privileged apps, and will be ignored otherwise.
Bug: 236932598
Change-Id: I78db484b9d479abed67689c827707b6f141b2c00
Test: N/A
Detect recycle called twice always (and when DEBUG_RECYCLE is on, we
detect recycle called twice or called zero times, and we show a stack).
Bug: 231799394
Test: manual (calling recycle twice)
Change-Id: I1dd9f392ee916edd9c598085a1c19dbdd3ce957f
This CL updates the configuration handling for USAP system properties.
Test: Build; flash; set property; check device state
Bug: 161725679
Change-Id: Ia1f6c4f4f7b8798d9c906953629bed61ce618f54
Lazy Bundles, (aosp/1787847), introduced a change in behavior where a Parcel
created as part of initializing a Bundle is dependent on the next ART GC run to be
recycled, causing a short term memory-leak.
To land this in T, we are making the change targetted and allowing
consumers to opt into the parcel being immediately cleared by calling
.clear() on the bundle.
As part of the unparcel() in clear(), mParcelledData is set to null, and
mMap may or may not still contain references through lazy values,
depending on if the lazy valyes have been unmarshalled. As
such, we keep a weak reference to mParcelledData we can use to recycle it.
The mParcelledData reference could have been copied to other bundles in
a few operations:
new Bundle(Bundle o)
bundle.deepCopy()
bundle.putAll()
In this case we can not recycle the parcel yet as other bundles may
still require it. If so, we will skip the recycle and rely on the later GC pass
Bug: 233216232
Test: Reproduced linked bug on-device
Test: atest android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest
Change-Id: Ic26eceaa1c11da67866af0963f760423d41d54bc
Merged-In: Ic26eceaa1c11da67866af0963f760423d41d54bc
Lazy Bundles, (aosp/1787847), introduced a change in behavior where a Parcel
created as part of initializing a Bundle is dependent on the next ART GC run to be
recycled, causing a short term memory-leak.
To land this in T, we are making the change targetted and allowing
consumers to opt into the parcel being immediately cleared by calling
.clear() on the bundle.
As part of the unparcel() in clear(), mParcelledData is set to null, and
mMap may or may not still contain references through lazy values,
depending on if the lazy valyes have been unmarshalled. As
such, we keep a weak reference to mParcelledData we can use to recycle it.
The mParcelledData reference could have been copied to other bundles in
a few operations:
new Bundle(Bundle o)
bundle.deepCopy()
bundle.putAll()
In this case we can not recycle the parcel yet as other bundles may
still require it. If so, we will skip the recycle and rely on the later GC pass
Bug: 233216232
Test: Reproduced linked bug on-device
Test: atest android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest
Change-Id: Ic26eceaa1c11da67866af0963f760423d41d54bc
Comment a warning for this hack to add data into statuses. I've also
heard from jsharkey@ in the past a need for a generic solution here.
At a minimum, this prevents new bugs/bad interactions with native
code.
Bug: 235006086
Test: N/A
Change-Id: I3bcb2b8638803cde0f6ef257b65bb9456843abf7
ID attestation will not work if the device identifiers are altered in
the system image. This is because KeyMint checks the device identifiers
that are provided in a generateKey call against the device identifiers
that were provisioned in the factory. If there is a mismatch, the key
request is rejected. The documentation on getSerial() has been fixed to
clarify this.
Test: The new documentation is semantically digestible by a SWE
Change-Id: Ie300cd167bb82b44e38fb3e091b90abe02a7c197
Emulated FBE was a developer-mode feature intended to allow developers
to add Direct Boot support to apps before native FBE devices became
widely available. Since all devices running the latest version of
Android now use native FBE (except for a couple edge cases not relevant
here, like in-development devices on which encryption hasn't been
enabled yet), and emulated FBE doesn't work on native FBE devices
anyway, there's no longer any need to carry the code for emulated FBE.
Bug: 232458753
Change-Id: I2ab35472c872b19b2bf64aa99424b5ccd9f6170f
The flag should be propagated to Parcelable.writeToParcel(). But since
it was hidden, we were not able to pass the flag to elements of the
list.
Bug: 215654054
Test: atest android.os.cts.ParcelTest
Change-Id: I72d419caa74c62d979c5102ebd8eba4338ec3e3b
