In order for us to be able to easily narrow down bugs that say
"IMEs stopped being shown up"
this CL temporarily enables good-old debug messages to logcat whenever
an app is trying to show the IME with the following two APIs:
* InputMethodManager#showSoftInput()
* InsetsController#show(ime())
With these logs, we can easily see if the app was actually trying to
show the IME or something went wrong before the app calls these APIs.
Hopefully one day we can remove these Log.d() as part of our on-going
effort to improve IME debugging (Bug 154348613).
Bug: 171597353
Bug: 171637033
Bug: 171792138
Bug: 172731591
Test: adb logcat -s InputMethodManager:D InsetsController:D
Change-Id: I67a790f9d98d6131aaf04e4bb98d2a28873d3424
When the size and the position of the insets source window are changed
at the same time, setPosition will be applied first, and the client will
draw on the new-size surface later, which makes the screen flicker.
This CL defers the setPosition transaction until the new frame is drawn,
which can make the window stable if the content is drawn at the same
location on the display.
This CL also fixes WindowState#mGivenInsetsPending. If the given insets
will be sent to window manager, the provided insets won't be changed
during relayoutWindow until the given insets are sent.
Bug: 171965103
Test: steps in the bug
Change-Id: I4684c03e8def6fa33980e6c10e444f7377c306f8
If SurfaceView changed and needs to update its SurfaceControl, it will
append its changes to the main window's blast sync transaction. This is
to ensure it can synchronize with the main window.
However, if SV changes, but the main window doesn't need to submit a new
frame, the logic to synchronize doesn't work. This changes fixes a few
issues
1. Make sure to force a full redraw when
mNextDrawUseBLASTSyncTransaction. This is to ensure we get the proper
callbacks even if there's no new content to draw
2. Clear nextTransaction in BBQ when a frameCompleteCallback is invoked.
In most cases the transaction in BBQ is already cleared since the
frameCompleteCallback is called after a frame is latched and BBQ will
clear the nextTransaction that was set. This is needed when hwui won't
draw a new frame since there's nothing new to draw. In that case, we
will get an immediate frameCompleteCallback without invoking the
processNextBuffer. If VRI doesn't clear the transaction, BBQ will try to
use the stale transaction when a new frame does come in
Test: blast sync in SV enabled doesn't freeze YT
Bug: 172579592
Change-Id: Idca7accdf094dbb4585897e4e884c1147b1a2cd0
Add a method to Display.Mode to return all refresh rates
to which a seamless display mode switch can be done. Note
that this is not a hard guarantee for seamless switches,
but rather a guarantee that switching to any other mode
will be non seamless.
This is implemented using the config groups which we get
from SurfaceFlinger.
Bug: 161776429
Test: atest LocalDisplayAdapterTest
Change-Id: Id0e721f6c278ce9dcc04d59422b2f881a1154102
We didn't intend to flip this behavior in the initial BLAST flip
revert back to using deferTransaction for now.
Bug: 172579592
Test: Existing tests pass
Change-Id: I07887d59d16ff3676cf20fac11e1ef3fc5e17106
Annotation processor seens annotation args with constants already inlined,
making it challenging to compare to the souce-generated metadata that contains
initial expressions.
For now just ignoring args for all non-DataClass annotations to prevent false positives
Test: . frameworks/base/tests/Codegen/runTest.sh
Exempt-From-Owner-Approval: changing metadata on multiple files
Change-Id: I640816ae0f20f36b1b828bc2161f53788c4a4dae
Add methods to trace.
Refer to design doc in bug.
Bug: 167947940
Test: atest ImePerfTests and also refer to README.md
Change-Id: I423e4f3f9253707d9b6d3d5a2dee260f872b879f
As part of media mainline project, we're resolving hidden API usages.
ViewConfigration#getMultiPressTimeout is a hidden API
used by MediaSessionService, which is going to move to mainline module.
Seeing a public API, ViewConfiguration#getLongPressTimeout,
making getMultiPressTimeout public seems to be trivial.
Bug: 171163798
Test: build successful
Change-Id: I4fb7b884b7496bfc0e4f33a93eb2a69a889a91c5
Usually most fields of InputWindowHandle don't change frequently.
Therefore, only the changed instances need to be updated. That
reduces the overhead of JNI invocation (especially
NativeInputWindowHandle::updateInfo which may be called from
setInputWindowInfo).
There should be no behavior change.
- Add a InputWindowHandle.ChangeDetectionWrapper to wrap the original
handle. So the changes of its fields can be tracked.
- Make InputApplicationHandle java side immutable. Its content should
be rarely changed. Then it is easier to compare by instance. This
might also reduces the race condition of accessing its field from
InputDispatcher because the instance is different.
- Move some fields that won't change of InputWindowHandle to the
constructor of WindowState to reduce unnecessary updates.
- When a window cannot receive input, reuse the per-window input
window handle to populate the disabled info, so there won't be a
shared instance that its fields always need to be updated.
- Reduce unnecessary Region#translate if the offsets are zero.
- For a simple activity launch, the invocation amount of
setInputWindowInfo is reduced 90% (from 126 to 11).
- The metrics updateInputWindows_mean of WmPerfTests is reduced 50%+
(from 0.89ms to 0.38ms on an old mid-end device).
Bug: 168008622
Test: WindowStateTests#testUpdateInputWindowHandle
WindowInputTests InternalWindowOperationPerfTest
Change-Id: Ief84bbe6e6fa4da5309912059904932ccf775b75
This introduces BackgroundBlurDrawable that does cross-window blurs
The drawable should not be created manually, it should be retrieved
from the ViewRootImpl
Test: manual
Bug: 159712515
Bug: 171916625
Change-Id: I697e93fc95ba3d0a7211b235b1c5d48a1968b939
Update java doc about the selection range and flags.
Test: only updates javadoc, no logic changes. Existing unit tests still pass.
BUG=171804584
Change-Id: Ife314031d728cf4c9d3512110acb3ae985572e7d
Added IntDef annotations to fields that missed them in
WindowManager LayoutParams: input_feature_flags,
system_ui_visibility_flags and subtree_system_ui_visibility_flags.
Bug: 160129453
Test: Run 'mp :framework-minus-apex-intdefs' and check if mapping files are properly generated
Change-Id: I66d6dcbff3b41175827c84c9fda68be92877925a
This is the first step to move the menu to fullscreen, but not quite
yet.
This CL does:
- Move PipMenuView to be attached to SystemWindow, instead of child of
PiP leash
- Use SyncRtSurfaceTransactionApplier to ensure the menu moves along the
PIP leash at the same time when the menu is visible
- Remove setup/destroy code in PipTaskOrganizer with SurfaceViewHost
- Expose Window information to Accessibility services
- Refactor ShellRoot to take in a Layer type instead of windowType
instead
Bug: 161710689
Bug: 170151121
Bug: 169894316
Bug: 152738416
Test: Manual
Change-Id: I73c26f96784b35b9bb9a4bea452df55cf5913278
For shared timeline visualization, the pid of the process owning the
layer is needed to show the information in the respective process
tracks. This change adds pid to the layer metadata that is passed around
during the creation of a layer.
Bug: 170911969
Test: pid section of `adb shell dumpsys SurfaceFlinger --frametimeline -<all/jank>`
Change-Id: Ibd16bf7740d0c1be07cdbd300a1741cfcb6d2ad8
If we rely on the finalizer we may end up keeping buffers alive
for a long time, and introduce OOM in some window creation stress tests.
Bug: 168506246
Test: Existing tests pass
Change-Id: Iaee579cdff96f1020a4904f89b876b726ecabd08
Expose uid to the CaptureArgs in Java and JNI. The implementation in
native is already merged.
Test: Builds
Bug: 155825630
Change-Id: I66e8870bfbf84a089387b73751cddbac253f9781
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
This is a resubmit of ag/12929664 with some APIs excluded that caused
test failures; see bugs 171886397, 171888296, 171864568.
APIs excluded:
Landroid/bluetooth/le/ScanRecord;->parseFromBytes([B)Landroid/bluetooth/le/ScanRecord;
Landroid/os/Process;->myPpid()I
Landroid/os/SharedMemory;->getFd()I
Landroid/hardware/input/InputManager;->INJECT_INPUT_EVENT_MODE_WAIT_FOR_FINISH:I
Bug: 170729553
Test: Treehugger
Change-Id: I8285daa8530260251ecad6f3f38f98e263629ca7
Update InputConnection#getTextBeforeCursor(int, int) and
InputConnection#getTextAfterCursor(int, int) API to
specify that the paramter {@code n} must be non-negative.
If the IME using the API incorrectly, throw
IllegalArgumentException.
Also update these two APIs that return nullable result (no
behaivor change). For editor App, return null for bad case.
Test: atest BaseInputConnectionTest#testInvalidGetTextBeforeOrAfterCursorRequest
Test: atest InputConnectionWrapperTest#testInvalidGetTextBeforeOrAfterCursorRequest
BUG: 169114026
Change-Id: I95169735198f8363c981a61e20234dfebfd645b1
* changes:
NotificationTopLineView supports layout_height="wrap_content"
Respect the gravity of the NotificationTopLineView.
Remove the smart reply container from the base template; I believe they are never used
