We may set a z-order different from the prefix order, for example
TaskDisplayArea#adjustRootTaskLayer. As a result, we should no longer
set animation leash layer based on the prefix order.
Fix: 208793409
Test: manually test launching activity over another
Change-Id: If8d545ca7a9ac42162262ad3a8f95b4ac9f65585
EventLog function can handle string,integer class and long class. (in android_util_EventLog.cpp)
If menu title string are used bold tag(like <b>test</b>), it'll be android.text.SpannedString.
therefore any android activity using tag menu string(like <b></b>) can be crashed by IllegalArgumentException.
Bug: 208862322
Change-Id: I2432b0cd28c8f5fcb07cdf3e29560bf6b6c0f7b6
Signed-off-by: chenchaoli <chenchaoli@xiaomi.com>
There are missing API description at getServiceComponentName in
ContentCaptureManager. Some errors may occur and an exception may be
thrown. So update the javadoc to remind user to handle.
Fixes: 203368373
Test: make
Change-Id: I979c81c74cda4e50627dc0c83ae7c33b333b9255
Fixes an issue where getting the IME source to check its
visibility unintentionally lazily created it.
Fixes: 208200189
Test: manual
Change-Id: Ib36082b393215fc59e299dea30d3315f3748ca02
The previous code waited for a frame complete callback from hwui before
notifying WMS that a draw had occurred. However, frame complete callback
was not guaranteed to get called since it only invokes a callback if a
draw actually occured. VRI really needs a signal that RT has completed,
since it just needs to know that a draw was possible so it can notify
WMS that the RT completed its pass.
Instead, rename frameCompleteCallback to frameCommitCallback since that
API is exposed to a public API when a frame was actually drawn.
Create a new callback, frameCompleteCallback, that is invoked when the
draw has completed, regardless if a frame was actually drawn.
When the frameCompleteCallback is invoked, VRI can check to see if a new
frame actually drew. VRI can call into BBQ to see if the frame acquired
matches the frame that was attempted to draw. If so, VRI can wait on a
transaction callback. If not, it can allow VRI to continue. In either case,
it will notify WMS that the draw has finished.
Test: Split over and over
Bug: 195262673
Bug: 193634619
Change-Id: I24dd19ab2746be3fc33e597761abf8c5249f8b5b
Merged-In: I24dd19ab2746be3fc33e597761abf8c5249f8b5b
CL[1] using isRequestedVisibleAwaitingControl() in
ImeInsetsSourceconsumer#setControl to hide IME surface when it returned
false without waiting control or requesting visible to deal with the
unexpecting hide IME cases during the testing.
However, when calling IMM#toggleSoftInput to reqest showing keyboard
on the dialog implicitly that will set requrested visible on both the
caller window and the dialog window, since toggleSoftInput didn't
explicit set the target window but just using the caller window as
requester implicitly.
It causes a regression that can't hide the IME surface when dismissing
the dialog to back to the caller window that the IME insets source
control is null but isRequestedVisibleAwaitingControl still returned
true because isRequestedVisible has been set true for the
toggerSoftInput caller window.
Revert logic in setControl to use mIsRequestedVisibleAwaitingControl
in case the IME surface won't be removed when backing to the implicit
caller window of toggleSoftInput.
[1]: I3071af14bf78e23f9526d6a9c138ab6ae2e0e339
Bug: 207092186
Bug: 204524304
Test: manual
Test: atest CtsInputMethodTestCases
Test: atest WindowInsetsAnimationControllerTests
Change-Id: Ic5265a6c3f2eba77d43832d23309998bf3cb1671
The insets resize animation is used to produce the callbacks of the
animation progress to the app. It shouldn't change the state of the
insets controller.
Fix: 205082601
Test: 1. Open a sticky-immersive app on a device which has taskbar.
2. Make sure taskbar is minimized on apps.
3. Swipe from bottom twice to go to home screen.
4. Open the same app again and see if task bar is hidden.
Merged-In: I5d9213d7b3e32eccbf3a51335654f5f53899e6ae
Change-Id: I5d9213d7b3e32eccbf3a51335654f5f53899e6ae
(cherry picked from commit cb11735c85)
Before this CL, SystemUiContexts were fixed to the Display metrics
when the SystemUiContexts were created. It is the same mechanism
as DisplayContext but applies to SystemUiContexts unexpectedly.
This CL makes SystemUiContexts associate with DisplayContent with
the corresponding display ID. In this way, SystemUiContext would
receive updates when there is a Display property change.
Bug: 194262507
Bug: 191064581
Bug: 205859784
Test: atest InputMethodMenuControllerTest WindowContextControllerTest
Test: atest NexusLauncherTests
Change-Id: I64a1614f32d097785915f6105b1813a929e0fe32
When hw rendering is disabled, we can't merge the transaction with the
next frame because the frame drawing callback won't be invoked. Instead,
just apply the transaction immediately
Test: HW Rendering app can remove SV
Fixes: 205924676
Change-Id: Ia6adb6dbad0238c4d815c72efc9b73bf4ea9c84a
Found a memory leak on ViewRootImpl. If the view wasn't been set
to the VRI successfully, there would keep the registed listeners to the
AccessibilityManager and DisplayManager forever because there didn't
need to deatch anything from window.
Another reasonable way is to register all listeners after setView
success.
Bug: 200843755
Test: manual, hard code to force addWindow fail and monitor no more
ViewRootImpl object leaked to AccessibilityManager and DisplayManager.
Change-Id: I3c9cc52d0ca4595c74c1dc3c51d286d9e6e3897f
Merged-In: I3c9cc52d0ca4595c74c1dc3c51d286d9e6e3897f
Many TV remotes have direct keys to launch the specific
application such as Netflix. KEYCODE_APP_X are
intended to be used for such a purpose and to be handled
by GlobalKeyManager.
Categorized like below.
- KEYCODE_VIDEO_APP_X
- KEYCODE_FEATURED_APP_X
- KEYCODE_DEMO_APP_X
Prevent KEYCODE_APP_X from being sent to the apps.
Bug: 182532772
Test: atest KeyEventInterceptTest
Change-Id: I13c469c92da97014be5c76c230806331f0602b54
Merged-In: I13c469c92da97014be5c76c230806331f0602b54
