This fixes the contract between equals and hashCode in
AndroidKeystorePublicKey. The previous fix made only a reference
comparisson between certificate blobs. In this patch java.util.Arrays is
used to compare and compute the hash of the array.
Bug: 196118021
Test: See following CL.
Change-Id: I2b8b7e740fb377de39fd21f763e15cb00024b2fc
Fix a NullPointerException when trying to insert SecretKey that already
exists.
Bug: 202146009
Test: atest android.keystore.cts.AndroidKeyStoreTest#testKeyStore_SetKeyEntry_ReplacedWithSameGeneratedSecretKey
Change-Id: If3a4bd6677ab3173c5c1a7c921ba567b7981662b
Soong having OWNERS in frameworks/base is useful to enable LSCs;
however, they shouldn't appear in review suggestions except as a
fallback.
Test: n/a
Change-Id: I86618b66e51893908478def9fc455a3dfde146f0
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
