Apps making calls into the system server may end up persisting
internal state or making security decisions based on the perceived
success or failure of a call, or the default values returned.
The reality is that if the system process just died, init will be
along shortly to kill all running apps, so we should have no problem
rethrowing the RemoteException as a RuntimeException.
Bug: 27364859
Change-Id: Ife0bcb079636c88d54c44d17eb580409fd79028b
If ignoreBottomDecorations=true, the display size was extracted from
the resources. However, this didn't work if the parent window was in
multi-window, as all the calculations went wrong. Instead, introduce
View.getWindowDisplayFrame which returns the "full" frame of the task
the window is currently in, without any insets, and use that to
calculate the bottom edge.
Bug: 26255254
Change-Id: I8b235b335775022ae399ee082d1200aa76cc047c
This reverts commit 90bd36363c.
Seems that the semantics of InputConnectionWrapper#setTarget() is more
complicated than I thought. At least the following cases have worked
fine.
case 1:
InputConnectionWrapper wrapper =
new InputConnectionWrapper(null, false);
wrapper.SetTarget(ic);
...
case 2:
InputConnectionWrapper wrapper =
new InputConnectionWrapper(null, true);
wrapper.SetTarget(ic);
...
case 3:
InputConnectionWrapper wrapper =
new InputConnectionWrapper(ic, true);
wrapper.SetTarget(null);
wrapper.SetTarget(ic2);
...
The previous code did not intended to break existing code. Let's revert
it we decide how to deal with above cases.
Bug: 27407697
Change-Id: I8bc84d484ab0b27a02e74f11110430f70646e69a
This CL makes it clear that InputConnectionWrapper does not support null
target. In other words, the semantics of null InputConnection can never
be emulated by a non-null InputConnectionWrapper.
This is particularly problematic when app developers are just forwarding
the return value of super.onCreateInputConnection() to
InputConnectionWrapper or its subclass, because there are many chance
that super.onCreateInputConnection() starts returning null, e.g. when:
A. the application is extending a Framework class, and the Framework
class is updated by OTA.
B. the application is extending system WebView, and the WebView is
updated.
C. the application is extending a 3rd party library, and the app
developer creates a new build with a new version of the 3rd party
library.
To make it easy to catch these kind of bugs, this CL lets the
constructor of InputMethodWrapper throw NullPointerException when target
is null. Bugs like crbug.com/571229 should be caught by developers
more easily.
Bug: 27407697
Change-Id: I83875bea886d4784f9507c930050efc29708d9db
Sometimes pointer change request is delivered after view is detached from its
ViewRootImpl. E.g. when popup is present click outside to close it.
Bug: 27292939
Change-Id: I925728af334a1e1ae53f7e530d639e50b0c37f2b
Bug: 27286867
If the system/app is slow, it might take too long to
stop drawing. Switch the ordering of destroying stuff so
that we switch to the pbuffer surface first, then do
cleanup
Change-Id: If64a3dbb71bb9fd53567231590436a89b2f1a09e
The registered shortcut will be called from PhoneWindowManager,
before dispatching
Change-Id: If26128939b45a639c8895719a7a23ca433f39fd9
(cherry picked from commit 4da863c5a8872dcabb179a978a2b2157d9081679)
Encapsulating the logic to toggle multiwindow mode from recents,
and plumbing it through to accessibility global actions. Sending
accessibility events when windows bounds change. Exposing the
dock divider window type to accessibility services.
Bug: 27250995
Change-Id: Ib7491f1f853dc7f01bf5c5a4ac1f914f55d0608a
When doing the actual layout pass, desiredWindowWidth/Height might be wrong,
because window manager has the final say how large the surface is, so use
that size.
Bug: 27342700
Change-Id: I4f74fdef66ba7aa88b86f8c95fb391b1cc847beb
When an app requests SYSTEM_UI_FLAG_LAYOUT_HIDE_NAVIGATION but we
force show the navigation bar, we need to treat for the app like
there is no virtual navigation bar on the device. Because if you
combine it with FLAG_HIDE_NAVIGATION, you'd expect the navigation
bar gets hidden but it doesn't, so there could be content that
overlaps with the navigation bar.
Bug: 27157904
Change-Id: I088e02eae2e723c35e9cb4873de6b1325458533b
The selection handles are implemented based on PopupWindow hence it is
necessary to calculate the transformed location from the TextView's
local coordinates.
This CL only addresses the selection handle locations. Many
functionalities (e.g. selection handle moving direction, handle angle)
doesn't work on transformed view since many components are calculated
on the TextView's local coordinates.
Bug: 24902578
Change-Id: Iaa5fd2812969d097e3bf3219a818ffbc67aaef54
By default, AVD animates on RT thread. But since in some cases there's a
need for a finer control on when the frame update for the animation should
happen, such as coordiating the AVD animation with other animations that
run on UI thread, we are providing a way to force the AVD to run on UI
thread.
Bug: 27278616
Change-Id: I372ecd3dc52e3fa0bdce3a1e9c19443f9b199027
Bug: 27286867
This hopefully makes everything fully-deterministic. It should
also fix some old annoyances around Bitmap lifecycle as they will
be released earlier in onStop() instead of waiting for
dispatchDetachedFromWindow() which may never happen.
Change-Id: I6e871760650780e327c0e42f62950c1052dd8019
This is a safe refactoring that changes nothing.
In order to improve the keyboard dismissal lags [1][2], we have used
IMMS#windowGainedFocus() as a combined event to do startInput() in
certain situations.
To make the intent of those CLs clear, this CL renames
IMMS#windowGainedFocus() to IMMS#startInputOrWindowGainedFocus(). Note
that these are @hide internal IPC protocols. Hence this change is never
observable to application developers.
[1] I8494cbd6e19e2ab6db03f2463d9906680dda058b
a82ba54b0b
[2] Icb58bef75ef4bf9979f3e2ba88cea20db2e2c3fb
7663d80f6b
Bug: 25373872
Change-Id: I56934f18e30d90fcdf77bcbb0c35a92a5feb1b82
See thread: "key presses & Ambient"
Bluetooth media button presses and Stem buttons were being rejected in ambient. This change allows those keys while disabling touch events while in ambient.
BUG: 25964771
BUG: 26524301
Change-Id: I914edd447c38678a06d27677be4597c0ee384635
(cherry picked from commit 7528f57c4d)
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
