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
- 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 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
When dismissing the docked or fullscreen stack, a dim layer is
introduced for a nicer visual effect.
Change-Id: I9f12e331e978208aa9fd9e9883b3c8a36d4da3a0
- Add the ability to add a listener when the existence of the
docked stack changes.
- Register SystemUI as such a listener and switch the recents
button asset when docked stack exists.
Change-Id: I05350878c5adc7ad9f0399f0c42d8d1615d44d02
Allows an activity to always be focusable regardless of if it is in a
stack whose activities are normally not focusable. For example, activities
in pinned stack aren't focusable. This flag allows them to be focusable.
Also, changed ActivityInfo.#{resizeable, supportsPip} to use flags.
Bug: 26273032
Bug: 26034613
Change-Id: I8c63e6d3256757e2e6931e08b8a65269f5169d35
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
Caching constructors can cause problems for dynamically loaded code if
the same class name appears in more than on classloader. Before using
cached constructors, verifty that they come from a valid classloader, i.e.
one that appears in the classloader chain of the current contexts
classloader. Remove ones that do not from the map to allow the associated
classes to be unloaded in case they're no longer in use.
Bug: 21690610
Change-Id: I84f2894cd03a5dc0c33aed9cd710e4a1f6d9515f
Move requestDropPermissions from DragEvent to Activity.
Permissions will be granted using UriPermissionOwner
associated with this activity and revoked when the activity
is destroyed (if DropPermissions.release is not called before that).
Change-Id: Ic8f8fc3f56f57e83b9bc34ae8c96d82c2c9c4e1d
When resizing SurfaceView along with a main application window,
we want to be able to update the crop of the SurfaceView without waiting
for a buffer at a new size. If we fail to do so the SurfaceView may
extend beyond the edge of the host surface.
Bug: 26010823
Change-Id: I3bb52f82c02bb729a2494a3a43b9654d9aae9532
The notification children didn't respect the given dimensions
when measuring and was simply measuring itself as high as desired.
This lead to a bug where the parent could crash when a layer was
set on it.
We are now measuring the container at most with the height of
the given size and let children draw over our view bounds.
In oder to still allow touch in those regions we also
override the touch rect.
This also simplifies the rest of the touch handling.
Bug: 26159274
Change-Id: I728553a6386455e6632e2511be8a3e7cb447e89b
