The CL adds an API to customize what overlay will be drawn on the top of
the magnifier content. Our default is to draw a 5% white overlay to make
magnifiers distinguishable in dark contexts.
Bug: 72211470
Test: manual testing
Change-Id: I1a356813960a60f49e068c6135ded9d41429d57c
The CL adds API to customize the bounds relative to a view where the
magnifier content is allowed to be copied from.
Bug: 72211470
Test: manual testing
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I3016a34929acf029f5251d03812f17e4da4cb948
This is a dead code that cannot even be used correctly as the
permission<->group mapping is not authorative in the platform
Hence remove the code beside the small sections still used by settings.
Test: Built
Change-Id: I09cfcb5cc6811222f77377fa20123ef954b7a309
- Refactored onProvideStructureForAssistOrAutofillOrViewCapture() into a common,
hidden onProvideStructure(viewFor) method on View that (hopefully :-) makes
it easier to understand / extend.
- Renamed / documentted some methods on TextView.
Bug: 111276913
Test: atest CtsAutoFillServiceTestCases CtsAssistTestCases \
AssistFrameworksCoreTests:AssistStructureTest
Change-Id: I328ce3f26a42e7408015cc0014a3f707801ebeb9
The CL adds a public API to enable customizing magnifier's behavior when
the coordinates passed to #show would position the magnifier outside the
main application window.
Bug: 72211470
Test: manual testing
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I9de26e446354d0ad987a4509089fbec4ee5ef7d3
There are 4 new APIs on View:
- boolean setImportantForContentCapture()
- boolean getImportantForContentCapture()
- boolean isImportantForContentCapture()
- boolean onProvideContentCaptureStructure()
And 4 on IntelligenceManager:
- void notifyViewAppeared()
- void notifyViewDisappeared()
- void notifyViewTextChanged()
- ViewStructure newVirtualViewStructure()
These methods are similar to the equivalent methods that are used for Autofill
and/or Assist, except for the following differences:
- The view hierarchy nodes are reported as they are rendered, rather than at
once in a tree, recursively. Hence, the ViewStructure implementation does
not implement the methods that add children to it, and views that provide
virtual hierarchies must manually call IntelligenceManager to create the
ViewStructure to their children and notify when their children are added and
removed.
- It does not support methods added for Autofill to handle HTML pages (such
as setHtmlInfo() and setWewbDomain()), as they're not important in the
Content Capture context.
- Similarly, it also does not support setDataIsSensitive(), because the
Intelligence service does not have the same restrictions as the Autofill
service.
The CL also provides the initial implementation of these APIs, although still
full of TODOs (for example, we're not holding the events to send as a batch
yet).
Test: m -j update-api doc-comment-check-docs
Bug: 117944706
Change-Id: I43f06ce82bfe3b14d8d13fb3b2ebee223db83284
The CL fixes a null pointer exception happening when the selection
controller in Editor is created on startActionMode. The NPE was
introduced by I261559b5c1abe21fd8508ab72f24a5696899a074, which removed
the handle drawable loading before using the drawables for creating the
handles. The current CL adds the handle drawable loading back.
Bug: 119214395
Bug: 119189742
Test: atest CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: atest android.widget.TextViewActivityTest
Test: atest android.widget.TextViewTest
Change-Id: Iba5f6b606b1aaf2124487da5642c6f3b132a061c
* changes:
WindowInsets: Annotate nullability
WindowInsets: Add Builder
WindowInsets: reimplement WindowInsets on top of Insets
WindowInsets: make WindowInsets.inset() public
The CL adds public setters and getters for the drawables used
for the insertion and selection handles of a TextView.
Bug: 117521469
Bug: 79404656
Test: atest CtsWidgetTestCases:android.widget.cts.TextViewTest
Change-Id: I261559b5c1abe21fd8508ab72f24a5696899a074
This is a ground work for b/114479228
FontStyle is an argument of the font itemization. Currently Android
system uses weight and italic info for itemizing but maybe we will
use width and oblique style in future.
To be extensible in future, introduce FontStyle.
This CL includes:
- new class FontStyle which holds width and italic at this moment. In
future, we may add width and oblique. (or grdual italic slant)
- Font class still returns weight/slant since they need to be immutable.
- Moved font weight constants from Font to FontStyle
Bug: 114479228
Test: atest CtsGraphicsTestCases
Change-Id: I0ba717fbf9f90ee6f760c1a0f6eda17b4bef6f43
This change makes touch ripples appear correctly on the action buttons
on media notifications. This involves the following changes:
- NotificationViewWrapper.onReinflated() sets the notification content
root's background to transparent rather than null when transferring the
background color to the NotificationBackgroundView. This gives the
ripples a surface to draw on.
- The RemoteViews for the media templates are changed to use a fixed
set of buttons instead of removing and re-adding them on every update.
This prevents the update caused by whatever action the tap invokes from
interrupting the ripples.
- A method is added to RemoteViews allowing the ripple color to be
specified. This allows us to change the ripple color to match the
foreground color of the controls, which is necessary for the ripples to
show up against a dark background.
Test: manual
Change-Id: I907f9a1a75efb48da496133ad357fc5150de4410
Fixes: 35856702
ContextImpl has an internal rule that when ContextImpl#mDisplay is
null the Context is associated with the default display. The problem
is that, as discussed in Bug 117709581, when ContextImpl#mDisplay is
null ContextImpl#getDisplay() tries to get some non-null Display
object by making an IPC to the system server, which is redundant when
the display ID is the only thing that the caller wants to know.
By having an @hide method Context.getDisplayId(), we can ensure that
display ID can be obtained without any IPC. This enables us to
re-submit my CL [1] that aimed to instantiate InputMethodManager (IMM)
for each display but then got reverted due to a performance regression
(Bug 117434607).
There should be no developer-observable behavior change.
[1]: I7242e765426353672823fcc8277f20ac361930d7
c53d78e992
Fix: 117712745
Test: atest FrameworksCoreTests:android.content.ContextTest
Test: prebuilts/checkstyle/checkstyle.py -f \
frameworks/base/core/tests/coretests/src/android/content/ContextTest.java
Change-Id: I2534530a5ce90e2620c5039d793a6454a0a1e154
Currently mStyleIndex is used as a flag int, but its default value is -1.
Rename it to mTextStyle and change the default value to 0 in order to avoid confusion.
Also fix the bug that when fontWeight is specified while not textStyle is
specified in XML, the typeface unexpectedly becomes italic.
Bug: 78873447
Test: atest TextViewTest
Change-Id: I819b8f15e1dcaae7b16f7c97b489b4ed8db494c6
On Android P, TextView was keeping track of the last mText that was sent to
AutofillManager to avoid calling it again if the value didn't change, as that
would incur on unnecessary IPC calls from AFM to AFMService in the UIThread.
Now on Android Q this optimization is causing the method to not be called when
it should when the mText is a reference to a SpannableStringBuilder, as it's
equals() method now returns true in this case (before it was returning false,
which was a bug: if the reference didn't change, it should return true).
We have 2 options to solve this problem:
1.Fix TextView to keep a String copy of mText.
2.Remove the optimization.
This CL fixes it using #2, for 2 reasons:
1.On Android Q, the AFM calls to AFMS are async, so it's not a jankiness issue
anymore.
2.Making a copy will actually be *worse* for performance, as it would be making
an unnecessary copy for the cases where autofill is disabled.
Test: atest android.autofillservice.cts.DatasetFilteringTest#testFilter_usingKeyboard
Test: atest CtsAutoFillServiceTestCases # to make sure it didn't break anything
Fixes: 117106046
Change-Id: Ia1c69e2d7a478288f65566e862f4a43e88eca463
The magnifier is currently behaving badly when the magnified view is
scaled and/or rotated - the content of the magnifier and its position
are wrong, as we do not take these into account when computing
coordinates for content copy and magnifier positioning. This CL is
making the magnifier remain hidden when such transformations are applied
to the magnified view or a view above it in the view hierarchy.
Bug: 112519631
Test: manual testing
Change-Id: Ibb81fdc9d2ec8ba14914166e408c92a3aad7e312
Bug: 68489306
If we use a drawable like ColorDrawable for an ImageView it has intrinsicWidth and intrinsicHeight == -1.
1) Simplified matrix calculation in ChangeImageTransform.captureValues. It makes no sense to return null as a matrix because later in createAnimator it will be considered as the identity matrix. For cases when drawableSize == -1 instead we can just use view.getImageMatrix() which would be the identity matrix.
2) There is an additional check in createAnimator() to start an empty animation if the drawable width or height is 0. But actually it worth to use it also for cases when width or height is -1, as if it goes into else branch matrix transformations will try to incorrectly change the bounds of the drawable to (0, 0, -1, -1).
3) And also actually there is a bug in createNullAnimator() method, we can't provide nulls as values for ObjectAnimator.ofObject, as later it will crash on PropertyValuesHolder.setObjectValues(Object... values) because of "values[0].getClass()". So I changed it to provide some nonnull values like Matrix.IDENTITY_MATRIX. It is not important what to provide here as NULL_MATRIX_EVALUATOR will not use the values anyway.
4) Also I found a bug in ImageView.animateTransform(). If we provide null matrix if will try to update the drawable bounds to the view size but will not take into account paddings(in the same way like configureBounds()).
Test: Tested manually on the sample app from the bug and added new tests for both cases: with view bounds change and without it
Change-Id: I0750de56f4a011e06b340ed342884b59896d92dc
- This is to work around issues where the caller (ie. RemoteViews) is
launching a provided pending intent that is immutable and still needs
to ensure that it is launched in a separate task.
Bug: 112508020
Test: Launch an immutable pending intent from a widget and ensure it
launches in a new task as expected
Change-Id: I70c318674da15a78418548ee719cb1257f899ac6
The CL deprecates the old constructor for Magnifier instances in favor
of the usage of builder Magnifier#Builder.
Bug: 116116502
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Change-Id: I3daa9f066c77144e9d5c62bc666ecd37041f4bbb
This API is necessary for identifying the cursor locations.
Bug: 112327179
Test: atest android.graphics.cts.PaintTest
Change-Id: Ief6770bd622a296ae356094fe3ce58e9c4371088
This is a preparation to deprecate the following two methods.
* InputMethodManager#getInstance()
* InputMethodManager#peekInstance()
Since we soon need to stop relying on the current per-process
InputMethodManager singleton model to fully support multi-display,
those two methods really need to be deprecated.
With this CL, framework code no longer depends on
InputMethodManager#peekInstance(), which is also marked as deprecated
in this CL.
InputMethodManager#getInstance() is a bit tricky because it also works
as a constructor of such a per-process singleton instance. Remaining
two call-sites of this method will be migrated in a subsequent CL.
This is a mechanical refactoring, which in theory should have no
observable logical behavior difference.
There could be a small performance regression, but it is basically not
avoidable to correctly support multi-display scenarios.
Bug: 115891476
Test: atest CtsInputMethodTestCases CtsInputMethodServiceHostTestCases
Test: atest CtsWidgetTestCases:android.widget.cts.EditTextTest
Test: atest CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: atest FrameworksCoreTests:com.android.internal.inputmethod
Test: atest FrameworksServicesTests:com.android.server.textservices
Change-Id: I5db31491f3d47d3ad4a621e956995135c72e007b
