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
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
Expose the binderDied() variant that supplies the IBinder that has
become invalid.
Bug: 207163286
CTS-Coverage-Bug: 214327236
Test: atest BinderDeathDispatcherTest
Change-Id: I7193e29287dcc5c2a6447514c84840eca8adf61f
Now that these methods are no longer called, and none of them are a
public API or have @UnsupportedAppUsage, they can be removed.
inCryptKeeperBounce() actually had one known app user via reflection,
despite the method not having @UnsupportedAppUsage. However, that user
only made the call if Build.VERSION.SDK_INT < VERSION_CODES.P, so it is
not being used anymore.
Bug: 208476087
Change-Id: Idc218e5f355bb61257b07cf5b5b6df5f4c6ece11
Log a specialized error message if installation task
failed due to insufficient storage space.
This helps the user to disgnose the source of error.
Bug: 200002443
Test: start DSU task and check logcat
Change-Id: Iabb3e0325ae99c343978ca6c35ab8378f20e0527
Reference to createFixedArray shoudl be escaped. Otherwise resulting
html renders as <s>(strikethrough) tag.
Bug: 227007069
Test: m online-sdk-docs
and see if ./reference/android/os/Parcel.html works ok
Change-Id: I7a3b447cbeddd8d66ca1733dc8d115c61ece2509
IVold.ENCRYPTION_STATE_* and IVold.PASSWORD_TYPE_* are values returned
by or accepted by FDE-specific vold methods, which are no longer used.
Stop using these constants so that we can remove them from IVold.aidl.
Notes on specific constants:
- Some constants have @UnsupportedAppUsage. There is no reason why a
non-system app should have been using these. However, to avoid
possibly breaking apps I just left these with hardcoded values.
- StorageManager.CRYPT_TYPE_* are used by
LockscreenCredential.getStorageCryptType(). However, the caller of
this method was removed by an earlier CL, so just remove this method.
- StorageManager.CRYPT_TYPE_* also have a user in
packages/apps/Settings, but it is obsolete code that I'm removing in
another CL.
Bug: 208476087
Change-Id: I41c684b69a97dbafac65d8f55db2c284d7a8dd70
Devices that launched with Android 10 or later require FBE (File Based
Encryption) from the beginning, so there's no need to support converting
to FBE after the fact anymore. This was only ever a developer option,
so it probably wasn't used much. And in any case, it's not used
anymore, as isConvertibleToFBE() is hard-coded to return false. Besides
the fact that FBE has been required for several releases now, this
functionality was only ever available on devices that use FDE (Full Disk
Encryption), but FDE support has been removed from Android.
Therefore, remove this unused code.
Bug: 208476087
Change-Id: I1f56c8e05fb3fba09aab4bf5f8609b0f552b8999
* changes:
Remove HardwareAuthToken parameter from unlockUserKey
Remove HardwareAuthToken parameter from clearUserKeyAuth
Remove HardwareAuthToken parameter from addUserKeyAuth
Don't pass HardwareAuthToken to unlockUser() in non-SP verifyCredential
Remove non-SP based setLockCredentialInternal()
Remove HardwareAuthToken support from FakeStorageManager
Due to the migration to synthetic passwords, the 'token' parameter to
unlockUserKey() is no longer needed. Remove it.
Note: I didn't change unlockUser() in IActivityManager because it is
marked with UnsupportedAppUsage, so it might not be safe to change the
method signature. It now just ignores the 'token' parameter rather than
passing it down the stack.
Test: atest com.android.server.locksettings
Bug: 184723544
Change-Id: I35ce09412f47f2f2a17a371d518a0a518b70bfb6
(cherry picked from commit b1bcec9c7d)
Merged-In: I35ce09412f47f2f2a17a371d518a0a518b70bfb6
Due to the migration to synthetic passwords, the 'token' parameter to
clearUserKeyAuth() is no longer needed. Remove it.
Test: atest com.android.server.locksettings
Bug: 184723544
Change-Id: I739b519b0e91293acbf018020891d68b3090c175
(cherry picked from commit 2a8ab47782)
Merged-In: I739b519b0e91293acbf018020891d68b3090c175
Due to the migration to synthetic passwords, the 'token' parameter to
addUserKeyAuth() is no longer needed. Remove it.
Test: atest com.android.server.locksettings
Bug: 184723544
Change-Id: I06e7c36787cc7f384acb7742737c3b1cfa50f0ae
(cherry picked from commit 6b220a95e9)
Merged-In: I06e7c36787cc7f384acb7742737c3b1cfa50f0ae
Now that FDE is no longer supported, remove the FDE-related methods from
StorageManager that are no longer called.
Bug: 208476087
Change-Id: Ic24a5b029bdf51dec622d1b70cef9ef26c3d54c5
(cherry picked from commit 41fa601601)
Merged-In: Ic24a5b029bdf51dec622d1b70cef9ef26c3d54c5
The interface a ParcelableHolder is in determines its stability,
and it shouldn't change based on what is sent.
Bug: 215458170
Test: aidl_integration_test
Change-Id: I40239e14e59b3998ac19d140453eb29a298cdb76
These are processes that are spawned alongside regular app processes.
They have their own UID range, such that they can be properly isolated
from applications.
Add some APIs in Process that allows the system and mainline
modules to verify that a particular UID belongs to a sandbox
process, and to map between the sandbox process and the
corresponding app process.
Bug: 215012578
Test: N/A
Change-Id: I02aaaa1c2bcf9d141ddc97747eb6d7edd52d7b92
Merged-In: I02aaaa1c2bcf9d141ddc97747eb6d7edd52d7b92
* changes:
Stub out some FDE methods in StorageManager
Stop trying to update FDE password from LockSettingsService
Remove clearEncryptionPassword() from LockPatternUtils
Stop trying to get/set fields in FDE footer
Now that FDE is no longer supported, stub out some methods in
StorageManager that return FDE state. This allows
StorageManager.getPasswordType() to be removed, and it prepares for
removing these methods later.
Bug: 208476087
Change-Id: Ib5bcfb6a0279150fec33f2c3edd0431b450c90f4
(cherry picked from commit 401bf8a176)
Merged-In: Ib5bcfb6a0279150fec33f2c3edd0431b450c90f4
Mounting encrypted OBB files has never worked reliably across devices,
partly due to its reliance on Twofish encryption support in the kernel.
This is because Twofish support (CONFIG_CRYPTO_TWOFISH) has never been
required or even recommended for Android. It has never been enabled in
GKI, but even before GKI it wasn't required or recommended. Moreover,
this is now the only Android feature that still uses dm-crypt
(CONFIG_DM_CRYPT), and some devices don't have that enabled either.
Therefore, it appears that this feature is unused. That's perhaps not
surprising, considering that the documentation for OBBs
(https://developer.android.com/google/play/expansion-files) says that
they are deprecated, and also it explains OBBs as being app files that
are opaque to the platform; the ability of the platform to mount OBBs
that happen to be in a particular format is never mentioned. That means
that OBB mounting is probably rarely used even with unencrypted OBBs.
Finally, the usefulness of OBBs having their own encryption layer (in
addition to what the platform already provides via FBE) is not clear
either, especially with such an unusual choice of cipher.
To avoid the confusion that is being caused by having the broken code
for mounting encrypted OBBs still sitting around, let's remove it.
Test: atest StorageManagerTest # on Cuttlefish
Test: atest StorageManagerIntegrationTest # on Cuttlefish
Bug: 216475849
Change-Id: I6e6a6462ab8343299dc5e0145b87dc28b16b0bc1
