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
After we hit the per-UID proxy limit and kill the originating process,
there's actually no guarantee that the proxies to the (now dead)
processes are cleaned up immediately; if the processes get restarted and
start accumulating proxies again, we may go over the global proxy limit
(25k with this CL). Do a GC to make sure we clean them up.
Note that the GC here might not actually clean up all the proxies,
because the binder reference decrements will come in asynchronously; but
if new processes belonging to the UID keep adding proxies, we will get
another callback here, and run the GC again - this time cleaning up the
old proxies. Because of this potential delay, an app may temporarily
have many more outstanding proxies than the high watermark, so also
increase the global proxy limit to 25k proxies.
Bug: 198340142
Test: Manual
Change-Id: I75c7ea4f7aa4a5d448f610014770f1b9788cfb5b
Merged-In: I75c7ea4f7aa4a5d448f610014770f1b9788cfb5b
This fixes a race condition that exists around preparing CE storage, and
a package being reinstalled at the same time.
The normal CE data unlock procedure is something like this:
1. User state is RUNNING_LOCKED
2. UserController calls onBeforeUnlockUser()
3. onBeforeUnlockUser() prepares CE storage
4. onBeforeUnlockUser() calls PackageManagerService.reconcileAppsData()
5. reconcileAppsData() prepares app CE data directories, creating dirs
when needed
6. UserController changes state to RUNNING_UNLOCKING
The race comes into the picture when an app is installed right between
step 5 and step 6; when a new app is installed, PMS does have a function
to create the CE app data directory; but that function only creates CE
data directories when the user state is RUNNING_UNLOCKING (or later); so
even though technically CE storage became available in step 3, other
parts of PMS will only use it after step 6 has completed.
To fix this, we use StorageManagerService to record the fact that CE
storage for a particular user is prepared; then, PackageManagerService
can query StorageManager to ask whether CE storage is prepared. That in
combination with the user key being unlocked is then used as a condition
for creating CE data directories from PackageManagerService.
Bug: 187103629
Test: manual
Change-Id: Ice81ae98441b9ed287e8db4196a041c3d47afce9
Merged-In: Ice81ae98441b9ed287e8db4196a041c3d47afce9
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
If the lists of custom power components do not match, a crash will occur.
Instead of causing a crash, simply skip incompatible snapshots.
Bug: 196040329
Bug: 200511361
Test: atest FrameworksCoreTests:com.android.internal.os.BatteryUsageStatsProviderTest
Change-Id: I87ba605371a5f3119dcff33f6109e94ee46ab57d
(cherry picked from commit a1ea9ecd56)
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
Enable ANGLE as a Game Dashboard intervention via Phenotype.
Bug: b/188475576
Test: GameManagerServiceTests
Change-Id: I91894a76b8dcf7a97244cff679a501001734f671
Merged-In: I91894a76b8dcf7a97244cff679a501001734f671
(cherry picked from commit acf3851b8f)
