The behavior of proxying through a headless implementation of
the unbundled component was left over from an earlier stage of
the migration ("phase 2" of go/sharesheet-unbundling-phases).
This headless use is no longer supported in the unbundled
component, and it seems that some users are triggering this
code path even when unbundling is disabled -- resulting in
displaying both the "legacy" (system-side) UI and then, when
a share target is selected, the new unbundled UI (which is
no longer "headless").
Bug: 213348070
Change-Id: I146b42e9624d795cfa6689b6a417778ae912d8b5
Test: manual verification of crash fix, atest ChooserActivityTest
We prefetch standalone system server jars in ZygoteInit based on the
STANDALONE_SYSTEMSERVER_JARS environment variable, so that they can take
the advantage of AOT compilation. This CL adds a check to disallow jars
that are not prefetched, which reminds developers to make appropriate
changes so that their jars will be in the environment variable.
Bug: 203198541
Test: 1. Build a system image.
2. The device boots.
Test: 1. Remove an entry from PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS
2. Build a system image.
3. The device does not boot and encounters the following error:
java.lang.RuntimeException: Creating a ClassLoader from /apex/com.android.wifi/javalib/service-wifi.jar is not allowed. Please make sure that the jar is listed in `PRODUCT_APEX_STANDALONE_SYSTEM_SERVER_JARS` in the Makefile and added as a `standalone_contents` of a `systemserverclasspath_fragment` in `Android.bp`.
Change-Id: I275d75ac37194a4d8fd491529b7cdb697dc04e37
This CL applies the SystemUI dialog theme to the Cast dialog. See
b/202264918#comment20 for before/after screenshots.
Bug: 202264918
Test: Manual
Change-Id: Ic20df867177986a6a73617dd9141e4d091651b5b
(cherry picked from commit b8310b0dec)
Merged-In: Ic20df867177986a6a73617dd9141e4d091651b5b
Add safer Bundle APIs that take an extra Class<T> argument that checks
that the type about to be deserialized is a child of the type passed in
parameter *before* actually deserializing it, while also deprecating old
APIs.
This allows use to reap the benefits of the new typed Parcel APIs and
enhances security.
Only the APIs that could involve custom object injection are modified.
So, besides the obvious ones that have that design (eg.
readParcelableList()), subtler cases such as readIntegerArrayList()
could result in custom object deserialization, and since it's all
generics, even the casting inside Bundle wouldn't fail, only after the
client unpacked the list items would it blow up. Now those are checked
beforehand.
Since Bundle always calls Parcel.readValue() under the hood (instead of
specialized APIs such as readParcelable() etc), we had to augment that
method (that's used by LazyValue when retrieving the item) to accept
item types now for containers, which I implemented as a vararg of
Class<?> parameters (this is all private/@hide). This way we could
retrieve a list of intents like readValue(.., List.class, Intent.class),
or a map of string to intents like readValue(.., Map.class,
String.class, Intent.class). For non-container items, we can just pass
no arguments for the vararg. This is explained in internal javadocs.
Inside readValue() now, we also check the container types before
calling the internal methods for deserialization. So, if the thing on
the wire is a VAL_MAP and we know the method we're about to call will
return a HashMap, we verify that the type passed in parameter is a super
type of that (if it's non-null, if it's null it means "perform no
check").
Now, LazyValue became a BiFunction<Class<?>, Class<?>[], Object> to
receive those extra "item types" for containers. The reason for
separating the first from the rest is that the first defines the return
type in the new APIs and inside Parcel, so we need the T from Class<T>
to ensure type-safety.
(I was torn here between using BiFunction or just exposing LazyValue as
@hide for Bundle since it feels like we're missing meaning/abstraction,
but end up leaving this way, advise if you'd prefer the other way)
There was a bit of a refactor in Parcel so readValue() could call
internal methods that accepted nullable Class<?> parameters with the
meaning that null = "no verification" and non-null = "check against
type provided" (because the external APIs all require non-null
parameters).
Now we can return null in all cases when there is a type mismatch. Note
that the Bundle APIs catch ClassCastException to return null, but that
only works for non-generic types (eg. getSizeF()). For generic types
wrapping "return (T) o" with try-catch doesn't work because the type
gets erased to its bound at runtime, so the type mismatch escapes that
try-catch to the caller, potentially causing a crash. Now they happen
inside the getters, as the non-generic ones.
Test: Boots for now
Test: Working on CTS
Test: atest -d android.os.cts.ParcelTest android.os.cts.BundleTest android.os.BundleTest android.os.ParcelTest
CTS-Coverage-Bug: 219980813
Change-Id: Ifcbeb34b4684d7de105756b9d414162a9205ffaa
This is a follow up CL to my previous CL [1], which introduced
InputMethodManager#invalidateInput(View).
One thing I overlooked is that apps may call that API even before
InputMethodManager#mCurrentInputMethodSession,
which results in a NullPointerException.
With this CL, such a case will be gracefully fallen back into
InputMethodManager#restartInput(View)
like other cases when IMM#invalidateInput() is not available.
[1]: I3161755779080f98bcef0e47dd0c5247d8a3a256
daa6695c2e
Fix: 213350732
Test: atest CtsInputMethodTestCases:InputMethodStartInputLifecycleTest
Change-Id: I67458494b3069498a1395e3278f6a975e821e610
When the doze changes, StatusBar#updateDozing will be invoked at the
first frame, usually make the following one be regarded as janky,
but it is unperceptible by the users, so ignore it.
Bug: 201987244
Test: Capture the trace manually
Change-Id: Iac739d23eb0fdc988bd52076bdccca4665e28d18
JankData.PREDICTION_ERROR is asserted when SF vsync calculation
is incorrect and should be attributed to SF missed frames.
Bug: 211763914
Test: SF unit tests
Change-Id: I332480ad1017c220501ed938319f8b2fbfe22826
This is to allow us to collect more representative traces even if one of
the triggers is invoked more frequently than other.
Increased the throttling to be 5min per trigger name
Bug: 213920740
Test: manual - flashed and checked logcat
Change-Id: I078c640cc1e72c4ce8641b047fc90eb13bc8f2a4
When rotation happened during a change of screen (e.g. on foldable devices), getRotationLockOrientation was blocked by a wm binder call to get the display size. wm was holding the lock while changing display power state. This cl removes this dependency.
Bug: 197515205
Test: Manual
Change-Id: I950e80289ea0f385bcaedf052d393ac7a23a14c6
There is a "race condition" where a MessagingGroup is recycled while the
contents of that group are being used elsewhere in the
ConversationLayout, namely in the "image message container" used to show
the most recent image message in the collapsed state.
This state isn't cleared until later in the bind() process, which
unfortunately depends on the groups being updated. For that reason, we
defer all synchronous calls to recycle() until the end of bind(), which
will ensure that the old groups are still around as long as necessary.
Fixes: 212689920
Test: manual
Change-Id: Idef815d54690544615512bd2bd1006f172403e18
getUsbDataStatus now returns bit field values of @UsbDataStatus.
Also renaming from USB_DATA_STATUS_* to DATA_STATUS_* based on
review comments.
Bug: 216640242
Signed-off-by: Badhri Jagan Sridharan <badhri@google.com>
Change-Id: I96ade3dd7041a4094e57907069a872909a62e72f
The bug was found and fixed in
android.car.util.concurrent.AndroidFuture. The same fix is being
duplicated from commit 9dcaf6862035676b2574e92cb72cba67ff0a879b.
Bug: 218377773
Test: atest com.android.internal.infra.AndroidFutureTest
Change-Id: I1e13d512a449a7330c74ed06f6afd90e3c4f9493
- Fix handle of special args (they were not called unless the app
targeted T).
- Lazy-adds some dumpables to Activity (so the list of dumpables
is not created until dump() is called).
Test: adb shell am start com.android.settings && adb shell dumpsys activity com.android.settings --list-dumpables
Test: atest CtsAppTestCases:android.app.cts.ActivityDumpTest
Bug: 149254050
Change-Id: Id25d115d4aef8ab16ceb3d035c134c637e16dadd
When setting flags/sysprops, full reboot is overkill.
This adds a way to just restart system_server.
Bug: 219067621
Test: Call API and verify that it restarts
Change-Id: I67aecbc6ec0570fbaf36165034648ab39da57940
media devices from external clients.
Bug: 216313420
Test: CTS included in same topic
Test: atest NearbyMediaDevicesManagerTest
Change-Id: Ic5f26d3048a3475dbd232c913bb00bee46339b0a
Revert submission 16791148-chooseractivity-queryresolver
Reason for revert: b/218994001
Reverted Changes:
I91bbd3971:Query only necessary columns in ChooserActivity.ex...
I2ab9c6f03:Query only necessary columns in ChooserActivity.ex...
Fixes: 16850551
Change-Id: Idbc6270bb0dc1f2402c44d111bdcebe8a25f28c2
This increases the size of the default user icon to 190dp.
A new method convertToBitmapAtUserIconSize is added to UserIcons to
allow bitmaps of this size to be easily obtained. The existing
method convertToBitmap uses the intrinsic size of the drawable, which
is only 48dp as standard.
Bug: 218838295
Test: visual inspection of user icon for owner and new users
Test: atest UserIconsTest
Change-Id: I5cbf110731f4c944bb1d3af63b5a0fcb5ab50f16
