Changes activity manager and window manager to use resizeMode
as defined by ActivityInfo#resizeMode instead of a boolean.
Bug: 26774816
Change-Id: I8cef46d9fba6bfdd21df7da63ed5d5330ad03d4b
This is the first UI iteration which contains elements for
displaying the keyboard shortcuts. Is is by no means final,
the following items (and maybe more) still need to be actioned:
* no UI for phone
* no view for system shortcuts (which contain icons)
* the shortcut items container needs a custom layout which
needs to wrap and right align elements (prototype done)
* find or build an util which can produce human readable
names of the baseCharacter and the modifiers (so far I
found a few functions, none of them good)
* not pixel-perfect
* the scrollbar does not show
* the last separator (before the DONE button) is not
visible
Change-Id: I0d191e9516ab8f4728f40b3eefe9d854249ee7a8
Removed and updated some obsolete documentation about window
content. Stated the purpose of accessibility. Updated docs
for getTextSelection to include its ability to get cursor
position. Clarified wording for accessibility overlays.
Change-Id: Iaa11b499c2b7ece12ca182d336376d97b961b54f
Adding a flag to AccessibilityServiceInfo that only works
for UIAutomator that supresses other services. This flag
is set by default for UIAutomation to match the current
behavior, but tests may clear the flag and enable other
services.
Needed to improve cts coverage of AccessibilityService.
Bug: 26592034
Change-Id: Icfc2833c1bd6546a22a169008d88a6b15e83989c
When dismissing the docked stack, the fullscreen stack stayed in drag
resize mode because it got a relayout, but because the bounds didn't
change (it switches to the fullscreen layout a bit earlier) it never
called WM.relayoutWindow, so it stayed in drag resize mode indefinitely.
To fix this, introduce forceRelayout in Window.resized(), which makes
sure the client always calls relayoutWindow. Set this to true whenever
drag resizing is changing.
For some very weird reason this also broke that home button was not
responding anymore.
Bug: 26806532
Change-Id: I4b39c1c419a166aa7093c31226f2a4915f642328
We used to have a condition to start drawing only in the second traversal,
which added a delay of about 10-15ms. We believe that we don't need this
anymore, because we have other means of synchronizing the app transition
animation with the app drawing - we wait for all surfaces to be drawn
in window manager.
Bug: 21035872
Change-Id: I5094a1377817dc7e0a2392cc8f522e99cd7b4d6e
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
