Adds the chevron when it's not casting and we expect to open a dialog
Test: manual
Test: atest CastTileTest
Fixes: 191154648
Change-Id: Ib3e70d3c8dbc797fd85a6781743270ed4abc7e63
Merged-In: Ib3e70d3c8dbc797fd85a6781743270ed4abc7e63
(cherry picked from commit 9dd955bd0c)
Keep new test changes isolated to the new test to avoid disruption
to the existing tests
Fixes: 196295234
Test: atest KeyguardViewMediatorTest
Change-Id: Ia7706ce8b3923c1bf4fccd3f15edf97c60893472
(cherry picked from commit d4f5bde12f)
shouldRestoreImeVisibility(token) used to check if the task window
token should restore IME visibliity by checking the tasksnapshot.
Previously by default it calls mAtmService.getTaskSnapshot() to load
tasksnapshot from the disk if the does not exist, which caused
additional bitmap allocation to see if the tasksnapshot is not active.
Since we only check the IME surface from the tasksnapshot when
the task is still running. Also, after the next booted, tapping
the tasksnapshot from the overview will be refreshed with
splashscreen that we don't trying to restore IME visiblity
for that case.
Use WMS#getTaskSnapshot with specifying restoreFromDisk parameter as
false to get the active tasksnapshot from memory.
Fix: 195347355
Test: Enable systrace on device from developer option,
launch an App with showing IME, swiping up to the overview
and then tapping the original task again, expect no
additional EGLContext created in the systrace.
Change-Id: I0abb5d6d77fdb200c737e7582923ced9ee98ad05
From code flow, when onConfigurationChanged() by rotating
OneHandedBackgroundPanelOrganizer#showBackgroundPanelLayer()
will be invoked and then create one-handed-background-panel
even though OHM is not activated.
Besides, this could introduce overhead on SF.
Test: manual rotate and dumpsys check HWC layers
Test: atest WMShellUnitTests
Bug: 196306312
Change-Id: Ia766078d5c76b08ab5b24e0ce965ad1d085e4686
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
renamed to avoid conflict with existing copy in the R framework.jar.
The framework.jar copy was removed during S development
Bug: 195608856
Test: build
Test: cts-tradefed run cts -m CtsMediaTranscodingTestCases
Change-Id: I40ab066cd61be8d278f21cc788016f2edd6bb86e
Problem: Framework Reboot i.e., NullPointer Exception in android.ui Thread
E AndroidRuntime: FATAL EXCEPTION IN SYSTEM PROCESS: android.ui
E AndroidRuntime: java.lang.NullPointerException: Attempt to invoke virtual method
'java.lang.Object android.content.Context.getSystemService(java.lang.String)' on a null object reference
E AndroidRuntime: **at android.app.Dialog.<init>(Dialog.java:199)
E AndroidRuntime: **at android.app.AlertDialog.<init>(AlertDialog.java:204)
E AndroidRuntime: **at android.app.AlertDialog.<init>(AlertDialog.java:200)
E AndroidRuntime: **at com.android.server.am.BaseErrorDialog.<init>(BaseErrorDialog.java:39)
E AndroidRuntime: **at com.android.server.am.AppNotRespondingDialog.<init>(AppNotRespondingDialog.java:53)
E AndroidRuntime: **at com.android.server.am.ErrorDialogController.showAnrDialogs(ErrorDialogController.java:183)
E AndroidRuntime: **at com.android.server.am.AppErrors.handleShowAnrUi(AppErrors.java:1077)
Analysis:
As Context Object is passed from showAnrDialogs method and will be retrieved from getDisplayContextWithErrorDialogs
And list of context objects will be filled by querying from RootWindowContainer.getDisplayUiContext and this method is
Annotated with Nullable. So, the possibility could be null value filled in the context object List.
Bug: 196189977
Test: Stability Test
Change-Id: Ib944fc5ffc8bcca999c75f99d462d441e555fcda
Remove modules-utils-build_system from static lib of service-wifi.jar,
because it is already in static lib of framework-wifi.jar
Cherry-picked from https://android-review.googlesource.com/1792931
Bug: 195965491
Test: build apex
Merged-In: Ica496e67dd8b7c83aa93a512d06ad1a05d1c9c8d
Change-Id: Ib2fc438eb01787a0910c29601b579c17d06130de
Also add new testcase for sensor privacy service boot.
Test: atest SensorPrivacyServiceMockingTest CtsSensorPrivacyTestCases
Manually test booting with old file version
Fixes: 195913883
Change-Id: I9d8791e5f27c881afd9e23f94fb5fb9dc891fda4
We're willing to preserve an implicit "Nearby devices" permission
grant if this app was already able to interact with nearby devices
via background location access.
If the app doesn't have background location access, then the implicit
"Nearby devices" grant will be revoked as normal. If the "Nearby
devices" permission had already been revoked through some other
means, it will remain revoked.
Bug: 195931693
Test: atest CtsPermission2TestCases CtsPermission3TestCases
Change-Id: I7d8df91954525da6473f70cb1759d9507e6a5606
