View attachment calls jumpDrawablesToCurrentState(), so the view state
needs to be set up prior to attachment. For views that are already
attached but are being moved to a new position, manually jump.
Cleans up comments in methods that were modified.
Bug: 29978498
Change-Id: Ica27b2c60ad7ee98b9d1e4912c4f8b8c248af88d
Had to revert the previous CL that referenced AbsListView
in the Javadocs. This one is using ListView which is the right
class, since that's where those remotable public methods are
defined.
Change-Id: Ibfa68f2c96f0440d46ba192c7c378188d4f8af34
- Record undo operating even when composing text.
- Combine several edits in a batch edit into single undo
operation.
- Freeze undo state on commitCorrection.
- Freeze undo state on switching insert/delete to
delete/insert.
- Merge replace with delete or replace if they are for the
same region when composing text.
- Merge insertion with replace when they can be single
insertion when composing text.
- Perform drag and drop in batch edit.
Bug: 28588666
Change-Id: I37da124b3a05b322769e4d97fb0ce074aa4fc358
Layout.getDesiredWidth measured text with TextDirectionHeuristics.LTR,
whereas the real calculations used the active direction heuristic set
in the TextView instance. This CL uses the same heuristics for both of
them by passing the value to Layout.getDesiredWidth function.
Bug: 28845953
Change-Id: I68d23f55fe5a86255d62e83bc62df38a047e4bca
Currently Toolbar lays out all children based on its
minHeight (if set). If that minHeight is larger than
the Toolbar height, then the children are laid out larger
than the Toolbar and clipped.
This CL fixes it back by capping the alignment height.
BUG: 29049143
Change-Id: Ia3389a906b132bb0a2ae41b27116c00744d0ddf4
When we want the WindowManager to clip our requested width/height
to the display frame, we need to pass DISPLAY_CLIP_VERTICAL/HORIZONTAL.
It seems this behavior was unintentionally applied without this flag
in previous releases.
Bug: 29602363
Change-Id: Ib98060e36efde0dbaabb59a758da5374035dbb62
It turns out that we can let the system to call
InputMethodService#exposeContent(InputContentInfo, EditorInfo), which
added in my previous CL [1], during the IME is calling
InputConnection#commitContent() as follows.
[IME]
InputContentInfo contentInfo = new InputContentInfo(
contentUri,
new ClipDescription(description, new String[]{mimeType}),
linkUrl);
getCurrentInputConnection().commitContent(
inputContentInfo,
InputConnection.INPUT_CONTENT_GRANT_READ_URI_PERMISSION,
null);
[App]
try {
contentInfo.requestPermission();
// Load inputContentInfo.getContentUri() here.
} finally {
contentInfo.releasePermission();
}
This gives us flexibility to let InputConnection#commitContent() do all
the magic for IME developers like other APIs such as
Context#startActivity(), rather than asking them to call one more API to
grant a temporary URI permission like a scenario where
Context#grantUriPermission() is used.
[1]: I2772889ca01f2ecb2cdeed4e04a9319bdf7bc5a6
25e0813e6e
Bug: 29450031
Change-Id: I99536cd58c9984af30b0bafb4a1dd25a26634a2d
