In Id65443e93d277c106ea955c867d39e94192cc55d we fixed a monkey crash
happening when the smart selected text had changed while the smart
selection animation was running. However, the change introduced a new
crash, happening when the smart selection result was null. This CL fixes
it, and lets startSelectionActionMode run even when the result is null,
as there seems to be some logic there which should happen in this case.
Bug: 80244201
Test: none
Change-Id: I7f0304446dec85578bdcd5011d2e9ea2737d3c36
(cherry picked from commit a9d27ea869)
Merged-in: I7f0304446dec85578bdcd5011d2e9ea2737d3c36
This regressed when introducing TC sessions in
I3c9ceea0863099fc4f0a5ce5e823c648ee9c4521
When the user triggers a terminal selection event such as "Copy",
we should immediately end the session instead of waiting for the
"Abandon" event (i.e. selection dismissed) to be included in the
logs. Terminal selection events implicitly dismiss a selection and
we'd rather distiguish between an actual "selection dismiss" from
one that happened because of a "terminal" selection event.
This cl also removes the "*" marker used to distinguish the new
logging from the old ones. The code for the old logging has already
been deleted so no more need for a marker.
Bug: 78541105
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Change-Id: Iac7d45dbc63e7076683742bd045766a1d927cfc9
At the end of the smart selection animation, we run a callback that sets
the selection on the TextView (subsequently starting the action mode
toolbar and showing the handles). However, when the text changes before
the animation finishes, the selection might not be valid, and might get
out of the text bounds, which was producing a crash. This was observed
in a monkey crash. This CL fixes this bug by refusing to set the
selection when it goes outside the text bounds, corresponding to the
case when text has changed between the time the animation has started
and the time it ended.
Bug: 69919777
Test: manual testing before and after the fix
Change-Id: Iea043f320004d45ad16dd7e9e5b47e5256e6d9fa
(cherry picked from commit cce6e82d35)
Merged-in: Iea043f320004d45ad16dd7e9e5b47e5256e6d9fa
Approach here is to register a content observer that invalidates the
TC settings whenever updates to the settings happen.
This CL also ensures that the TC is invalidated when a settings
update happens. This is because the settings may change what
TC the system returns.
TextView's SelectionActionModeHelper has been updated to not cache
the settings and get them directly from TCM (which caches the settings).
NOTE that we expect TC settings to rarely change.
Bug: 77539576
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: manual - Made changes to TC settings and observed logs / app behaviour
Change-Id: I88bbb6f951708b17323fac1a72385fe808d270a5
DateTimeView won't update timestamp until the view is attached to
window and received TIME_TICK intent.
Update timestamp on onAttachedToWindow().
Test: manual 1) turn on DND 2) send a notification and wait some time 3)
turn off DND and check the timestamp
Fixes: 77970557
Change-Id: Ia8420aacf5b91b0bb9cbec561629ddbfc8de4f67
Since Ic5b5f6ca687db8b5d842f0ab20eac70f1fd2f85e, the magnifier can be
the child of a diffent surface than the one its content is copied from.
This initially led to much code duplication accross different methods,
making the code quite difficult to understand. This CL performs a small
refactoring, removing some of the TODOs and making the code a bit
cleaner.
Bug: 78876353
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Ifa26f94ba2e4983446f058f016af6010c1017ea7
The position of the magnifier surface is always clamped inside its
parent surface. As of Ic5b5f6ca687db8b5d842f0ab20eac70f1fd2f85e, we are
always trying to make the magnifier surface a child of the main
application window, if possible (before, if the magnified view was a
SurfaceView, we were making the magnifier a child of the SurfaceView's
surface). However, the CL did not also update the clamping, continuing
to clamp to the SurfaceView space when the magnified view was a
SurfaceView (even if the magnifier was child of the main window). This
was making the magnifier window to be wrongly positioned on the screen
when the magnified view is a SurfaceView. The current CL fixes this.
Bug: 78876353
Test: manual testing
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I63f2b185f58e62e8ad6eadf788e641fb1de07b04
The CL fixes the magnifier's behavior when its parent window has
positive insets in its surface:
- we compute the content copy coordinates sent to the pixel copy request
relative to the surface the content is copied from. We were clamping
them inside the visible region of the magnified view as returned by
belonging to the view which is magnified. However, the method returns
coordinates relative to the window. Therefore, the CL offsets the
visible rectangle with the window insets, to account for them.
Otherwise, when the insets were non-zero, on a text line we were
allowing the magnifier to display content from the left outside of the
text line, while a certain region at the end of the text line could have
never been magnified
- when clamping against the visible view region, when the surface we
copy from is a SurfaceView, #getGlobalVisibleRect is still returning
coordinates relative to the main window, whereas the coordinates we are
trying to clamp are relative to the surface of the SurfaceView. In order
to make the visible rectangle relative to the surface of the SurfaceView
instead, this CL negatively offsets the visible rectangle with the
SurfaceView position in the parent surface
- the selection/insertion handles are hidden when they overlap the
magnifier. To check this, we intersect the magnifier rectangle with the
rectangle of each handle. However, when we were performing this check,
the magnifier rectangle was relative to the surface, whereas the
handles' rectangle was relative to the main window. The CL negatively
offsets the magnifier position with the surface insets, to make both
rectangles relative to the window.
Bug: 78621162
Test: manual testing
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I0d749c1abb38520fe8fc477d22d6523f470e9abc
Previously, we were making the magnifier surface a child of the main
window unless the magnified view was a SurfaceView, in which case we
were setting the SurfaceView to be the parent of the magnifier. In
Chrome, where the magnified views are usually SurfaceViews, this caused
the magnifier to be displayed underneath the omnibox, which was a
terrible user experience when trying to magnify the first lines of text
on a page. This was because the omnibox had a higher Z than the
SurfaceView, and therefore a higher Z than all children of the
SurfaceView (including the magnifier).
This CL sets the parent of the magnifier surface to be the main window's
surface when the magnified view is a SurfaceView as well. Therefore, the
magnifier becomes a sibling of the Chrome omnibox and, by giving the
magnifier a higher Z, it ends up being rendered on top.
Bug: 77926365
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: Ic5b5f6ca687db8b5d842f0ab20eac70f1fd2f85e
1. Define default Themes for autofill window and save dialog.
(http://go/theme_autofill). Phone uses light themes, TV uses
dark themes.
2. Apply autofill theme to RemoteViews passed from autofill service.
So this can make sure the textColor of RemoteViews matches
the background of autofill theme uses.
Updated public javadoc that autofill service should not
hardcode color values.
3. A new TV ux that occupies half screen height (go/autofill-for-tv).
TV autofill now passes unhandled physical keyevent to app window
in the same way phone/tablet does.
4. Fixed ATV autofill window to be SYSTEM_DIALOG, so it wont be
clipped by app activity window (DialogLauncherActivityTest).
Bug: 71720680
Bug: 74072921
Test: CtsAutofillTest
Change-Id: Ib570227b0958b1800e8f0600b8aec36478568d74
This code and docs predates the existence of get/setMin() on ProgressBar,
should have been updated when we introduced the new min property.
Test: Ran TalkBack
Bug: 74357845
Change-Id: I318f26bb8ecacc5ecdbf7d026d8568f871cf2369
(cherry picked from commit 25886a160b)
Make floating toolbar outside-touchable for link action mode in
non-selectable TextView.
This allows the user to be able to dismiss the toolbar by tapping
outside of the toolbar.
Bug: 78099871
Bug: 73156794
Bug: 78298142
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit CtsViewTestCases:android.view.cts.ActionModeTest
Change-Id: I8e3b460d0b1baee48d4f9cb3f92e73926eeee231
Previously the user could open inline reply even when the
action was already cancelled. This also enables listening
to pending intent cancellations.
Test: manual
Fixes: 77811784
Change-Id: I4ae164081c6abdeb60a8e78d61bf5e4f26cca1d3
Previously these would overlap, but they are now completely
separate.
Test: ensure that all notification styles still work with the new affordance.
Change-Id: I16f5f863b4afac27494a4a7615631bca240ca532
Fixes: 72750728
As per the referenced bug, we're running into issues where apps are
being fired with stale intents. The reason is because we need intents we
fire to be unique by Intent.filterEquals. Some of the intents we
generate put unique data in the intent extra which is not considered by
filterEquals. The solution here is to create PendingIntents with unique
request codes (using classifiedText.hashCode()).
See more info about this in
https://developer.android.com/reference/android/app/PendingIntent.html
Bug: 77930684
Test: manually tested broken scenarios. See referenced bug
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
Test: bit CtsViewTestCases:android.view.textclassifier.cts.TextClassificationManagerTest
Test: bit FrameworksCoreTests:android.view.textclassifier.TextClassificationTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Change-Id: Ib7275f94ca5ada51e4ba191742d4b614df12e1ea
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
StackView currently expands the clip of the view which is a prohibited
operation in API Level 28. This CL currently allows this specialized
use case to work in this situation until we can update StackView
to not clip to its bounds and then just intersect with this clip
provided by its parent.
Test: CtsWidgetTestCases
Bug: 77642155
Change-Id: Icc003ad3946bb226368ec2030d4707753f4f55e9
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
