The primary goal of this CL is to enable application developers to
provide more context-based language (locale) information for IME
developers so that users can be benefited by more natural text input
experience.
As of API Level 23, there are several APIs that allow IMEs to retrieve
locale/country related information.
- Locale#getDefault()
- Configuration#locale
- LocaleSpan#getLocale()
- SubscriptionInfo#getCountryIso()
However, only LocaleSpan#getLocale() can be used to pass application
specific languge (locale) context from applications to IMEs. Also
LocaleSpan is not designed to be used per input-context. We want to
have something in EditorInfo and LocaleList would be the right thing.
Although default implementation of TextView#onCreateInputConnection()
starts filling EditorInfo#localeList with TextView#getTextLocales() by
this CL, application developers are encouraged to provide its own
LocaleList when they are confident that the user want to use a
certain (set) of language(s).
For instance, a chat application may be able to guess what language will
be used in the conversation before the user start typing. At least it
should be able to remember the last used language for each conversation.
Another instance would be "From" and "To" EditText fields in a
translation app. Those fields should have different LocaleList based on
the languages that the user want to translate from and to.
Bug: 22859862
Change-Id: I77db5b99a7cf745d800db75baf135bb60ad04820
So we don't have to implement crazy magic when one app requests
drawing the status bar by itself, and the other doesn't in split
mode.
Bug: 24365214
Change-Id: I1f6a0efd0865b784402055e008da2f31e626f163
When an activity is moved to a stack using the
ActivityStack#moveActivityToStack API a new task is created to
hold the activity in the stack. However, when the new task is
created in the window manager side it uses the stack id of the
previous stack the activity was in. We now pass the stack to use
from activity manager to window manager.
Bug: 25987309
Bug: 25961636
Change-Id: Iecc71f6d9b3e70a8d88e134b42f7532ba5327bad
Add a TYPE_QS_DIALOG window type, that is in the same layer as
apps and dialogs and such. It is guarded by having a token
that is granted by SysUI after a click has occured. If the
app shows a dialog before listening finishes (QS closes) then
the token will stay granted until the tile is removed by the
user, otherwise the token will be removed immediately to avoid
later dialogs.
Also fix a couple tiny TileService issues:
- Stop/Start listening reversed
- Fix javadoc referencing wrong action
Change-Id: Iedcdd5fd9a2af2b33eb7f6f17bb0e6c997879876
The body of {@code} must not be HTML escaped. This is one of
several changes that fix the source in conjunction with a
doclava fix.
Bug: 25757239
Change-Id: Ib38a0fa2dd2a3d68e467f78a812071e763d7e881
Previously the notification header had a seperate implementation
in SystemUI from which the platform implementation was derived.
Now that everything is in the framework, we’re migrating the
implementation for notification groups.ß
Change-Id: Ia61a75bd6c85e1805d4364a9e7e4587a020c1271
In order to ensure reusability and separate inflation,
the expand touch listener is now moved to its view.
Change-Id: I363fc4ae2c68833dc9f1258398ec9ad3bf44dc7f
Now first the App name shrinks up to a minumum and then
the subtext shrinks. This way the expand button is always
visible.
Change-Id: Ibda8e9efbac7119cc31ce4c129be33a7a192f974
We achieve the removal by notifying System UI about the visibility of
the dock divider. This way System UI can change visibility of the root
view, which in turn will cause the WMS to destroy or create the surface
as necessary.
Bug: 25844096
Bug: 25683717
Change-Id: Idbc33368db697a059af49106dfadb80c3d7d06c1
This patch does the following things:
- add new graphic assets of large icons for accessibility needs
(imported from ChromeOS data)
- add the logic to choose the set of normal icons or accessibility icons
- make InputManagerService to observe the settings change, so that
it can reload the new resources
This patch misses non-1x graphic though, because ChromeOS doesn't
have such data.
Bug: 25778857
Change-Id: Ia5f95d47f50b3f6eea555c3af8069bc6bae0b400
Refactors the menu helper classes. Both classes now implement a common
MenuHelper interface, which eliminates the need to keep separate helpers
on PhoneWindow and unifies the DecorView showContextMenuForChild()
implementations.
We now explicitly dismiss any previously shown context menu before showing
a new context menu. Previously we relied on the modal nature of the dialog
context menu to prevent multiple menus from being opened at once, but this
is no longer reliable with popup context menus.
Bug: 25656520
Change-Id: Idab3daa6d6888f803f2e33660fe1dd488e4c28d1
As a preparation to fix Bug 25373872, this CL introduces an additional
int parameter into the following two methods
- IInputMethodManager.startInput()
- IInputMethodManager.windowGainedFocus()
so that IMMS can know why IMM needs to start input. Currently the
"startInputReason" parameter is used only for debug message only when
the OS is rebuilt with flipping IMMS#DEBUG to true. Basically this
should have no impact in production builds except for a tiny overhead
of having one int parameter in some internal IPC calls.
Note that since 7663d80f6b [1] basically
IMMS#windowGainedFocus() has been a superset of IMMS#startInput().
Hence we should pass to "startInputReason" parameter to
IMMS#windowGainedFocus() as well as IMMS#startInput().
[1]: Icb58bef75ef4bf9979f3e2ba88cea20db2e2c3fb
Bug: 25373872
Change-Id: Ia1fe120af7d71495c5f3a4fc0ec6390efb8240ca
- Adding “focused” stack state to support paging
- Changing the paging to match UX spec (only auto-page after the first
tap)
- Removing old header focus animation
Change-Id: Id72825b8a1b1c0a2238ee184a6695b13c1d8cb1c
Previously we were lax about whether an app needed to call
setLayoutParams() when changing layout param (ex. height), but now
failing to call set will break layout.
Bug: 25801251
Bug: 25836190
Change-Id: I4431526ab38b9e3cbdf3553e41db6251d2a7fbc3
The new method allows changing the drag shadow image
while the drag is in process.
It has to be called on a View in the same window (under the
same ViewRootImpl) that the view which started the drag.
Bug: 25520420
Change-Id: I57e752626a4a6a86d42c597c09dbd7ec77f42f30
View.cancelDragAndDrop cancels a drag operation initiated by
View.startDragAndDrop.
It has to be called on a View in the same window (under the
same ViewRootImpl) that the view which started the drag.
Bug: 24415683
Change-Id: If9a265fd8cc4d26b207d582d0d02d5c9ae78eba1
We need a more sophisticated touch handling to support overlaying the
caption. The touch events need to be routed in following order:
close/maximize buttons, application content, caption dragging.
Bug: 25486369
Change-Id: I9d4e971fb055c217c0bd83f0490fb42a5c22e93b
This in preparation to adding a new method to cancel an
ongoing drag. This method cannot be called cancelDrag,
stopDrag or endDrag because these names are already
taken by View-derived classes in the framework or in
important apps.
Change-Id: Ie21a778c3253b2d526c0c1bcc423c374ca70ee01
This reverts commit 93cf731b26.
This is required because adding View.cancelDrag conflicts with existing app code.
Change-Id: I323fc5d2144266781d3168fe033c53cb5b37050e
Traditionally, when a view called requestLayout it would force
recursive requestLayout calls for all parent views up the
hierarchy. This meant that there was no way to determine at traversal
time whether a parent view itself needed layout, or if just one of its
descendants did.
Add a ViewParent method requestPartialLayoutForChild(View). This lets
a caller state that a particular child of a given parent needs a
remeasure and relayout at its current measured size and position
within that parent. This can help prevent the full-tree relayout often
caused by otherwise trivial changes. Partial layouts are processed
after any pending "full" relayout during ViewRoot traversals, but
before drawing.
Add a ViewGroup method requestLayoutForChild(View). This lets a
ViewGroup decide whether it is more appropriate to request a
traditional relayout or a partial layout for itself or just the child
that changed.
Add a ViewParent method findDependentLayoutAxes. This allows a caller
to check if the ViewParent's layout is dependent on a specific direct
child view along one or both axes. Called recursively, this can be
used to determine if a change in a child view can be isolated to a
partial layout, even if its direct parent's own layout is tied to its
other ancestors. (e.g. MATCH_PARENT, LinearLayout weights)
Implement ViewGroup#requestPartialLayoutForChild to call new
ViewParent method findDependentLayoutAxes and based on the result,
either request a full layout for itself or a partial layout for the
child in question.
Implement findDependentLayoutAxes for common framework ViewGroups. A
private implementation in ViewGroup is available for use by framework
classes that will deal with basic LayoutParams. These implementations
specifically check for derived LayoutParams classes and abort the
optimization if they find something beyond their expected parameter
types.
Change-Id: I0a1a9b79293d17d4fae8d9892b96d3586f9401ae
'dumpsys input_method' does not generate useful information for
InputMethodManager#mIInputContext. It is currently just a default
output of Object#toString().
This CL overrides ControlledInputConnectionWrapper#toString() so that
we can easily understand whether this connection is accepting API calls
from the IME or silently droping those API calls. Note that
ControlledInputConnectionWrapper is not exposed to developers so
overriding #toString() has no effect for application developers.
Bug: 25373872
Change-Id: I89b9d4e15bc1569817bab4d1be429ac6e0462f14
As a preparation to fix Bug 25373872, this introduce an additional
parameter to IInputMethodClient.unbind() so that the IME client
that is running in the application side can know why IMMS needs
to unbind the connection.
In future the "unbindReason" parameter is supposed to be used to
optimize the behavior of IMM runtime running in the application process,
but for now it is not used unless we build the sytem with debug message
enabled. Hence there should be no user-visible change with this CL.
Bug: 25373872
Change-Id: I74e83c8ca9d1d53e31e9c7b5bda1dec6274e59c8
View.cancelDrag cancels a drag operation initiated by
View.startDrag.
It has to be called on a View in the same window (under the
same ViewRootImpl) that the view which started the drag.
Bug: 24415683
Change-Id: Iae5ff3534b6c747ae174f170fdd01ff4d3b1c312
Recents to freeform animation must hang on the first frame and inform
Recents to hide its views. This mirrors the transition from freeform
to Recents, where the animation needs to hang on the last frame.
We need a special window flag for recents to force a redraw after the
animation launches. At this point Recents will become not visible
from the perspective of the activity manager, which would prevent
further drawing. We make recents ignore that and instead depend on
window visibility which will change after recents exit animation
finishes.
Bug: 24913782
Change-Id: Ief743b7e6fcebb3d8789d4745fb122ac607c1cf0
Also separates magnification state and touch event handling. Moves
callbacks for window manager changes and display state changes into
the magnification controller.
Bug: 22718911
Change-Id: I3a8ba060a07d8f1f51856855a5f85601766fd45d
Fast rounding doesn't work for negative values, so use Math.round()
where we might encounter negative values. Use Math.floor() and ceil()
for rounding down and up, respectively.
Bug: 25695621
Change-Id: I94831b8eb7552fc24cbe5808e923de1674d8ba6d
As a preparation to fix Bug 25373872, this CL does a mechanical
code clean-ups. Literally there is no behavior change.
Bug: 24504456
Change-Id: I6e3062bda17e748a3c5f1450d6752239dd260520
On some chips, SurfaceControl.setSize will not take effect for several
frames. We have to also do a updateSurface/invalidate (which destroys
and creates the EGLSurface) to get the size right.
Keep track of SurfaceControl size changes in window manager, and pass
that to ViewRootImpl, so that a updateSurface is done either the surface
itself or its size is changed.
Note that we don't use frame size change to trigger updateSurface, because
frame size could be different from the surface size that window manager set.
For example during drag resizing, the surface size is fullscreen although
frame size changes constantly. Doing updateSurface upon frame size change
could cause us to do many unnecessary updateSurface.
bug: 25583942
Change-Id: I1989613a187bb6ef1c179bd2800c6a7b01fcdb3a
Bug: 25411780
Partial-revert for now, reopened b/22565656 to
deal with the memory use in a followup
Change-Id: I1ec636bc811a85eb2dc4f8c91562dc81b6261355
