Fix: 217730256
Bug: 222537368
Test: Added test in EditTextTest (will merge later when reviewed).
Merged-In: I78354a0f1d955c5b7c1ead044ea49086b3479841
Change-Id: I78354a0f1d955c5b7c1ead044ea49086b3479841
(cherry picked from commit e1f392d171)
While we investigate the root cause of this bug, turn the crash into a
warning.
Bug: 218409359
Test: none; we don't have repro steps for the bug yet
Change-Id: I6d699ea839726adc634a200a0057e316d59ecaa9
(cherry picked from commit 827d967199)
EditorBoundsInfo uses local coordiantes, it was mistakenly set with
screen coordinates
Test: atest InputMethodServiceTest
Bug: 217957587
Change-Id: Iadeaa793d1331b6208e4b19036c45120b0185f64
Re landing with the following changes:
We initially cloned the SurfaceControl handle to avoid locking when
accessing the SurfaceControl from the position listener callbacks
running from RT workers. But this meant the last reference to the
layer handle would only be released by GC. If SurfaceViews are
created and destroyed rapidly, we would be at the mercy of GC to
release buffers.
Original change:
There are three transaction queues that can submit SurfaceView
changes.
1. Buffer updates via BBQ apply token
2. SCC apply token
3. ViewRootImpl BBQ apply token
It makes sense for most SurfaceView changes to be synchronized with
ViewRootImpl draws since the caller can optionally synchronize the
change with main window content.
This change eliminates the tmp transaction that is applied directly
via the SCC apply token and instead applies them with the ViewRootImpl
draw transaction.
Also take the opportunity to scope down mSurfaceControlLock usage.
Test: atest SurfaceViewSyncTest
Test: go/wm-smoke
Test: run mem tests via forrest
Bug: b/217973491, b/221631942
Change-Id: Idba712d146e62d7346920dc4f060cba92d47fada
I discovered this error in documentation while I needed to capture "PasteAsPlainText" in an android app.
I suspect it might be missing in other folder too, but I’m not familiar enough with Android to be sure
Change-Id: I77af9b06eb602c4ba60b0744cc02f7449bc4f500
There are three transaction queues that can submit SurfaceView
changes.
1. Buffer updates via BBQ apply token
2. SCC apply token
3. ViewRootImpl BBQ apply token
It makes sense for most SurfaceView changes to be synchronized with
ViewRootImpl draws since the caller can optionally synchronize the
change with main window content.
This change eliminates the tmp transaction that is applied directly
via the SCC apply token and instead applies them with the ViewRootImpl
draw transaction.
Also take the opportunity to scope down mSurfaceControlLock usage.
Test: atest SurfaceViewSyncTest
Test: go/wm-smoke
Bug: 217973491
Change-Id: I0b5741b376e042537c37ec34644e0a048eb4bfe0
One of the optimizations ag/12911059 did was calling
SelectionModifierCursorController.show() before
startActionModeInternal(). The rationale was that if we start the action
mode first, SelectionModifierCursorController.show() would end up
invalidating the action mode twice unnecessarily, once for each handle.
However, with this optimization, we are calling
SelectionModifierCursorController.show() even when onCreateActionMode
returns false.
Reverted this particular optimization to fix the issue.
Added a test which was failing without this fix but passing with it.
Fixes: 199380016
Fixes: 214341747
Test: atest TextViewActivityTest
Merged-In: I793f76a23978cbbbbde2d16e8a522615174bcdd5
Change-Id: I793f76a23978cbbbbde2d16e8a522615174bcdd5
(cherry picked from commit 11bd644822)
Does not remove Support Library artifacts from docs classpath (ApiDocs.bp)
because they are still used in development/samples, which is not as easy
to migrate as javadoc.
Bug: 158779503
Test: make docs
Exempt-From-Owner-Approval: Mass find/replace for androidx migration
Change-Id: Icf7f53ec36a0e970413352e2ebf40ce9d60ed17e
One of the optimizations ag/12911059 did was calling
SelectionModifierCursorController.show() before
startActionModeInternal(). The rationale was that if we start the action
mode first, SelectionModifierCursorController.show() would end up
invalidating the action mode twice unnecessarily, once for each handle.
However, with this optimization, we are calling
SelectionModifierCursorController.show() even when onCreateActionMode
returns false.
Reverted this particular optimization to fix the issue.
Added a test which was failing without this fix but passing with it.
Fixes: 199380016
Fixes: 214341747
Test: atest TextViewActivityTest
Change-Id: I793f76a23978cbbbbde2d16e8a522615174bcdd5
Replaced "than" (comparative) with "then" (temporal) for the setTextSize JavaDoc. No functional change.
Change-Id: I84b5d1b250cb7a5d925cfbd0a86a2bfef55ade24
ACTION_SET_SELECTION is needed on all TextView nodes to reset the
cursor. But some non-edit texts are selectable and need to be
identified by a11y services. ACTION_SET_SELECTION has been on these
nodes for years so to avoid the complexity of breaking this, add a
node property.
Services should use ACTION_SET_SELECTION for nodes where
property=true
Bug: 62058901
Test: atest AccessibilityTextTraversalTest, TextViewTest cts and
core (TextViewTest#testCutShouldNotThrowException keeps failing but
it's unrelated to this change)
Change-Id: Ia825dd806824e663e7fa7d274f51c6bf44f0c2c4
This change propagates FLAG_WIDGET_IS_COLLECTION_CHILD and
FLAG_USE_LIGHT_BACKGROUND_LAYOUT to nested RemoteViews (either added by
addView, or set as portrait/landscape/sized RemoteViews) if that flag is
also present on the parent RemoteView.
For FLAG_WIDGET_IS_COLLECTION_CHILD, this prevents a PendingIntent from
being set on a RemoteView that is a child of a collection item RemoteView.
For FLAG_USE_LIGHT_BACKGROUND_LAYOUT, this ensures that nested
RemoteViews use their light background layout if this is set on the
parent.
Bug: 214288099
Test: RemoteViewsTest
Change-Id: I8da92d0d338631a99ee718a136bf9674827437bb
This change adds applyNestedView() and reapplyNestedView() to
RemoteViews. This makes it possible to pass the top-level
"rootParent" view (usually AppWidgetHostView for widgets) to nested
RemoteViews that are added by addView(). This allows setRemoteAdapter
actions to work properly when they are used in nested RemoteViews.
Bug: 214288099
Test: RemoteViewsTest
Change-Id: I4fa3fe98d89bffdc0a5be46dabed12b9c217219e
* changes:
Clean <plurals> in DateTimeView
Clean <plurals> in CertificateMonitor
Clean <plurals> in FillUi
Clean <plurals> in BugreportProgressService
Clean <plurals> in keyguard
Clean <plurals> in ChooserActivity
Clear <plurals> in TextUtils
Clean <plurals> in FindActionModeCallback
Clean <plurals> in ZenModeConfig
Add util class for plurals
New filter modes for InputConnection#requestCursorUpdates(mode) to allow
partial data in cursor/anchor updates.
Selective data helps with speedy CursorAnchorInfo updates.
Test: atest InputMethodServiceTest
Bug: 203086136
Change-Id: Ibba06e9a2533ca91c5cc215dfb18d21c9a74fb73
The line break word style(lw) provides the phrase-based breaking opportunities. When the line break word style is set, it will be brought to ICU for calculation.
Bug: 183780874
Test: atest minikin_tests; atest TextViewTest; atest MeasuredTextTest; atest PrecomputedTextTest
Change-Id: Idd851497e46c1fca87ff590230d93f8bb5c9afae
This reverts commit 331be9a643.
Reintroducing ag/16366278 since it seems unrelated to b/214053959 (more details on b/214053959#comment55).
Original commit message:
Migrate unsafe parcel APIs in framework-minus-apex
Migrate the following unsafe parcel APIs in framework-minus-apex:
* Parcel.readSerializable()
* Parcel.readArrayList()
* Parcel.readList()
* Parcel.readParcelable()
* Parcel.readParcelableList()
* Parcel.readSparseArray()
This CL was generated by applying lint fixes that infer the expected
type from the caller code and provide that as the type parameter
(ag/16365240).
A few observations:
* In some classes we couldn't migrate because the class also belonged to
another build module whose min SDK wasn't current (as is the case for
framework-minus-apex), hence I suppressed the lint check
(since I'll eventually submit the lint check to the tree).
* In some cases, I needed to do the cast in
https://stackoverflow.com/a/1080525/5765705 to make the compiler happy
since there isn't another way of providing a class of type
Class<MyClassWithGenerics<T>>.
* In the readSerializable() case, the new API also requires the class
loader, that was inferred to by InferredClass.class.getClassLoader().
* Note that automatic formatting and import rely on running hooked up
to the IDE, which wasn't the case here.
Bug: 195622897
Change-Id: I272432e6e082a973f7a50492ec35d79c2b577c93
Test: TH passes
