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
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
Implement lazy deserialization for custom types in bundle:
* Parcelable (VAL_PARCELABLE)
* Serializable (VAL_SERIALIZABLE)
* Parcelable array (VAL_PARCELABLEARRAY)
* Lists (VAL_LIST)
* Sparse array (VAL_SPARSEARRAY)
* Bundle (VAL_BUNDLE)
This enhances security, makes bundles more robust to deserialization
errors and avoid deserializing unneeded objects in some cases*, for more
details check go/lazy-bundle.
To do that, we prefix those types with their length when writing them on
the wire. Map serialization and deserialization now happens inside
Bundle (instead of calling Parcel's readArrayMapInternal() /
writeArrayMapInternal()) and we use an intermediary object - LazyValue -
that holds information about the position and length of the value we
will deserialize when queried.
So, there are basically 3 states:
1. We received the bundle but haven't queried anything about it (not
even isEmpty()): in this case the original parcel is held inside and
we haven't attempted any deserialization (except for the metadata at
the beginning such as the magic, etc)
2. We queried something on it (eg. isEmpty()): Now we deserialize the
bundle skipping the custom values above (we're able to do this now
with the length written on the wire) and instead placing LazyValue
objects for them in the map.
3. We query one of the lazy values: Now, we deserialize the object
represented by LazyValue and replace it on the map.
Since after (2) LazyValue objects are the only ones holding references
to the original Parcel, when all LazyValues are deserialized, the
original Parcel is available for GC.
Inside bundle now we differentiate between unparcel(itemwise = true) and
unparcel(itemwise = false) where the first also deserializes each item
(such that there are no LazyValues in the map). This is because some
operations such as kindofEquals() need all items deserialized.
I had to break a few methods in parcel into multiple methods in parcel
to be able to control the format in bundle. They are all @hide.
* In quick local experiments, counting the bytes that didn't need to be
deserialized after the change. Roughly 10% of bytes from custom-type
items in Bundle are not deserialized in the testing scenario (if I
haven't messed up the stats :). That's on a sdk_gphone_x86_64_arm64 a
few minutes after boot. Check
https://screenshot.googleplex.com/53uXrrqDMYahzg3, stats collection is
on ag/15403076.
Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest
Test: Boot device
Bug: 195622897
Change-Id: Icfe8880cad00c3cd2afcbe4b92400ad4579e680e
- Rename existing SharedMemory.create and make it public
- Passed file is now detached after creating shared memory and is
not usable any more.
Bug: 188780895
CTS-Coverage-Bug: 197226773
Test: atest com.android.car.internal.test.LargeParcelableJavaStableAIDLTest
(runs only in auto. will add matching CTS tests for non-auto devices)
(This combines two CL in internal tree, so Change-Id and Merged-In id are
different)
Change-Id: I8a634062d10ff0c114f3add1d2a5e8056f17b788
Merged-In: I11381e78580b97982b25a52aa06f2192def7353f
The functionality is similar with fetchUuidsWithSdp which uses TRANSPORT_AUTO. Bt stack depends on the devie type and address type to do sdp or gatt service discovery. Add an api to specific the transport. It would be fexible to handle the dual mode device.
Tag: #feature
Bug: 197195548
Test: atest BluetoothInstrumentationTests
Test: Take two headphone to test the dual mode behavior
Change-Id: I32c8dde68969e0bdc42e4e898c43a4f2c1d3379a
Merged-In: I32c8dde68969e0bdc42e4e898c43a4f2c1d3379a
There are three reference type members in UsageStats's constructor, when using "new UsageStats(stats)" to copy, it will be a Shallow Copy, which may cause concurrent modify problem.
For example, in UserUsageStatsService.java, the sUsageStatsCombiner is using "new UsageStats(stats.packageStats.valueAt(i)" to copy, and the value is passing to the computeCacheQuotaHints in
CacheQuotaStrategy.java. If we change the UsageStats.mForegroundServices at the same time, IndexOutOfBounds Exception will happen.
Therefore, it is necessary to modify the way of copying of the UsageStats.
Signed-off-by: zhuyunyi <zhuyunyi@xiaomi.com>
Change-Id: I58a54d17aad6ef5213e52658ee3387f3069339af
For now AIDL doesn't support Map<String,Integer>, there's no way to fix
it with typed map.
Bug: 192615532
Test: m
Change-Id: Id0011372a0997b4ab9aa700a7c4f8746bff29189
For experiment flag testing, adding lmkd flag in DeviceConfig.
Bug: 194316048
Signed-off-by: Suren Baghdasaryan <surenb@google.com>
Change-Id: I1f13d6bbb4a9a7fd8825d7e5acde416750271df4
Merged-In: I1f13d6bbb4a9a7fd8825d7e5acde416750271df4
GZIPInputStream has a bug (b/195554062) where it uses unbuffered IO
when reading the gzip header. This triggers the UnbufferedIoViolation
strict mode violation for apps that target API level 28+.
Independently of fixing GZIPInputStream, DropBoxManager can use
BufferedInputStream to take a proactive step against this and future
bugs.
Bug: 195554712
Test: Successfully read gzip dropbox entries from API level 28+ app.
Change-Id: Id539efcb366b3e3d53513a098975b25866ed16ff
Map is not supported in C++ backend. To compile IAdbManager in C++,
Map is translated into a list of key, value tuples.
Test: pass
Bug: 194829333
Change-Id: I92e3ad29e8a2bfbab3756d2ef5a2db76ba3cc3d9
PacProxyInstaller had been renamed to PacProxyService
so any comments that refer to it should be updated
accordingly.
Bug: 194984075
Test: refine comments only
Change-Id: I5d8ed07e804471cfcbcc80eca908b18f6557cf79
RandomAccessFile#length returns 0 for block devices while
FileChannel#size returns the correct size.
APK signature verification utils should work with block-device zip files
when Android is running as a guest OS and APK/APEX files are passed via
block devices.
This is a follow-up of 1257f1505c.
Bug: 193592496
Bug: 192366904
Test: FrameworksServicesTests
Merged-In: I3015fc30574c36c18c0d0c9ae7453d33a1349927
Change-Id: I3015fc30574c36c18c0d0c9ae7453d33a1349927
(cherry picked from commit 310edbe3c7)
Legacy VPN is deprecated starting from Android S. So this API
shouldn't be called if the initial SDK version of device is
Android S+. Otherwise, UnsupportedOperationException will be
thrown.
Bug: 189808606
Test: 1. make gts && gts-tradefed
2. run gts --module GtsNetworkStackHostTestCases
Change-Id: I00f49555bbbc8ccf270056f0e4d1bfdd927ef26d
Merged-In: I00f49555bbbc8ccf270056f0e4d1bfdd927ef26d
Starting in R, some methods in ConnectivityManager like
getNetworkCapabilities started passing the package name from
the context stored in CM to check that the package is really
whom it pretends to be. Unfortunately, in some cases, the
context contains package "android" for an app, and since the
app is not the system, the check fails and crashes the app.
It seems the culprit is updateHttpProxy, which is called by
ProcessList when the PROXY_CHANGE_ACTION broadcast is sent.
If this happens to run between the time the process is created
and the activity thread is "bound", then the mInitialApplication
member is not set, and updateHttpProxy uses a system context.
Since ConnectivityManager caches the context forever in a
static, this leads to subsequent legitimate calls crashing.
Setting the proxy can be deffered until such a time that the
app is bound, as it can't run any code before then. The member
is never reset to null, so it's guaranteed to be non-null at
bind time.
An alternative would be to post a runnable on the handler
thread if the member is null to try again later. This
could however run the lambda a considerable number of times
as binding can be delayed, and risks causing an infinite loop
if some invariants are changed in the future.
See also b/73572062 and ag/4056059
Bug: 155549446
Bug: 189360509
Test: ActivityThreadTest FrameworksNetTests NetworkStackTests
Test: Manually set a proxy, observe the broadcast being sent and
apps not crashing
Change-Id: I956f76be2e0a1a675576511fb394d7ed4354b28a
Merged-In: I956f76be2e0a1a675576511fb394d7ed4354b28a
