RemoteViews end up passing around Uris, so we need to extend Uri
permission grants for them to ensure the recipient of a Notification
object is able to render its contents.
Bug: 9069730
Test: atest frameworks/base/services/tests/uiservicestests/src/com/android/server/notification
Change-Id: Id31b5adaf2ee66113a1b503e32126aeddbf97b28
The old design didn't work at all because of various
paddings. The new design adds more paddings and a
new button style
Fixes: 72814598
Test: runtest systemui
Change-Id: I4b4ac0790afe45db97f912740446c6da09620be3
I put it on TextView to try to scope it as narrowly
as possible, but an ImageView could be a heading, as
could a LinearLayout that holds a TextView (like a
preference).
Bug: 77726494
Test: atest CtsAccessibilityServiceTestCases
Change-Id: I9313ce6de25b5893db450f23499b151a4f08afda
Consider an app targeting the final API 28, but running on an older
build where "P" is still API 10000. Those apps need to be treated as
legacy apps.
In general, the logical pattern that should be used when enforcing
target SDK behaviors is below.
For applying behavior to legacy apps:
// BROKEN
if (targetSdkVersion <= Build.VERSION_CODES.N_MR1) {
// CORRECT
if (targetSdkVersion < Build.VERSION_CODES.O) {
For applying behavior to new apps:
// BROKEN
if (targetSdkVersion > Build.VERSION_CODES.N_MR1) {
// CORRECT
if (targetSdkVersion >= Build.VERSION_CODES.O) {
Bug: 77865751
Test: builds, boots
Change-Id: Ia83bd446a940751d51a6542c7a5b9cca174c5296
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
In general, since text insertion/selection handles are implemented as
PopupWindows, if they get to overlap the magnifier they are going to be
rendered above it. Therefore, we are trying to avoid this case.
Before this CL, we were only hiding the grabbed handle, when this would
overlap the magnifier. Since the magnifier would usually be displayed a
certain offset above the grabbed handle, this could only possibly happen
when there was not enough space for the magnifier above in the current
surface.
However, this is not enough, as in the case of selection, the other
handle could as well overlap the magnifier in certain cases. This CL
intersects the magnifier rectangle with the rectangles of both handles
and detects whether these should hidden or not.
Bug: 76459199
Test: atest FrameworksCoreTests:android.widget.TextViewActivityTest
Test: atest FrameworksCoreTests:android.widget.TextViewTest
Change-Id: I22519979eead276dbcf273f7c1a54d654fa251bc
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
