This logically reverts a previous CL [1], which added
InputMethodInfo#isEncryptionAware() for File-Based Encryption (FBE)
support, since it turns out that the method in question is unnecessary
to make InputMethodManagerService encryption-aware.
[1]: Icf921fe3661eccf4a589b08b616d05decc561356
69811a98f1
Bug: 26279466
Change-Id: Ia4884bf5922ad453d4b9e5e3c6f0d17b36dc205d
Apparently only the navigation bar is excluded when calculating
Configuration.screenLayout. Make the calculation for non-fullscreen
tasks consistent with fullscreen tasks.
Change-Id: I027e41e49ffe95245116f3d134e0bc93af0ee450
When animation happens in a dialog, it is possible for the dialog to
be dismissed and RootRenderNode to be destroyed before we create
animation handle for the staged animators. In that case, we need
to remove the staged animators so they will not run without a
animation handle.
Bug: 26975079
Change-Id: I0c2c6c1b530beaec3984c0b1c410df4fd8f25c95
- Move ClipRectTB/LRAnimation to wm package, because that's the only
place we use it.
- Extend ClipRectTBAnimation to combine it with translation animation
so the clipping gets applied after the translation.
- Fix clip reveal transitions when a window is docked.
- Make the docked divider minimizing animations synchronized with clip
reveal animation.
Bug: 27154882
Bug: 22174716
Change-Id: If5c94c777f3b51c6f53f6f34cc261bf3439cfc88
- We keep the docked stack visible when home task is visible even
though it's not resizable.
- We introduce the a new concept called "minimizing" the docked stack,
which happens when going home. In this state, the docked stack is
clipped of almost completely.
- To achieve that, we introduce TaskStackBoundsAdjustController,
which adjusts the bounds of the docked stack when minimized. Also,
migrate the IME handling to this new class.
- We also need to inform SysUI that it is now minimized so it can
remove the drag affordance on the divider, and also make it a bit
smaller.
- When we detect an app transition, we check whether the home stack
gets visible/invisible. We then start an animation which runs in
sync with the normal app transition. For that we introduce
DockedStackDividerController.animate(), which performs the animation.
Bug: 27137961
Change-Id: I8623bc73cc6872bf28c5b1b8d5795974576811b2
Currently if View.setPointerIcon is called from inside a pointer
event handler this will cause a redundant round-trip to the server
which can be easily avoided.
Bug: 27107871
Change-Id: Ia641818c3700c0d96d0c32e020b91af58dccfa2a
If there was another layout happening before the app called
relayoutWindow(), we were issuing multiple reportResized calls,
leading to multiple relayoutWindow() calls, slowing everything
down.
Change-Id: I1f3da04bb7581c655567e1d1a6fe0f8c83c0ffda
-Only add animators to a RenderNode when its owning view is attached
-When changing animator's target RenderNode, remove the animator from
the old target RenderNode that it's currently running on, if any.
Bug: 27141983
Bug: 27145149
Change-Id: I9c9592382d64ecc0390f7ec743a59ce1ad7d9798
It is possible for the WindowManager.LayoutParams set from a view/window on
the client side not to have the LayoutParams.mTitle set. This is normally
not an issue as we later set it to the package name before passing the
LayoutParams to window manager. However, we rely on the full window name
in order to identify unique windows during CTS hostside tests. We now
retain the current LayoutParams.mTitle if the LayoutParams we are copying
form didn't set one.
Bug: 26982752
Change-Id: Icc3c5937391ed1646c3777921c6f61c27ebec05d
Currently there is an internal hidden class named
ControlledInputConnectionWrapper which works as a proxy in the
application process to receive incoming binder calls from input method
and dispatch those method calls again on an appropriate thread.
Although this is a kind of implementation details, basically you can see
the same design everywhere in the Android.
Currently ControlledInputConnectionWrapper is initialized with
view.getHandler(), where the view here is the View which was used to
call View#onCreateInputConnection(). This is actually a reasonable
behavior because we have generally assumed that there the only
reasonable way to implement InputConnection is to extend
BaseInputConnection, which is designed to be able to work only on the
UI-thread associated with the target view.
However, on Android N and onward, we are going to ensure that
BaseInputConnection can be re-implemented on top of public APIs [1].
Although most of applications should not try to do that, for certain
applications such as web browsers and WebView it may make sense to let
custom InputConnection implementation run with a custom Handler so that
the application can respond to the IME without blocking the UI thread.
To do that, this CL introduces a new method
InputConnection#getHandler(), which changes nothing as long as it
returns null, but if it returns non-null Handler, InputMethodManager
will use it to initialize ControlledInputConnectionWrapper.
Note that InputConnection#getHandler() is not for IME developers.
It just returns null when called in the IME process.
[1] See Bug 24688781 for details.
Bug: 26945674
Change-Id: Id9e579bb3e2966986cdcb1c34bc8cacfeca2e1a9
In split-screen the light status bar flag for one side of the
status bar can be different from the other side.
SYSTEM_UI_FLAG_LIGHT_STATUS_BAR is now reported for both
the fullscreen stack and docked stack, but not anymore in the
"default" SysUI visibility field when reporting a visibility
change to SystemUI. The change also reports the docked stack
and the fullscreen stack bounds, so SystemUI can guard tinting
the icons on whether the icon is one of the areas.
When calculating the light status bar flag in PWM, we keep track
of the top fullscreen opaque window state for the docked and
fullscreen stack separately.
Bug: 24365214
Change-Id: Id2240a86d75bf96e0138ec7652a4793859f56e3c
The ViewPager requires measure/layout to initialize a list used
in getChildDrawingOrder, and crashes when this method is called
too early. Protecting against that by assigning a default value
to the drawing order value of AccessibilityNodeInfo if the View
bounds have not yet been set.
Bug: 27076826
Change-Id: Ic42dbb81d15340f6b021626b1c27ad5abce7e7d1
Currently, scrollbar is mouse draggable even when it's not visible.
It's confusing. Scrollbar shouldn't be draggable when the View don't
want to show scrollbar. This CL fixes it.
Bug: 20016455
Change-Id: Ibada1f01fb4821cdd834c9f9c0dafa02f5530e60
This is a follow up CL to the previous CL [1], which unintentionally
relied on whether the entire application rather than the
InputMethodService is marked to be encryption-aware. This wasn't
obvious because right now LatinIME is entirely marked to be
encryption-aware, which probably needs to be reconsidered in subsequent
CLs.
This CL drops "encryptionAware" line from InputMethodInfo#dump() as it
is redundant. The same information is already dumped in the
'ServiceInfo' section.
[1] Icf921fe3661eccf4a589b08b616d05decc561356
69811a98f1
Bug: 26279466
Change-Id: I6cea5fe5731f4a6a64ea722b854b99c5154a15ae
- Rename to FrameMetrics to avoid collision with existing
android.view.FrameStats class
- Make FrameMetricsObserver implementation detail,
exposing FrameMetricsListener interface as public API
and wrapping in FrameStatsObserver to maintain state
- Remove dropped frame count call, in favor of passing as
parameter to callback method.
- Move away from raw timestamp access in favor of Metric IDs
which represent higher-level, more stable stages in a frame
lifecycle and match the categories exposed in the onscreen
bars.
- Support many-to-many Window<->FrameMetricsListener relationship
Change-Id: I00e741d664d4c868b1b6d0131a23f8316bd8c5c2
This is another preparation for Bug 26279466. Whether an input method
is marked to be encryption-aware or not would become the thing here and
there in the Framework code. Having a utility method and debug info
in dumpsys should make our lives easier.
Bug: 26279466
Change-Id: Icf921fe3661eccf4a589b08b616d05decc561356
This has nothing to do with Bug 26279466 but might be something nice to
fix just as a preparation.
Bug: 26279466
Change-Id: Ie1a8ee2248081a70728c29e52c657b3a0ed919b1
This makes the animation when exiting docked mode a bit nicer
when you fling the divider towards to the navigation bar. However,
since the divider ends at the navigation bar, we need to immediately
dismiss it instead of fading out when the divider is fully occluded
by the navigation bar.
Change-Id: Ic5432fd118cb71be36485667b2c537caf5065ce5
Prior to this commit in this case of activity pause, with finishing=true
the activity manager will notify us of app visibility and we will begin
an exit animation. When this exit animation finishes, we will destroy
the application surface (unless its eligible for saving). However there
are two cases where this breaks down:
1. The exit animation finishes before the activity thread handles
the stop transition. Many activities stop rendering on Pause
but many do not and it is totally legal to do so. Sometimes this
results in non fatal dequeue buffer errors and sometimes results in
fatal errors with Pixel Buffers, etc...
2. We may resume the activity shortly after asking the window manager
to pause it. If the window wasn't eligible for animation, we will
immediately destroy it after being told of the visibility change
following PAUSE_FINISHING. It's possible for this to complete
before we process the resume. On the other hand the client
happilly processes the resume and transitions back from PAUSE
and then crashes once it attempts to use it's surface.
In this commit we have the activity manager notify the window manager
when an application has actually finished (or we have timed out
waiting). For windows which have not been explicitly removed by the
client, we defer destruction until we have received both this signal
and the animation has completed.
Bug: 26793431
Change-Id: Ib6ee8fbdd1f03450fbbfd62468a19e97774befab
Have the new showContextMenuForChild(View, float, float) call through
to the old showContextMenuForChild(View) before recursing up to its
parent. This ensures that existing apps with custom views that
override the old method still get called as expected if they implement
custom behavior.
Unlike some other similar circumstances we aren't implementing this to
be bidirectional as the new behavior doesn't need to be triggered by
invoking the old. If the older method is invoked explicitly we will
still show old-style dialog context menus instead of the newer popup
style since we won't have a good place to visually anchor a popup.
Bug 26919262
Change-Id: Ie09f922d322b5a24789c7867820c4bc43824c385
(cherry picked from commit 759a4c5400)
* changes:
Hide swipe-up gesture behind tuner flag
When long pressing recents and already docked, undock
More multi-window fixes
Use separate flag to suppress resizes
Only treat "null" bounds as fullscreen
Exclude stable insets from task config
Fix bug where surface was not clipped off during resizing
Fix crash in SysUI when configuration changes
When dragging the divider in a way such the task size goes through
the following transition
- Half size
- Full screen
- Half size
the surface wasn't clipped off anymore. This was because in full
screen configuration, computeDragResizing() == false thus when
going full screen -> half size, we reset the draw state to
DRAW_PENDING to get notified when it has finished drawn. However,
this also broke clipping.
In order to fix this, we always put the window into a resizing mode
no matter whether the bounds are fullscreen or not.
However, this introduces an ugly flickering on the navigation bar,
when going into docked mode, because the app doesn't draw navigation
bar background in resize mode.
To fix that, we calculate the presence of navigation bar whether the
window is fullscreen, and not just whether it's resizing. For that,
we need to calculate the presence in BackdropFrameRenderer, by using
the insets just sent by window manager.
Change-Id: Idf56df4ae7fefe67d068bc2eeda8dc4d83bbefb7
