- Use the precalculated aggregate visibility instead of traversing
hierarchy again in isShown()
Bug: 140157754
Test: atest SystemGestureExclusionRectsTest
Change-Id: Ica58de4ff43da75cfcdac3f359fc915f65608e78
Sometimes, the activityViewToScreenMatrix is null, we should skip
updateing cusor anchor info in such cases.
Fix: 139135335
Test: Manually using the steps in bug.
Change-Id: Ie58ad9a311a8f630b0a6d27d60ca017abc95ef45
For backward compatibility, SurfaceView ignores alpha value by
default. In order to reflect alpha value set on the SurfaceView
to its underlying surface, setUseAlpha() needs to be called.
Translucent alpha only works when the surface is placed z-above.
Otherwise only fully opaque and transparent status are supported.
Bug: 137937105
(Orignal bug from b/130442248)
Test: Manual, use BubblesTest app and checks if alpha is set.
Change-Id: I86847de59109b2adf12a2c7c50c988c2cbcf0450
Test: Open app and immediately swipe up while opening. Verify
Thread prioties in systrace
Test: WindowProcessControllerTests
Fixes: 137881181
Change-Id: Ic1d7403d2a648e6f1d1b6a3d55b56bf37bc57a2c
Some apps rely on not updating the window format when changing the
background of the DecorView. To keep the compatibilty with these app we
add only call DecoreView.drawableChanged() when the window background is
changed on app targetting Q and above.
Test: Manually test by lunching Instagram TV and pressing return twice.
The window should aninate with no flickering.
Bug: 136987724
Change-Id: I3593d30dc6f10519008151974e475f0dad86fc64
- Allow the recents animation runner to request deferring a cancel from
stack order change until the next app transition start without using
a screenshot. This allows launcher to set this state, then start an
activity without a flash due to the animation not finishing immediately
- Always prepare a transition when using the deferred cancel to ensure
an app transition callback
- Handle app transition canceled as well (if canceled, we continue to
cancel recents the animation with/without the screenshot as requested)
- Remove internal lock and use the global WM lock when setting the defer
cancel state
- Renamed a few methods to clarify the deferred cancel flow
Bug: 137196872
Test: atest FrameworksServicesTests:RecentsAnimationControllerTest
Test: atest WmTests:RecentsAnimationTest
Change-Id: Ie8f6f60b6bf6777e36f24749b30f90c8c26ee848
When the WindowManager lock is contended, reportSystemGestureExclusionChanged can cause
jank. Making it oneway avoids this.
Fixes: 137650591
Test: make droid
Change-Id: I5d96b7e2225745b146014ad11cafaf0ad9a1b734
Merged-In: I5d96b7e2225745b146014ad11cafaf0ad9a1b734
In Q, these APIs were either:
- removed from the greylist entirely without good reason
- Moved to the restricted greylist without any public alternative
information added
So they are being moved back to the greylist for Q.
Test: Treehugger
Bug: 136102585
Change-Id: Ie3dd15c8e17d530d853473a013717e6175383080
Currently when calling attachAndQueueBuffer, the color space information is
lost. This results in color shift if the color space doesn't match the color
space of the surface.
BUG: b/135002842, b/131928312
Test: boot. Manually verified on P19
Change-Id: I95ec73c24942f79197d25ee85f139b2aaf805677
... as throwing an exception in there somehow will mess up the
hwui task queue.
Test: Have a crashy app, swipe up while the app is crashing
Fixes: 134583193
Change-Id: Ie3ba5f991759f807b154f55f9fc816e7efe2fdfe
Revert API behavior changes to SurfaceView, snapping
back to Q's version.
Bug: 133378280
Test: none
Change-Id: I3a47f9bfdfab2d16707f952a9af672551736e681
When the configuration changes between landscape and reverse
landscape, the app will not receive onConfigurationChanged as
orientation is not part of the public portion of the configuration.
However, when the ViewRootImpl receives such a configuration back from
relayout, it will force a layout of the client views
(see updatedConfiguration in performTraversals), this is because
Configuration#equals compares the non public part of the configuration
as well. This CL changes MSG_REPORT_RESIZED to handle the configuration
changing the same way performTraversals does, so that the app consistently
receives a configuration change.
Bug: 134643273
Test: Manual
Change-Id: If016bcd9a5b8d2a7efc5e1ab3c82a88a608caf8b
Annotates InputMethodSystemProperty#MULTI_CLIENT_IME_ENABLED as @TestApi
to let cts can verify if multi-client IME enabled.
Bug: 135217809
Test: build and passes
Change-Id: Id7b4dceb2dbfaf3d7ed1084957dd14b04cad0cdf
... as opposed to strong references.
In case the calls between register and unregister aren't matched, we don't want to be leaking views.
I haven't seen any real eveidence of there being leaks, just a report. But this is preventative.
Created a "WeakSparseArray", which wraps SparseArray, and passes in a kind of WeakReference that has an id.
The references become unreachable, we use the id to remove the the entry from the SparseArray.
Test: Used the device for a bit with talkback on. CTSAccessibility*
Change-Id: I8d11727428f56fc06007232ae341d1409a11991f
Fix: 134506015
In order to get DISPLAY_EVENT_CONFIG_CHANGED, eConfigChangedDispatch needs
to be used when creating DisplayEventDispatcher.
Bug: 131688378
Test: adb shell /data/nativetest64/libsurfaceflinger_unittest/libsurfaceflinger_unittest
Test: trigger config change and observe logcat
Change-Id: I0de8037ee5b024b7d9729750f582be919087be41
failed to launch app resolver when there are more than one app handlers.
What happened:
1. TextClassifier constructs an implicit intent to fulfill a task
like opening a link, making a phone call, etc.
2. TextClassifier calls resolveActivity against the implicit intent to
resolve the intent. The resolve component name will be used to create
an explicit intent. In this case, the intent is resolved to the
app resolver activity.
3. wouldLaunchResolverActivity in SysUI returns false for an explicit
intent with component name android/ResolverActivity.
4. SysUI does not trigger the "start the activity after the keyguard
is gone" logic because wouldLaunchResolverActivity returns false.
5. When user clicks on the action on keyguard, ResolveActivity.onStop
is triggered because it is shown (and thus moved to the background)
under the keyguard. So, finish() is called in onStop, and thus the bug.
IMHO, wouldLaunchResolverActivity should not return false
for an explicit intent with component name android/ResolverActivity.
But since we are late at this point, the safest option is to not setting
component name when the intent is resolved to package "android". Note that
this is what we are doing for P, so it should be pretty safe.
Test: 1. Install two browsers. Send myself a link. Tap on the Open Link
chip on keyguard. App resolver is shown.
2. atest frameworks/base/core/tests/coretests/src/android/view/textclassifier/
BUG: 129220155
Change-Id: I6d4d67c2233a2fec950887ea274825bf1cbc1ae2
