When a content URI is dropped onto EditText, it tries making sense
of the contents, and in the process it accesses the content provider.
If this content provider requires a permission grant, SecurityException
occurs.
This fix does two things:
1. Editor.onDrop now requests DropPermissions and releases is
when it is done. This required the introduction of a new hidden method
DropPermissions.takeTransient, because the existing method required
access to an Activity instance.
2. If the drag originator neglected to allow the permission grant,
DropPermission request would not help, so a try/catch block
is added to Editor.onDrop to avoid breaking the recipient app.
Bug: 26694948
Change-Id: I714429a507e62c83a150d91fbcdee791bced3ad3
This CL fixes a bug in View#requestRectangleOnScreen where the
position was not being moved from child's coordinate space to
the parent's coordinate space properly.
I've also added more documentation to clarify the API.
Bug: 25787435
Change-Id: Id821fa178e04016f6fb830d0bd2abde046581465
This CL introduces IWindow.updatePointerIcon method.
When the drag is complete, this method is called on the window
directly under the pointer.
Same method can be used in the future to update mouse pointer
when a window appears or disappears.
Bug: 24415739
Change-Id: Ia7b0522448cb3cd754da5e24696060d3b3bf2e50
Mouse pointer is set to STYLE_GRAB when the drag has started and
reset to STYLE_DEFAULT when the drag has ended.
Resetting the pointer shape to the one defined by an underlying
view will be handled in a separate patch.
Bug: 24415739
Change-Id: I8df0a08c5701a34a48f10ec6b43c2cf2e6362d61
Also updates nullability annotations for methods called during touch
dispatch. Verifies that TouchTarget and HoverTarget are not recycled
multiple times.
Bug: 26611563
Change-Id: Ica5ff18e18b325b12fe72b8ca145443b25625fe4
My previous commit [1] introduced a new XML attribute "languageTag" for
subtypes but forgot to initialize InputMethodSubtype object with that
attribute. As a result, InputMethodSubtype#getLanguageTag() has always
returned null even if "languageTag" attribute is specified.
[1]: I77db5b99a7cf745d800db75baf135bb60ad04820
8d6eeb01df
With this CL, InputMethodSubtype#getLanguageTag() starts returning the
value specified in the XML resource.
Bug: 22859862
Change-Id: I251d3d999afd13c0d618f2cb59e8ed3d47f21c98
On the lockscreen we were unintentionally disabling single clicks
on the media buttons while we only wanted to disallow it for the
notification header. This is now fixed by explicitly checking if
we are clicking on the notification header.
Bug: 26325096
Change-Id: I044f25ac3216b98c7769c31d09d19f801a437194
Rather than associate the keyboard layout solely with a specific
hardware model, we should also associate it with a given IME subtype.
This lets users switch between various languages and have the
keyboard change in unison with them so they can use the appropriate
layouts for each language.
This change adds initial support for associating IME subtypes and
keyboard layouts. We still need to:
- Remove support for the old style of layout association once the
Settings apps begins to use the new APIs
- Automatically select an appropriate layout based on the given
subtype (or set a reasonable universal default such as QWERTY)
Bug: 25752812
Change-Id: Ie88ce1ab77dbfe03ab51d89c1dc9e0a7ddbb3216
During the initial attempt to support automatic language switching in
LatinIME, it turns out that the current EditorInfo#locales is difficult
to use and even confusing in some situations. Based on that
experience, this CL changes as follows:
* Rename EditorInfo#locales to EditorInfo#hintLocales:
This is mainly to avoid possible confusion when to set this. We want
to make it clear that having non-empty LocaleList there is a clear
signal that the user would switch to certain languages regardless of
the currently selected input method subtype.
* Make EditorInfo#hintLocales nullable:
Previously marshaling EditorInfor causes NPE when
EditorInfo#hintLocales is null. This CL relaxes such a restriction.
* Introduce TextView#{set, get}ImeHintLocales():
In the previous implementation [1], we just copied
TextView#getTextLocales() into EditorInfo. This is, however, does not
work well because it is no more or less than the default value. If
LatinIME supports automatic language switching, having the default
value in EditorInfo actually means that whenever you focus in a new
text field, the keyboard language is reset to the default locale.
In order to make this "hint" useful for IME developers, this "hint"
should be specified only when the application developers are confident
to do so.
[1]: I738ffaaf07091d8b980f8bfc6e16227fcb85a96a
0445fdf321
Bug: 22859862
Change-Id: I0a730011874ea8d01e50624ed3f1ecd197d05f94
No functional changes. The default behavior for overridden methods is
@inheritDoc, so a standalone annotation is not necessary.
Change-Id: I3ace1989e9035ecf3cf8f7acc5391de1c1ff7c65
This is for Views that have special mouse dragging handling. e.g.
TextView invokes text selection on mouse dragging, so it cannot be
scrolled by mouse dragging.
This provides such Views or ViewGroups a last resort to scroll as we
don't assume that all devices have touch panel, touch pad, or mouse
wheel.
Bug: 20016455
Change-Id: I68a13258a50b5e4ea681b2576da6000a0bb3fa65
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