This change moves the initial bootstrapping of the apps filter cache off
onto a secondary thread to avoid impacting the boottime critical path.
Fixes: 162347084
Bug: 161250592
Test: atest AppsFilterTest AppEnumerationTests
Change-Id: Iafa85e838d7f753eaf74037c85f86ee1feeb17aa
(cherry picked from commit 6ab5b2975e)
Merged-In: Iafa85e838d7f753eaf74037c85f86ee1feeb17aa
Merged-In: Iac2948fb2ad66e45161627f637f039a5f4faf88c
Previous logic in onStateChanged notifies insetsChanged based on the
change of mLastDispatchedState, which can make us dispatch redundant
insets changes to the app.
In this CL, we only notifies insetsChanged if mState is really changed
in onStateChanged -- we use the final mState (after updateState and
applyLocalVisibilityOverride) to compare with the one before changing.
Fix: 161924448
Test: atest InsetsControllerTest WindowInsetsControllerTests
Test: Swipe up to home while IME open and see if there is any jank
Change-Id: Ia536cdf76805caa56ca1b6eaf2b3db83b6ecd94e
Its getAllUsers() method was not returning pre-created users, so
packages installed for a "regular" user were not marked as
"installed=false" for the pre-created users. Hence, when the
pre-created was "promoted" to a full user, it contained such
packages.
Here's how to reproduce the issue:
$ m -j ApiDemos
$ adb shell pm create-user --pre-create-only
Success: created user id 10
$ adb install --user cur $OUT/testcases/ApiDemos/arm64/ApiDemos.apk
Performing Streamed Install
Success
$ adb shell pm list packages --user cur | grep com.example.android.apis || echo
package:com.example.android.apis
$ adb shell pm list packages --user 10 | grep com.example.android.apis || echo "NOT FOUND"
package:com.example.android.apis # Should return "NOT FOUND"
$ adb shell pm create-user FullUserIAm
Success: created user id 10
$ adb shell pm list packages --user 10 | grep com.example.android.apis || echo "NOT FOUND"
package:com.example.android.apis # Should return "NOT FOUND"
With this fix, it returns "NOT FOUND" in the expected steps.
Fixes: 160252062
Fixes: 162847145
Test: see above
Change-Id: I6cd17ac588a4d95bf0ea704dd18387e19eeab374
(cherry picked from commit 00175974ba24d982ecfe760ee78a1a17bb326d04)
Add a null check for mResolverDrawerLayout in ChooserActivity
Bug: 162900698
Test: ChooserActivityTest
Change-Id: Id2b4442a0c5f22e1ecff04a1d20b48784ecc47dd
Extend timeout more than telephony retry timer to prevent CS release 2nd request before retry.
Bug: 159772456
Test: Consecutive emergency NI SUPL test, emergency NI SUPL test with/without SIM and SI SUPL test
Change-Id: Ib3e1f394adda6c2c2eacc38df941cc5e9fd8370d
For range controls, many users will want to swipe multiple times in
order to set the desired level. Currently, if the user swipes twice in
fast succession, only the first set point will be sent. Do not block
these swipe events from being sent to the corresponding service.
Fixes: 162850998
Test: manual swipes on range controls
Change-Id: Ib3be25bd362b411b9cd089d49edec7747820d0e7
(cherry picked from commit 05ed2ceec9)
Discussions with framework team led to addition of the
BIND_NOT_PERCEPTIBLE flag, which will help release the service when
the system is under memory pressure.
Fixes: 158771014
Test: manual
Change-Id: I58b25dd23dba88fbd9e5f9e3ad0a052cccd39d21
(cherry picked from commit 9a7bd8477f)
This was intended to fix a reparent issue when preserving
surfaces before the app was closed. That is no longer happening
so this change is no longer needed.
The reason this causes the flicker is it waits to reparent until
next frame. However, the frame can be submitted before WM gets a
chance to show the new Surface since that request is sent to WM.
Therefore, the SurfaceView can end up getting reparented to the
new SurfaceControl before the new SurfaceControl is visible,
causing it to be hidden for a few frames.
This reverts commit c1dcac9568.
Reason for revert: b/162377855
Fixes: 162377855
Test: Split screen with SurfaceView doesn't flicker
Change-Id: Ic7a209b7aa66e278b99a526d8427f140b31de0f6
If the size of snapshot is mismatched, the removal of the starting
window will be deferred. But if the snapshot target is home, since
it is only presented for unlocking, it is better to dismiss it as
soon as possible to avoid outdated content from being shown on screen
if the windows of home have drawn.
Bug: 161530286
Test: Keep home on top and turn off screen with secured lock. Use
fingerprint to unlock. If home is drawn fast enough, the
previous state won't show on screen (e.g. the time on clock).
Change-Id: I103f49eb539f78455ad38f48f9cd853dee51b135
android_uiautomator is distributed as part of the SDK and should use
-target 8 for compatibility with old JDKs.
Bug: 150153790
Bug: 162522383
Test: javap -v -cp out/target/common/obj/JAVA_LIBRARIES/android_uiautomator_intermediates/classes.jar com.android.uiautomator.core.Configurator | grep "major version"
Change-Id: I6871ab5436232ad3bffff6bd26adf2de6b3c06ff
