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
As getSubDeviceSummy, we should check the memberDevices's size and
decide if the secondarySummary need to be shown.
Bug: 201491295
Bug: 150670922
Test: pair with the A2DP/HFP headset, and check the summary
Change-Id: I8bb0744067733c6e17292d6c7be1c3f110d731e3
Round 2: ag/15616233
Round 1: aosp/1702009
Even with increased timeouts, testNativeCrash is not always able to get
the tombstone of the crashed native app. This is because the tombstone
timestamp can be more than 1000ms before the ApplicationExitInfo,
causing them to not match. See b/191798394 for more details.
This CL increases the maximum timestamp difference to ensure that the
tombstone (almost?) always matches.
Bug: 192299487
Test: atest android.app.cts.ActivityManagerAppExitInfoTest
Change-Id: Ideeb93dbcb40ce9d564f159fe1f7574554c09a40
The "Lost network stack" message often gets reported as suspected
root cause of a crash, but it is actually just a side-effect of a crash
of the network_stack process, which often was just killed together with
the rest of the system.
Clarify the error message, so that it is clear that the root cause
should be visible earlier in logs.
Bug: 198681439
Change-Id: Ieb79ace34170f8bd9ea847175199590998278d57
Test: m
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: Ibaacc27a125a31e18d4b5889d05d12cc18d05624
When we use GPU to copy the data, rendering would choose filter. But we need add shrink in border to ensure the sampler not reach border like what GUI does.
Change-Id: I2c59956f3d7a7052d8e4bee587360f252a6c5549
Signed-off-by: Chun Jiang <chun.jiang@mediatek.com>
Bug: 197180327
Test: CTS PixelCopyTests & DecodeAccuracyTest
* Bundle supports types char, char[], short[], float[] which were
falling back to serializable handling in Parcel because readValue()
didn't have specific support for those types. Adding support in Parcel
to avoid the need for length-prefixing and to improve performance.
Curiously some of those had read/write methods already.
* Updated Bundle to just pull the types above from the map since those
won't be lazy values anymore.
* We were missing a few custom type containers in our list of
length-prefixed types and we were listing Bundle unnecessarily as
length-prefixed since Bundle itself is already length-prefixed and
copies the correspondent section of the parcel internally.
Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest
Bug: 195622897
Change-Id: I1e15d59d883311685ffa32ece1f5a00e01bf6aea
Description:
Added replacements of `readList`, `readParcelable` and
`readParcelableCreator` APIs.
To avoid unexpected types of objects being unparcelled,
ideally clients would use the readTypedXXX() methods that
take the parcelable creator. However, this won’t be an option
for use cases involving deserializing children objects
inherited from non-final parcelable or serializable objects.
Currently out of ~4k parcelable classes, only ~1.5k
are marked as “final” in the platform. Hence it would be
necessary to introduce new replacements that take
an extra Class<T> parameter and before deserializing
we check that the class written on the wire is the
same or a descendant from the one provided as argument.
Doing so could enhance the security of Parcel deserialization,
More details can be found at go/safer-parcel.
Test: atest -d android.os.cts.ParcelTest
Bug: 195622897
Change-Id: Ie9a4cb4c3d6f1805b14df7b703aef43e2993d459
So that the API more closely matches intended usage, as requested.
Bug: 175814583
Test: aidl_integration_test
Change-Id: I2fb5f2d5059d7f9cd9e034a4d0d2e7aa63692067
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
[Description]
revert part of solution in
55bc36d33c
On Android R, TV's power status is TRANSIENT_TO_STANDBY
by default, in this case, device information related actions
should be started as well, that's why we allow
SystemAudioAutoInitiationAction and NewDeviceAction to be started
When TV boot up, SystemAudioAutoInitiationAction
is not started if power statusof HdmiControlService is not ON
This happens if onNewAvrAdded is called before
SystemService.PHASE_BOOT_COMPLETED
Bug: 194429425
Test:
Build PASS
Boot with ARC device plugged PASS
Change-Id: I79cd1d4f5a180a052be49df186505e579f7d1339
Ensures that all queued actions on local devices are started after
boot. Previously, an unstarted SendKeyAction could stick around after
boot, blocking any future SendKeyAction from being created.
Unit tests omitted because of AOSP incompatibilities.
Bug: 193188675
Test: atest HdmiControlServiceTest#normalBoot_queuedActionsStartedAfterBoot
manual test: spam volume up on boot with IR volume control enabled
Change-Id: I0050ca927bdba939b0b0030a6aa2f6235b11ff5c
Merged-In: I0050ca927bdba939b0b0030a6aa2f6235b11ff5c
(cherry picked from commit 22dc89a89f)
