* changes:
Log only current client data in IME tracing
Optimized workflow for IME tracing on InputMethodManagerService side
Optimized workflow for IME tracing on InputMethodService side
Optimized workflow for IME tracing on clients side
* changes:
Update variable names to reduce confusion.
Fix/hack MessagingStyle notifications
Reduce notification minimized height
Fix the placement of the work profile and feedback badges.
Fix HUNs
Remove the unneeded icon spacing in the InboxStyle.
Hide app name from minimized notifications
Notification Title is 16pt in Big state
Ensure headerless notification with large icon is big enough.
Round corners of BigPicture
Increase the expand button touchable area.
Remove the reply action entirely.
Notification template redesign; part 1.
Remove night-mode override of notification_divider_height
This CL adds a new parameter shouldBeSeamless to the existing
setFrameRate APIs. This parameter indicates whether the desired
refresh rate should be achieved only seamlessly or also switches
with visual interruptions for the user are allowed. The default
value of the new parameter is "true".
Test: atest SetFrameRateTest
Test: atest RefreshRateConfigsTest
Test: atest libsurfaceflinger_unittest
Bug: 161776961
Change-Id: Ic2446d278e4f57fe507d30a0a18ef7b85909da4b
* Removed some dead code from NotificationTopLineView
* Icons appear left-aligned, as they do with conversations
* Fixed the order (also with conversations) to ensure that
the 'alerted' icon disappearing doesn't cause movement
(at least when the header text fits; otherwise some
amount of movement is unavoidable).
Bug: 163626038
Test: manual
Change-Id: I8e19dd504f8c861f752cd2705048f015ab0e3106
Known issues:
* Sub-par dyson animation
* Sub-par animation of text in the title
* Notification height limits not yet adjusted
* Decorated custom view height limits not yet updated
* HUNs may need to get their own headerless template
* Messaging style notifications are not yet headerless
* Possible [de]colorization bug for grouped icons
* Some notifications still not always expandable
Bug: 163626038
Test: Manual, visual testing
Change-Id: I9e7e2fd689938a13e042c8f6319bd7d0d2252781
This change moves from dumping information of all Input Method client
instances to dumping only the current client, which is the one in which
the triggering event happened.
Bug: 154348613
Test: flash a device
start IME tracing by calling "adb shell ime tracing start"
end IME tracing by calling "adb shell ime tracing stop"
pull generated trace files and visualize in Winscope
or start tracing directly through ADB Connect and visualize traces
Change-Id: I46460d3d08947c7d37a8969a2fed6539f35aaf91
Optimized the tracing logic for the IME clients information. The
clients trigger a tracing dump through the new method triggerClientDump
exposed by the ImeTracing interface. This change was done
to be able to support custom dump for clients information and
custom dump from IMS.
This change only covers the clients information. The IMS and IMMS
information will be dumped in next changes.
Bug: 154348613
Test: start IME tracing by calling "adb shell ime tracing start"
end IME tracing by calling "adb shell ime tracing stop"
pull trace using "adb pull /data/misc/wmtrace/ime_trace_clients.pb ime_trace_clients.pb"
Change-Id: I499cb5f45a3e78912b09b9c6cedf1ce5443e797a
Previously onReceiveContent() would only invoke the app-configured
callback if the MIME type of the content matched one of the declared
MIME types for the callback. This change updates onReceiveContent()
to always invoke the listener if one is set (regardless of the MIME
type of the content). To delegate processing to the platform, the
app's listener can return some or all of the passed-in content. To
make this easy for apps to implement, the Payload class and its
Builder now provide some convenience methods to conditionally
partition the content.
Reasons for this change:
* Checking the MIME types could be an expensive operation. On SDKs prior
to S, ClipData does not keep track of the MIME types of individual
items, so for a ClipData that contains multiple items, checking the MIME
types requires making at least one RPC call per item.
* Allowing the listener to delegate processing to the platform via its
return value enables us to limit the API surface (we don't need to
expose TextViewOnReceiveContentListener as a public API, nor equivalent
classes for other types of views such as WebView).
* An app that wants to customize the platform behavior for coercing
content to text would previously need to declare "*/*" as the MIME type
for the callback (in order to be invoked for all content). But this
would make it impossible for features to know whether the app would
actually accept a particular type of content or just coerce it to text
(e.g. should the soft keyboard show GIF suggestions when the declared
MIME type is "*/*"). With the new logic the app's listener is always
invoked and can decide which content to process vs delegate to the
platform vs reject completely.
Bug: 170191676
Bug: 152068298
Test: atest CtsViewTestCases:ViewOnReceiveContentTest
Test: atest CtsWidgetTestCases:TextViewOnReceiveContentTest
Test: atest FrameworksCoreTests:TextViewOnReceiveContentTest
Change-Id: Ie48b6fe0b2ae4b014c371b5dc40248221947c6bf
Having a hidden abstract method for a class that can be extended
means that public implementors cannot implement these hidden methods
posing a risk that custom implementations will not have required
abstract methods resulting in an exception.
Bug: 151134792
Test: make update-api
Change-Id: I758d12465fabc671be19bedeeceb16885de23c87
Exempt-From-Owner-Approval: large scale suppression of existing issues,
no-op in terms of behavior
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
