IME can use this method to redo spell checking after it has learned a
new user dictionary word.
Bug: 166304720
Test: atest CtsInputMethodTestCases:SpellCheckerTest
Change-Id: I956cd46f25bb77b7e1a6a3e1478c0d7efa1a056a
Bug: 174932174
Test: I solemnly swear I tested this conflict resolution.
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Change-Id: I9262a08ffc1ccede8e519d0eed90ed2bfcf0232c
As general background, OWNERS files expedite code reviews by helping
code authors quickly find relevant reviewers, and they also ensure
that stakeholders are involved in code changes in their areas.
Some teams under frameworks/base/ have been using OWNERS files
successfully for many years, and we're ready to expand them to cover
more areas. Here's the historical coverage statistics for the last
two years of changes before these new OWNERS changes land:
-- 56% of changes are fully covered by OWNERS
-- 17% of changes are partially covered by OWNERS
-- 25% of changes have no OWNERS coverage
Working closely with team leads, we've now identified clear OWNERS on
a per-package basis, and we're using "include" directives whenever
possible to to simplify future maintenance. With this extensive
effort, we've now improved our coverage as follows:
-- 98% of changes are fully covered by OWNERS
-- 1% of changes are partially covered by OWNERS
-- 1% of changes have no OWNERS coverage
This specific change is automatically generated by a script from
detailed ownership information confirmed by team leads.
Bug: 174932174
Test: manual
Exempt-From-Owner-Approval: refactoring with team leads buy-in
Merged-In: I9789c97c1de8e5d962b48c29c57d82fe83729eba
Change-Id: I9789c97c1de8e5d962b48c29c57d82fe83729eba
* changes:
Integrate the SuggestSelection API in TextView
Introduce TextSelection.Builder.setIncludeTextClassification and TextSelection.getTextClassification()
Currently, fonts are loaded in Zygote.
This CL adds a preparation to switch it to system server and
bindApplication(), so that system server will be able to update font map
at runtime.
(1) Zygote will be initialized without fonts.
(2) System server will maintain a serialized font map in ashmem.
(3) Apps will load font map from the ashmem in bindApplication().
The change is guarded by Typeface.ENABLE_LAZY_TYPEFACE_INITIALIZATION,
and the new behavior is disabled by default.
I tested with ENABLE_LAZY_TYPEFACE_INITIALIZATION = true.
Bug: 172891184
Test: atest FrameworksCoreTests:TypefaceTest
Test: atest CtsGraphicsTestCases
Test: atest CtsTextTestCases
Test: atest CtsWidgetTestCases
Change-Id: I40832962a4b27f6160c4dc6268689c52f6a4dd33
Because we use suppliers for TextClassifier, the
mTextClassificationHelper::isTextClassifierDestroyed actually always
returns false. Always swallows the exception temporarily to unblock
other teams. We may want to keep a reference of the TCSession in the
AsyncTask and check it ideally (b/174300371).
Bug: 174300371
Fix: 172627102
Test: atest AccessibilityTextTraversalTest.java
Change-Id: I5988db992956d666e24e608cd99d4fc87fd6820b
NumberPicker uses AccessibilityNodeProvider. When creating
AccessibilityNodeInfo, the accessibility focus boolean property should
be set. Otherwise, talkback doesn't think it is accessibility focused
and won't speak the usage hint.
Fix: b/170267520
Test: tested manully with talkback on. Unit test added.
Change-Id: Icd280bce4a394ccff2a60314518109c07808338d
This helps AccessibilityService to detect if an EditText is capable of
showing an auto complete or not.
Bug: 173744816
Bug: 150827488
Test: manual.
Change-Id: I47636bf9491fdbfc1fbca3c24f4ea5a551578cfd
After ag/12036126, the AsyncTask may throw RuntimeException if we
destroy the TCSession before it is done. However, this kind of Exception
should be swallowed silently because we do not need the result anymore.
In b/172627102, the test fails because we perform a cut action to the
text immediately after we trigger a selection. The cut action will
destroy and TCSession and thus cause a session-already-destroyed
Exception in the AsyncTask. With this, we will check whether the Text
Classifier has already been destroyed and therefore can fix it.
Bug: 172627102
Fix: 172627102
Test: atest AccessibilityTextTraversalTest.java
Change-Id: Ia2ca04a06e97858cd897e5d35f707f5edeee56cf
Use the weight adjustment instead of a binary on/off
Bug: b/170966021, b/110991537
Test: Manual with bold text toggle,
atest CtsWidgetTestCases:TextViewTest, CtsTextTestCases
Change-Id: Ic60ca7eed497bfc798d653a07824a9e5fabe5bc2
Having a hidden abstract method for a class that can be extended
means that public implementors cannot implement these hidden methods
posing a risk that custom implementations will not have required
abstract methods resulting in an exception.
Bug: 151134792
Test: make update-api
Change-Id: I758d12465fabc671be19bedeeceb16885de23c87
Merged-In: I758d12465fabc671be19bedeeceb16885de23c87
Exempt-From-Owner-Approval: large scale suppression of existing issues,
no-op in terms of behavior
Previously onReceiveContent() would only invoke the app-configured
callback if the MIME type of the content matched one of the declared
MIME types for the callback. This change updates onReceiveContent()
to always invoke the listener if one is set (regardless of the MIME
type of the content). To delegate processing to the platform, the
app's listener can return some or all of the passed-in content. To
make this easy for apps to implement, the Payload class and its
Builder now provide some convenience methods to conditionally
partition the content.
Reasons for this change:
* Checking the MIME types could be an expensive operation. On SDKs prior
to S, ClipData does not keep track of the MIME types of individual
items, so for a ClipData that contains multiple items, checking the MIME
types requires making at least one RPC call per item.
* Allowing the listener to delegate processing to the platform via its
return value enables us to limit the API surface (we don't need to
expose TextViewOnReceiveContentListener as a public API, nor equivalent
classes for other types of views such as WebView).
* An app that wants to customize the platform behavior for coercing
content to text would previously need to declare "*/*" as the MIME type
for the callback (in order to be invoked for all content). But this
would make it impossible for features to know whether the app would
actually accept a particular type of content or just coerce it to text
(e.g. should the soft keyboard show GIF suggestions when the declared
MIME type is "*/*"). With the new logic the app's listener is always
invoked and can decide which content to process vs delegate to the
platform vs reject completely.
Bug: 170191676
Bug: 152068298
Test: atest CtsViewTestCases:ViewOnReceiveContentTest
Test: atest CtsWidgetTestCases:TextViewOnReceiveContentTest
Test: atest FrameworksCoreTests:TextViewOnReceiveContentTest
Change-Id: Ie48b6fe0b2ae4b014c371b5dc40248221947c6bf
Having a hidden abstract method for a class that can be extended
means that public implementors cannot implement these hidden methods
posing a risk that custom implementations will not have required
abstract methods resulting in an exception.
Bug: 151134792
Test: make update-api
Change-Id: I758d12465fabc671be19bedeeceb16885de23c87
Exempt-From-Owner-Approval: large scale suppression of existing issues,
no-op in terms of behavior
Results:
We measure the latency between Editor.startActionModeInternal is called
and FloatingToolbar.show() is called.
When there is only smart action (url)
Before: ~150ms
After ~30ms
When there are 5 smart actions (phone number)
Before: ~400ms
After: ~100ms
Before and after videos:
https://recall.googleplex.com/projects/ea8c4705-96bd-46f0-9f37-786708050727
Fixed a few issues:
1. updateAssistMenuItems() gets the Icons from TextClassification
object, calls loadDrawable on them and creates the MenuItem
objects loadDrawable() is slow, especially if we have a lot of
smart action icons to load. Even worse, we are calling this
function 4 times in a row when selecting something! 1 time from
onCreateActionMode and 3 times from onPrepareActionMode.
The fix here is to avoid reloading the drawable if it is the same
text classification object.
2. From SelectionActionModeHelper, we call startActionModeInternal
before SelectionModifierCursorController.show()
Internally, SelectionModifierCursorController.show()
show the two selection handles by calling startHandle.show() and
endHandle.show(). Apparently, each handle.show() call invalidates the
action model right after it is just created! This explains two of the
unnecessary onPrepareActionModel calls.
The fix is to call SelectionModifierCursorController.show()
before startActionModeInternal() is called.
3. Editor.startActionModeInternal() does not invoke
FloatingToolbar.show() right away.
There are two issues here.
a) Editor.startActionModeInternal() ends up calling
FloatingActionModel.repositionToolbar() which hopefully calls
FloatingToolbar.show(). Sadly, it is not the case
because mViewRectOnScreen is not set at that time. mViewRectOnScreen
is set in next onPreDrawCall() call.
b) When mViewRectOnScreen is finally set and calls repositionToolbar()
again , it still won't call FloatingToolbar.show() immediately
because we think that the toolbar is moving by comparing the previous
content rect and the current content rect. They are different because
the previous one is empty(it wasn't shown before). Becoz we think it is
moving, we schedule the FloatingToolbar.show() call after 50ms.
To fix a, we now update mViewRectOnScreen() right away wihout waiting
for the next onPreDraw call().
To fix b, when the previous content rect is moving, we don't consider
the toolbar as moving anymore.
Bug: 169043706
Test: atest android.widget.TextViewActivityTest
Test: atest
cts/tests/tests/textclassifier/src/android/view/textclassifier/cts/TextViewIntegrationTest.java
Test: atest
cts/tests/tests/widget/src/android/widget/cts/TextViewTest.java
Test: Smart select a phone number and then smart select a link.
Make sure the smart actions menuitems are updated.
Test: Click on a smart linkify link. Then dismiss it by tapping outside.
Change-Id: I634b21ac7ed66a14883dc17e03ef006df5b3f223
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Merged-In: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
Change-Id: I54e5ecd11e76ca1de3c5893e3a98b0108e735413
Result(with ag/12911059 as well):
https://recall.googleplex.com/projects/ea8c4705-96bd-46f0-9f37-786708050727
1. Removed the corner animators.
Before 3552167, we supported two modes - fit and overshoot.
In fit mode, the highlight is expanded to a rounded rectangle.
Then corner animator then fills the corner so that the highlight
becomes a rectangle.
In overshoot mode, the expansion animation ends up in a rectangular
highlight, so the corner animator is just like doing no-op for 50ms.
With ag/3552167, we deleted the fit mode and ended up using the overshoot
mode. So, the corner animator is no longer necessary. Deleting it
saves 50ms. I confirmed that it is a no-op by increasing the duration of
it to be 5s.
2. Before this CL, the whole animation takes 350ms.
As per the material design spec
(https://material.io/design/motion/speed.html#duration)
small animation(e.g. toggle) takes 100ms
medium animation(bottom sheet) takes 250ms
large animation(page transition) takes 300 ms.
That means, our animation takes even longer than the large animation!
I think smart selection animation is somewhere between small
and medium, so adjusted the animation duration to be 200ms.
Bug: 169043706
Test: Manual. Select the text and observe the animation.
Change-Id: Ib32bb47851c1cfe95d6951998d6dc5c09a37e17b
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Merged-In: I8285daa8530260251ecad6f3f38f98e263629ca7
Change-Id: I626caf7c1fe46c5ab1f39c2895b42a34319f771a
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
This is a resubmit of ag/12929664 with some APIs excluded that caused
test failures; see bugs 171886397, 171888296, 171864568.
APIs excluded:
Landroid/bluetooth/le/ScanRecord;->parseFromBytes([B)Landroid/bluetooth/le/ScanRecord;
Landroid/os/Process;->myPpid()I
Landroid/os/SharedMemory;->getFd()I
Landroid/hardware/input/InputManager;->INJECT_INPUT_EVENT_MODE_WAIT_FOR_FINISH:I
Bug: 170729553
Test: Treehugger
Change-Id: I8285daa8530260251ecad6f3f38f98e263629ca7
These are APIs that have @UnsupportedAppUsage but for which we don't
have any evidence of them currently being used, so should be safe to
remove from the unsupported list.
Bug: 170729553
Test: Treehugger
Change-Id: I4c8fd0006f950de9955242e93968fb0996ceb372
Added View.onReceiveContent() which will invoke the callback if one
is set.
Added View.getOnReceiveContentMimeTypes() to return the MIME types
that the view can receive, removing the getSupportedMimeTypes()
method from the callback interface.
Changed the code to pass MIME types as a String[] instead of a
Set<String> in order to:
* Avoid repeated conversion from Set to array in
onCreateInputConnection.
* Avoid misleading users of the API into using contains() to compare
MIME types (ClipDescription.compareMimeTypes should be used in order to
correctly handle wilcards such as "image/*").
Bug: 170191676
Bug: 152068298
Test: atest CtsViewTestCases:ViewTest
Test: atest CtsViewTestCases:ViewOnReceiveContentTest
Test: atest CtsWidgetTestCases:TextViewOnReceiveContentCallbackTest
Test: atest FrameworksCoreTests:TextViewOnReceiveContentCallbackTest
Test: atest FrameworksCoreTests:AutofillValueTest
Change-Id: Id0c7f8f5fd3c7c44827a62dba1b2b205433e7540
The original logic of preventing the multi-touch issue for the edtiable
text view was introduced by ag/10930920.
Turns out the non-editable text views are affected.
The root cause of the issue is that:
- the ACTION_DOWN/ACTION_UP events, as well as ACTION_PONITER_DOWN /
ACTION_POINTER_UP, could be generated by different fingers,
- and View#onTouchEvent() gets muted when isFromPrimePointer() == false,
- so that no gesture is generated, e.g. click, long press, etc.
Note that View#onTouchEvent() is necessary to be muted to prevent long press
on text or scrolling while dragging the insertion handle view.
Bug: 169288151
Change-Id: Ia763e94be727ad23bb13839f146293f1579d03ec
(cherry picked from commit 265096d9da)
