We always want the SurfaceView to be layed out
relative to the parent frame, fixes multiple issues
in freeform mode.
Bug: 26689889
Change-Id: Ib4728a515dc01c6884363b68a29f2e4ce5d5babc
In resize modes where we are preserving the main application
window, we need to tell the WindowManager to prepare to replace
the child surfaces, or they will dissapear across relaunches.
Bug: 26070641
Change-Id: I864168688dc320e9280e651f9c5df614f52bc96c
- Make sure mPendingBackdropFrame gets also set when if the window
triggers a relayout on it's own, so it doesn't call into window manager
all the time.
- Set the insets of the docked divider to empty so we don't trigger a
layout when we are just moving it - it doesn't need it in any case.
- Send a window move message to the divider when it moved
- Update attach info in all move cases, update light center
The whole resize operation now only takes around 4ms per frame, and
leaves a lot more resources for the apps to do configuration changes.
Bug: 25015474
Change-Id: Ica48129570a0fc858a89c21f46abf3442efb0224
- Communicate the resize mode to ViewRootImpl. If it is a docked
divider resize, do not call relayout for every traversal.
- Do not call Task.resizeWindows() unconditionally when changing
Stack bounds. It might be just a move.
- However, not calling relayout breaks layout bounds while
relaunching. To fix that, do the following:
-- Inform ViewRootImpl that the activity just relaunched, and force
a relayout call in the next traversal so the client can pick up
the unfrozen bounds.
-- When unfreezing the bounds, cause a traversal in window manager.
Bug: 25015474
Change-Id: Iab9a445dabce4f6ec1e25957038fe40a4be65246
InputMethodManager#setAdditionalInputMethodSubtypes() is the only API
that allows IMEs to add and remove additional subtypes. However, due to
a bug, there is no way to clear the last entry of additional subtypes
because the API in question does nothing if the given array is emptry.
With this CL, an empty array is treated as a valid input.
This CL also adds a JavaDoc comment about a possible way to work around
this limitation in Android M and prior devices.
Bug: 26298984
Change-Id: I3731f84531247d071d9d88861e9079afc244a4e8
- Expanding drop targets to indicate the size of the to-be docked window
- Fixing animation when dropping task
- Fixing drag view z order
- Fixes issue where the dock divider position in WM is not exact
- Requiring user to move the slop distance before accepting drops
Change-Id: I2f6eab504db7126c19e0c680629e89a39e7512e3
Avoids infinite invalidations caused by re-use of scrollbar drawable
during a single draw() pass. Does not address the general problem of
drawable reuse causing unnecessary invalidations as a result of calls
to setBounds() invoking invalidateSelf().
Bug: 26533725
Change-Id: I99e9c2dfe4ddfc833569e40e7268dcb03e931fc9
This CL introduces a API variant of IC#deleteSurroundingText(), named
IC#deleteSurroundingTextInCodePoints(). Major differences from
the existing one are:
- The lengths are supplied in code points rather than code units.
- This API does nothing if there are one or more invalid surrogate
pairs in the requested range. (Failure Atomicity)
Note that due to the asynchronous nature of the input method
architecture in Android, implementing the same logic in the input method
side basically ends up with unreliable and unpredictable results.
Bug: 6526420
Change-Id: I7f6a2c5d3d52079ae71623fd5e40d60c688dd5fb
This reverts commit e5e59c6da4.
Drawables expect to be able to call invalidateSelf() during
draw() to pump animation frames. We shouldn't break this.
Bug: 26533725
Change-Id: Ibe2871f2622faf836637225fc1e3e6f0ca6def47
Keyboard shortcuts are requested via WindowManager, and
the request pipes through to the view root and the window
callback.
Bug: 22405482
Change-Id: Ic0071e91c7b554be3ac9df71e9539ee8a60e822e
Cancel() has apparently never worked. Calling cancel() results
in the startTime being set to Long.MIN_VALUE. In theory, this means that
on the next animation frame (getTransformation()), the elapsed time
(currentTime - startTime) should result in a large positive number, which
is way more than needed to prove that the elapsed fraction is >1 and
therefore that the animation has ended. But in practice, anything subtracting
MIN_VALUE will result in a large negative number due to Long wraparound, so the
end check fails and the animation continues. Forever.
Moreover, event fixing the cancel issue results in a repeating animation
continuing to repeat, because the logic was never there to determine whether
a repeating animation was canceled.
This fix addresses both issues, but in a minimal way. The risk in fixing this
for real is changing the behavior of cancel in a way that existing apps would not
expect. For example, it's weird that cancel causes one more frame to run. And even weirder
that it does so with a negative elapsed duration (resulting in an animation fraction of 0).
But I wouldn't want to change that behavior for fear that I'd break apps who rely on
that weird behavior.
Instead, there's a simple check for for the "expired" check and the "repeat?" check that
sees whether the startTime has the magic value of MIN_VALUE, which should only happen
when an animation has been canceled. If this is the case, it ensures that the animation ends.
For real.
Issue #24984018 canceled animation runs forever
Change-Id: Ia137eb04bd7df3976a4d9cef86fd39a78dc56f39
UiAutomationConnection.clearWindowContentFrameStats method currently clears
calling identity before calling mAccessibilityManager.getWindowToken. This
doesn't work properly when a call is made by a secondary user, because it
wouldn't pass a check in getWindowToken. This is now fixed by explicitly
passing ID of the calling user.
Bug: 26498396
Change-Id: I8f0cdde33e18f04adb1833c6c0d0c329de921018
Prevents infinite invalidation loop when reusing a drawable asset within
a single draw() call. Also reduces unnecessary extra invalidations due to
drawable setters (ex. setBounds()) being called during draw().
Bug: 26329675
Change-Id: I31b3c99e8efd4193415cc562a84c8939a2f56c2d
(cherry picked from commit 8cda8e9159)
- Move DividerSnapAlgorithm to com.android.internal, also move
some utility stuff into DividerUtils which is used from both
SystemUI and window manager
- When the screen rotation changes, rotate the stacks like before
but then also snap the docked stack to a valid snap position.
Change-Id: I9e1aa13f42f398a25c9016e6f20395ee212e405b
- Move DividerSnapAlgorithm to com.android.internal, also move
some utility stuff into DividerUtils which is used from both
SystemUI and window manager
- When the screen rotation changes, rotate the stacks like before
but then also snap the docked stack to a valid snap position.
Change-Id: Ifb0c65dfbdfca2343a76b12de982c0701fe0c3ab
This is a part of effort to reduce the number of dependencies on @hide
method in BaseInputConnection.
Currently BaseInputConnection#sendKeyEvent() cannot be implemented
without relying on @hide internal fields in InputMethodManager.
This is not ideal because app developers cannot implement their own
InputConnection without relying on BaseInputConnection. If this
functionality needs to be exposed to app developers anyway, then it
should be a public API.
Bug: 24688781
Change-Id: Ib5ea8131de5ba792b10e1a4e51b4d163cf3649e3
We allowed activities to move to any stack, but that's too much
freedom. Instead we only allow them to move from freeform stack to a
fullscreen stack.
Change-Id: I04de9bbf18cf4431d7bd34d6c727de82802661ef
This is a part of effort to reduce the number of dependencies on @hide
method in BaseInputConnection.
In a nutshell, IMM#notifyUserAction() and IMM#setFullscreenMode() are
something that IME developers should not care about, hence ideally
BaseInputConnection should not rely on them.
IMM#setFullscreenMode():
This @hide method is just for updating an internal state flag about
whether the current IME is in full screen mode or not.
IMM#notifyUserAction():
This @hide methods is just for sending a signal to IMMS so that IME
rotation list (for globe button) can be updated based on the user's
action.
Depending on those @hide methods in BaseInputConnection is problematic
because:
A. We cannot implement InputConnection without relying on
BaseInputConnection, which forces developers to use Editable to
maintain internal text representations.
B. If BaseInputConnection#commitText is overridden,
those @hide method calls can be missed.
C. Currently some method calls of BaseInputConnection() even from
application itself can trigger those @hide method calls. Ideally
those internal events can be dispatched only when those methods are
called from the input method rather than the application itself.
With this CL, those @hide API calls will be moved from
BaseInputConnection to ControlledInputConnectionWrapper so that
developers can forget about them.
Note that BaseInputConnection#sendKeyEvent() still relies on @hide
internal details of IMM. It should be addressed in a subsequent CL.
Bug: 24688781
Change-Id: I571d6cc9c6e461d8994aa7496e7e18be13766411
The change has all the platform changes required to support
modifications in the navbar dimensions and custom icons in car mode.
The UX is not frozen yet, but have placeholder resources provided
by android auto UX engineers.
The change assumes that the car mode configuration is known to the
WindowManagerService and uses its current ui mode to request the
latest from the policy (PhoneWindowManager.java). The change is
modeled on the way rotation is handled, where the Policy knows the
different view attributes for uiMode and just returns back the
window sizes based on the current uiMode requested. The policy does
know the current uiMode, but the order of when that changes is not
deterministic [from logs it does happen before any request to update
UI occurs, but guess that could change].
Bug: 25996809
Change-Id: Ia46cbe5096382d26c9eb8ec74cf59a059b767edb
As a preparation work for Bug 6526420, where we are going to
introduce a new variant of IC#deleteSurroundingText(), this CL attempts
to clarify about the expected behavior of IC#deleteSurroundingText().
With this CL, the expected behavior when the number of existing
characters is smaller than the number of characters to be deleted is
now documented by simply describing the current behavior of
BaseInputConnection, that is, IC#deleteSurroundingText() will delete
characters until it deletes requested number of characters in code units
or reaches to an end.
This is purely documentation work. No behavior change is intended.
Bug: 6526420
Change-Id: I7280dec07e1c043bd26b3b12fd866b9d8b6186cc
This adjusts the code for measuring and laying out dialog windows, which
used display dimensions as a basis for calculating the dialog
dimensions. Because of this dialogs would be too large in multi window
mode, where the parent bounds are far smaller than full display. This
switches to using dimensions for configuration received from activity
manager.
Mind, this is still not working as needed, because the resources return
minimal size of the dialog as if it was displayed on a full display,
rather than within activity bounds.
The CL also introduces better logging tags in ViewRootImpl and
DecorView. These normal approach works reasonably well when there is a
single activity on the display. However, when multiple windows are
displayed, it becomes impossible to determine which view root/decor view
logged what. This adds a suffix, that allows to identify the owner.
Bug: 26251921
Change-Id: I515a1ff9a81ee5ad086773196db71915e88a25eb
