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
Context.getDataDir() for SDK sandbox incorrectly returns /data volume
path even if the actual storage is on another volume. This CL sets the
correct storage path by checking the uuid from the ApplicationInfo of
the client app and setting it to the same value.
Bug: 229736419
Test: atest
SdkSandboxStorageHostTest#testSdkSharedStorage_DifferentVolumeIsUsable
Change-Id: Ib72ea559363cdeb4b7cfcc2f48ca8ddace96e352
Merged-In: Ib72ea559363cdeb4b7cfcc2f48ca8ddace96e352
Add a method PowerManagerInternal.getLastGoToSleep(), similar to
existing method getLastWakeup(), to retrieve global values for last go
to sleep events, including system uptime and reason.
Retrieve this data in VibratorManagerService before cancelling ongoing
vibrations by the broadcast of ACTION_SCREEN_OFF intents to indicate
that the screen was turned of when the vibration was still playing. This
new logic allows vibrations to continue in the following cases:
- the broadcasted event was triggered before the vibration started;
- there is already a wakeup event triggered by the time the screen off
broadcast is being processed by the vibrator service;
- the screen off reason is in allowlist, indicating it's an
automatically triggered event (screen timeout or user inattentive);
This should handle the following scenarios:
- delayed broadcasts of screen off events, that should not cancel
vibrations that started when the screen was already off (e.g.
notification or ringtone that are allowed to vibrate in that state);
- race conditions when the screen automatically turns off right after a
ringtone/notification vibration starts, before the notification
acquires a screen lock;
Fix: 219849350
Test: VibrationSettingsTest
Change-Id: I358327192196989a7d4fc49a96b2ab92ec677302
Expose the binderDied() variant that supplies the IBinder that has
become invalid.
Bug: 207163286
CTS-Coverage-Bug: 214327236
Test: atest BinderDeathDispatcherTest
Change-Id: I7193e29287dcc5c2a6447514c84840eca8adf61f
A user can be created with an explicitly null name, as happens in tests.
But getUserName claims to never return null. So we must do a null-check
here to prevent it.
Bug: 227624966
Test: atest UserManagerTest
Change-Id: Iea0e7b6292c6dd49df1bebc5467091a82ddaedb5
For multiple log access requests from the same client
(same UID + package name) within a short timeframe, show only one
confirmation prompt to the user.
When access has been approved/denied, further requests will
automatically be approved/denied until another timeout expires, after
which a new request will show a prompt again.
If the prompt is shown but the request isn't approved or denied within a
certain time, the client will automatically be denied access.
Moved the approve/decline methods out of ILogcatManagerService into a
local service, so that they can only be called from within the system
server.
Bug: 229976778
Test: atest FrameworksServicesTests:LogcatManagerServiceTest
Change-Id: I6a3f56bdcbb84e64b1b24e73476bd24f32b75f24
Currently, sandbox cannot call any apis from StorageManager that checks
calling package has same uid as calling uid. This CL fixes that by using
pm.isSameApp() api.
Additionally, since Environment.java fetches the initial application
context, the uid for that does not fall under the sandbox uid range. It
falls under app uid range. We fix the problem by checking for
PROPERTY_NO_APP_DATA_STORAGE flag on the application.
Bug: 228424287
Test: atest CtsSdkSandboxInprocessTests (see ag/17657742)
Change-Id: I8d9fca369cfbed47b40a42a44a40ff73acb712ec
