Migrate DefaultLogger implementation to SelectionSessionLogger.
This cleans up after the API refactor and fixes two bugs:
- All events are currently logged twice.
- Interfaces accept a null signature, but it currently crashes the legacy logger.
Bug: 73392698
Bug: 77659305
Test: atest FrameworksCoreTests:TextClassificationManagerTest
Test: atest FrameworksCoreTests:TextClassificationTest
Test: atest CtsViewTestCases:TextClassificationManagerTest
Test: atest CtsViewTestCases:TextClassifierValueObjectsTest
Test: atest CtsWidgetTestCases:TextViewTest
Test: atest CtsWidgetTestCases:EditTextTest
Test: Manually examined logs
Change-Id: I0d2b925abf5cab12d71fc2cc0fa527530c86ab10
willNotCacheDrawing as intermediate caching layers are obsolete since
hardware accelerated rendering was introduced in API 11
ImageView's current implementation of setScaleType would manually
disable it's cache if the ScaleType provided was CENTER. This was end up
not drawing the ImageView if View.LAYER_TYPE_SOFTWARE was configured on
the ImageView as the cache no longer existed. Removed the logic to
conditionally disable the drawing cache and marked
setWillNotCacheDrawing/willNotCacheDrawing as hardware accelerated
rendering makes these facilities obsolete
Fixes: 77653694
Fixes: 72139649
Test: Created a test application with an ImageView and manually set a
ScaleType of CENTER and forced the ImageView to render in a software
layer to confirm that it would render properly with a drawable of the
test application's launcher icon
Change-Id: Ie73b1e0708a265e3cc2cc74ed13539f4219dbd7d
(cherry picked from commit 2ac86880d6)
The root of this bug was in the fact that Selection.removeSelection
removes two spans, the start index and end index of the selection.
Each span removal triggers Editor#onSpanRemoved, which in turn tries
to set a selection. This meant that if we started with selection
(100, 120), then removeSpan(start) was called, so we had (-1, 120),
then the onSpanRemoved code tried to set a selection so set it to
(120, 120), then removeSpan(end) was called, ending up in (120, -1).
There are two stages to this fix
1. A lot of our code assumes that when either start or end selection
are larger than -1, both are valid. Therefore when we have one of them
out of sync, we crash. Fixed this assumption in all the places I found
2. We didn't have a mechanism to use FLAG_INTERMEDIATE when removing
spans, only when adding them, so this CL adds a remove with flags. This
allows us to not trigger onSpanRemoved when only one of the selection
indexes is removed.
Because this is an added method to an interface, the default just
calls the existing method. The new method is implemented in
SpannableStringInternal and SpannableStringBuilder to read
FLAG_INTERMEDIATE and avoid sending a spans changed event.
Selection.removeSelection then uses FLAG_INTERMEDIATE when removing
the first of the two selection spans.
Note that 2. would be enough to fix the current bug, but we want to
avoid other implementations of Spannable from crashing in the wild.
In general, it seems like a good idea to verify both selection indexes
are valid whenever they are used.
Bug: 72101848
Test: atest FrameworksCoreTests:SpannableStringBuilderTest
Test: atest FrameworksCoreTests:SpannableStringTest
Test: atest CtsWidgetTestCases:TextViewTest
Test: atest CtsWidgetTestCases:EditTextTest
Test: atest android.text.cts.SelectionTest (note new test as well)
Test: atest android.view.inputmethod.cts.BaseInputConnectionTest
Test: atest android.text.DynamicLayoutTest
Change-Id: I0d647fad152d0bef0f2115a46c3d17ebd8642281
Making sure that a frame will be pushed after the display is ready to
turn on by invaliding the clock after a delay.
Also removed unecessary binder call.
Test: cover prox sensor and wait 1 minute. repeat ~10 times
Change-Id: Ic1b8006781e5486822a5ab65b71b3c44980f2f16
Fixes: 71913808
A deadlock between the UI and render threads caused by magnifier is
currently making the running app to become not responding. The deadlock
could happen in the following scenario:
1. The UI thread sets a frame callback and asks mRenderer to sync and
draw the current frame. A draw task is enqueued by RenderProxy in the
C++ code
2. The UI thread starts an InternalPopupWindow#destroy() on the UI
thread and acquires mLock
3. mRenderer#destroy() is called on the UI thread, which enqueues a
destroy task in the C++ code. However, this is implemented
synchronously, so the UI thread will wait until the destroy task is
dequeued and executed
4. Since the draw task was enqueued before the destroy task, this will
be executed and the frame callback will be called on the render thread
5. The frame callback tries to acquire mLock. However, this is held by
the UI thread, so the render thread has to wait for it. At the same
time, the UI thread cannot progress either as it is waiting for its
destroy task to execute.
The CL adds a new lock which is used by the UI thread to mark its
intention to #destroy(), such that the render thread will know about
this before trying to acquire mLock and starving.
Bug: 75276625
Test: manual testing
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Iedf2948350fcf8dd9c819c085b31b7ccaf2db7c5
1. Wraps TC queries in Request objects
2. Adds create/destroyTextClassificationSession system APIs
3. Adds the session Ids to system API calls
4. Change setSignature() to setId() on result objects
5. Plumbing to make the API updates work as things currently work
6. Hide Linkify.addLinksAsync APIs
Bug: 74461129
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextSelectionTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextLinksTest
Change-Id: I933ada8b37ef9893331a265e3b4fc08e043f1029
We try to never display in the magnifier content that does not belong to
the magnified view. If the magnified view has one or more scrollable
containers, these have to be considered in order to find out the visible
portion of the view which is not masked by scrollable containers.
The previous logic for computing the visible region was wrong when one
of the containers was a ViewPager, whose getScrollX() returns the scroll
relative to all pages, rather than the currently visible one as the
logic was expecting. This CL replaces the old logic with a
View#getGlobalVisibleRect().
Bug: 74359490
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Ib6b63a35436aa691f29c13a0789688f23bfca9f1
In most cases, the magnifier will be displayed above the current line,
so it will not overlap with the handle being dragged. However, when
there is not enough space in the current surface for the magnifier to be
displayed above the current line, the handle can overlap with the
magnifier. Since the handle is implemented as a different window, we
cannot really control the z ordering between them, and we noticed that
the handle will be rendered over the magnifier, which looks bad. This CL
better handles this situation, by hiding the handle when it would
overlap with the magnifier.
Bug: 76459199
Test: manual testing
Test: atest FrameworksCoreTests:android.widget.TextViewActivityTest
Test: atest FrameworksCoreTests:android.widget.TextViewTest
Change-Id: Id5a17fd964360df6094f9e2680e5bcca886c4d2d
Behavioural changes:
- Every action now as an icon, and instead hints via RemoteAction whether
the icon should be shown or not.
- Icons are now taken from the app default, not the activity.
(That way, we can construct a lightweight resource backed Icon)
- Legacy intents are no longer parceled for security reasons.
(TextClassificatio wasn't parcelable in O)
- TextClassifications built with the new API will always return null for
getIntent, but provide a getOnClickListener.
- Accessibility descriptions are now provided for action mode items.
Testing changes:
- Removed URI checks from TCM test because PendingIntent hides this info.
Bug: 73950205
Test: atest FrameworksCoreTests:TextClassificationManagerTest
Test: atest FrameworksCoreTests:TextClassificationTest
Test: atest CtsViewTestCases:TextClassificationManagerTest
Test: atest CtsViewTestCases:TextClassifierValueObjectsTest
Test: atest CtsWidgetTestCases:TextViewTest
Test: atest CtsWidgetTestCases:EditTextTest
Change-Id: I6706d2c342a8bbb9de0146a48c8b8aac9d9c7d83
Outstanding work tbd in other CLs
- Introduce request objects with session Ids
- Implement character based indexing for Selection events.
This CL hides the old Logger API but still keeps running so that we can
check that the modifications to the new API does not break anything.
We will remove the old Logger once we're convinced this is stable.
Please refer to I3c9ceea0863099fc4f0a5ce5e823c648ee9c4521 for previous
reviews related to this CL.
Bug: 74461129
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Change-Id: Iea744f1fa5964b4399290c31863ebeffa99af8d3
The beforeText in a text changed event was coming from
the underlying CharSequence, not what was on the screen.
As a result, it was not sent for password fields. Now
we just provide whatever is on the screen, which is
obfuscated to the same degree it is for a user looking
at the screen.
Bug: 75324441
Test: Verified with password field in TalkBack sample app.
Also atest CtsAccessibilityServiceTestCases
Change-Id: Ib7a10313d2f9d0e44d2052e81e47f19967a67bc4
There is no point in displaying the magnifier when the text is large
enough. In this CL we are using the font metrics of the TextView to
decide whether the magnifier should be displayed or not.
Bug: 70608551
Test: manual testing
Change-Id: Icb2fb4412b6b930dfb3322e51fd0139152cf9d39
DynamicLayout is required when
- The text is Editable.
- The selection is enabled on TextView.
This CL stops using DynamicLayout when the TextView is not selectable
TextView and the input text is PrecomputedText.
Bug: 72998298
Test: atest CtsWidgetTestCases:EditTextTest
CtsWidgetTestCases:TextViewFadingEdgeTest
FrameworksCoreTests:TextViewFallbackLineSpacingTest
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest
CtsTextTestCases FrameworksCoreTests:android.text
CtsWidgetTestCases:TextViewPrecomputedTextTest
Change-Id: Ic4a66ad3ed8868570735e3199879b74132a8c4aa
1. Preserve selection when the TC times out. (See: SelectionActionModeHelper)
2. Fix highlight/toolbar flicker when tapping on a smart link.
- Highlight flicker happening because we reset the selection while in
the process of starting a link action mode.
i.e. onLinkDown: show highlight
onLinkUp: start the link action mode asynchronously
onLinkUp: reset the selection to an insertion cursor*
onLinkActionModeStarted: reset the highlight
*Fix: Don't reset selection while starting a link action mode.
- Toolbar flicker happening because the toolbar positions itself over
the current selection. The way link highlights have traditionally
been done is to set the selection to the links bounds*
*Fix: Hide the toolbar for a few milliseconds when changing
selection for smoother transition.
3. Fix Paste menu overriding link action mode toolbar after a recent
"Copy" action. The Paste menu appearing is a feature. Whenever the
user inserts a cursor after just copying some text, we show the Paste
menu as a way to make it easy for the user to select the text.
Because of the problem described in (2) above, changing the selection
to an insertion triggers the Paste menu feature. Fixing (2) fixes
this.
4. Fix IME popping up on non-selectable + focusable TextViews.
See: imm.showSoftInput(...) in Editor. And see comment in the code
around that. We should only pop up the IME for editable text.
Fixes: 73872461
Fixes: 75985239
Fixes: 76011461
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Change-Id: If9ddb7f4e6d4db480ba4a495a22f7f2924ab937e
Before this CL, the magnifier window was sometimes displayed partially
out of screen or overlapping with the system bar. This CL prevents this
issue by clamping the magnifier inside its parent surface, also taking
into account the system window insets of this surface.
Also, the CL fixes two kindof unrelated small bugs:
- remembers to reset the previous show and pixel copy coordinates on
#dismiss()
- when clamping the pixel copy coordinates inside surface, consider the
size of the copied content rather than the size of the window where
this is scaled and then copied
Bug: 74234779
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Iec3404123145aa95b37c88f4fbfa3918cbf24f9d
The flag should only ensure that smart linkify calls behave in the
legacy way instead of totally disabling linkify.
Also, to keep the flag consistent with smart_selection_enabled and
smart_text_share_enabled flags, the flag should only disable the
SmartLinkify (i.e. Linkify.addLinksAsync) feature not TextClassifier
APIs (i.e. TextClassifier.generateLinks).
Also fixes issue with non-focusable TextViews by firing the primary
action instead of showing the floating toolbar. (b/73156794)
Bug: 75967597
Bug: 73156794
Test: bit FrameworksCoreTests:android.text.util.LinkifyTest
Test: bit CtsTextTestCases:android.text.util.cts.LinkifyTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: manual - checked behaviour turning flag on/off
Test: manual - checked behaviour with TextView.setFocusableInTouchMode(true/false)
Change-Id: I541f60161b9cd63ce7e57235607500f2fb0841e7
This is 2nd attempt of I072dfd70b9a687d9c47e310d8cdb34f988fbb32e
The root cause of crashing is unexpected copying of NoCopySpan by
SpannableString constructor. To prevent crashing, stop copying
NoCopySpan by passing ignoreNoCopySpan=true to SpannableString
copy constructor.
The original commit message is following:
To support selectable TextView, make PrecomputedText spannable.
By this change, TextView start using DynamicLayout instead of
StaticLayout. DynamicLayout requires boundary rectangle of the
text, so this CL also adds getBounds method to PrecomputedText
which retrieves measured boundary box from native.
By this change, the selectable TextView performance for the
precomputed text 10x faster. On the other hand, the performacne
for the non-selectable text gets 2.5x slower. However, we concluded
that we accept this performance regression since it still 10 times
faster than non precomputed text.
Here is a precomputed text performance result of TextView.
android.widget.TextViewPrecomputedTextPerfTest:
newLayout_PrecomputedText : 736,130 -> 1,648,694: (+124.0%)
newLayout_PrecomputedText_Selectable: 17,379,765 -> 1,700,146: (-90.2%)
onDraw_PrecomputedText : 1,274,921 -> 1,848,076: (+45.0%)
onDraw_PrecomputedText_Selectable : 17,367,238 -> 1,399,169: (-91.9%)
onMeasure_PrecomputedText : 752,875 -> 1,766,606: (+134.6%)
onMeasure_PrecomputedText_Selectable: 17,647,842 -> 1,810,704: (-89.7%)
setText_PrecomputedText : 92,894 -> 135,471: (+45.8%)
setText_PrecomputedText_Selectable : 145,134 -> 215,757: (+48.7%)
Bug: 72998298
Test: atest CtsWidgetTestCases:EditTextTest
CtsWidgetTestCases:TextViewFadingEdgeTest
FrameworksCoreTests:TextViewFallbackLineSpacingTest
FrameworksCoreTests:TextViewTest FrameworksCoreTests:TypefaceTest
CtsGraphicsTestCases:TypefaceTest CtsWidgetTestCases:TextViewTest
CtsTextTestCases FrameworksCoreTests:android.text
CtsWidgetTestCases:TextViewPrecomputedTextTest
Change-Id: Ie98c75d8b4ba962eaf0a544357b2ff1ade891118
setupAutoSize fills in the possible text sizes that can be generated
between a min and max value. In order to do that, it counts the number
of steps starting from minSize until maxSize. However, while counting
it rounds the initial value, which causes rounding error at the final
step.
Test: Change system font scale to 1.1 via
adb shell settings put system font_scale 1.1
Test: atest android.widget.cts.TextViewTest
Bug: 73917559
Bug: 75266270
Change-Id: I61811db28ef01262bd48f5042d783d75c71c3614
(cherry picked from commit db86a6b047)
A couple of links were badly formatted. Updated doc staged to:
go/dac-stage/reference/android/widget/RelativeLayout.LayoutParams.html
Test: make ds-docs
Bug: 72624598
Change-Id: I197f5ef52f2476134db674d342dee812ceebec2a
Exempt-From-Owner-Approval: Doc-only change
This CL updates both the magnifier and the floating toolbar to use the
dialogCornerRadius attribute for the corner radius of their windows. In
both we use its value defined in the default device theme, rather than
the value defined in the application's custom theme.
Bug: 70848492
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Ifcf4cff1f38fd18b7dbb4c1802390e3beb92cd3c
(cherry picked from commit 3dcbc2112d)
Merged-In: Ifcf4cff1f38fd18b7dbb4c1802390e3beb92cd3c
This is based on feedback on Ib5af1ec80a38432d1201fbc913acdc3597d6ba82
Bug: 74466564
Bug: 67609167
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Test: bit CtsViewTestCases:android.view.textclassifier.cts.LoggerTest
Merged-In: Ic8d58acb2bbd63cedcac4aa16940b4ac852aadc8
Change-Id: Ic8d58acb2bbd63cedcac4aa16940b4ac852aadc8
Currently, for selection, if we move one handle towards the other, the
moving handle will stop when the selection becomes 1 character long.
However, the magnifier would continue to follow the finger after this,
no longer being helpful for the selection.
This CL fixes this, by replicating what happens when the magnifier
reaches the end of the line also for the case when it reaches the other
handle.
Bug: 72314536
Test: manual testing (both English and Arabic)
Test: atest FrameworksCoreTests:android.widget.TextViewActivityTest
Test: atest CtsWidgetTestCases:android.widget.cts.TextViewTest
Change-Id: I5bde622421c7fb8ecce0ea00f0d8d2af7aa72cf4
(cherry picked from commit 2d6b40b821)
Merged-In: I5bde622421c7fb8ecce0ea00f0d8d2af7aa72cf4
Currently, after the cursor is reaching the end of a line, the magnifier
keeps following the finger even if the cursor cannot move anymore.
This CL limits the movement of the magnifier, ensuring it stays between
the bounds of the text line. Also, when the finger gets too far from the
end of the line, we dismiss the magnifier. We consider it went too far
when the cursor is not visible anymore inside the magnifier.
Bug: 72314536
Test: manual testing (both English and Arabic)
Test: atest FrameworksCoreTests:android.widget.TextViewActivityTest
Test: atest CtsWidgetTestCases:android.widget.cts.TextViewTest
Change-Id: I8dafba1fc8e7b8e482526e818831ece2ee20ac27
(cherry picked from commit dfc752bc74)
Merged-In: I8dafba1fc8e7b8e482526e818831ece2ee20ac27
