The fallback line spacing is a feature of extending the line height
when the fallback font has taller glyph. This was implemented to
StaticLayout in Android P but not yet implemented in BoringLayout.
This CL enables this feature to the BoringLayout as well.
Not to break existing apps, change this behavior only if the
targetSdk version is T or later.
This is a 2nd attempt of Ia6d6f9f44e73ddaf5e8fe9a8aead7a53efbddd44
The root cause of SystemUI crash was wrong API usage. (start, end) was
passed instead of (start, count).
Bug: 210923482
Test: atest FallbackLineSpacingTest BoringLayoutFallbackLineSpacingTest
Test: atest CtsGraphicsTestCases
Test: atest CtsTextTestCases
Test: atest SystemUITests
Change-Id: I9137607b0120934f7ad2a12c0f0b8aaa52915831
Revert "Add font extent calculation"
Revert "Add test case for fallback line spacing"
Revert submission 16486662-fallback_line_spacing
Reason for revert: Investigate test failures on master
BUGID: b/213826416
BUGID: b/213829920
Reverted Changes:
I06cd7ab71:Add font extent calculation
I6214d52cd:Implement fallback line spacing for BoringLayout
Ia5825c474:Add test case for fallback line spacing
Change-Id: Ia6d6f9f44e73ddaf5e8fe9a8aead7a53efbddd44
The fallback line spacing is a feature of extending the line height
when the fallback font has taller glyph. This was implemented to
StaticLayout in Android P but not yet implemented in BoringLayout.
This CL enables this feature to the BoringLayout as well.
Not to break existing apps, change this behavior only if the
targetSdk version is T or later.
Bug: 210923482
Test: atest FallbackLineSpacingTest BoringLayoutFallbackLineSpacingTest
Test: atest CtsGraphicsTestCases
Test: atest CtsTextTestCases
Change-Id: I6214d52cde25a044bc6e246d2118e35d3a243c9d
to explicitly callout the 2-line limit
Note: more information can be found in
https://developer.android.com/guide/topics/ui/notifiers/toasts
which is also linked in the documentation but
could be missed.
Test: manual
Fixes: 207767563
Change-Id: Icc7fbf6fddf101bd2422bbeab04e0da8084c6698
With this CL, EditText#setText() actually starts using
InputMethodManger#invalidateInput(),
which does not block the UI thread.
See the previous CL [1] about how that API actually works.
There should be no observable changes from the viewpoint of IMEs.
Note that this CL was once reverted due to Bug 208941904, which was
caused by a misbehaving InputConnection#endBatchEdit() implementation
as a combination of the following bugs:
* Chromium (crbug.com/1277732)
* EditableInputConnection (Bug 209958658)
Now those two bugs were addressed. We have also implemented a
safeguard [2] against the same type of app issues so that the system
can gracefully fall back to the previous behavior as needed.
[1]: I3161755779080f98bcef0e47dd0c5247d8a3a256
daa6695c2e
[2]: I109e0c26d8249fc2e01323e3e1cb36395fa7cc97
60c7c55c36
Bug: 203086369
Fix: 209008342
Test: atest CtsInputMethodTestCases
Change-Id: I2ce4be729e23ef686e128f832f8cf7debdcd551e
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
Test: TH passes
Change-Id: I11a27b9bdab7959ee86e90aa1e1cbebd7aaf883c
When user click notification's action (i.e. answer call), the activity
wouldn't display as the user is interacting with.
Add ActivityOptions#setLaunchDisplayId to the display that the given view
is currently on. So the activity will be launched to the display as the
user is interacting with.
Bug: 191222363
Test: Manually tested using Exo. Open calling application(e.g.WhatsApp)
on Exo virtual display, and answer the call from the notification of
phone.
https://drive.google.com/file/d/1OhS1yn5nCcUe1Aiti3_MLL7k5BLFf7_W/view?resourcekey=0-CCR2Mihn-cfCSIqQZMg-ow
Change-Id: I215519965074b2ddc66eb0a53320673295d4fb17
Bug: 206526994
When items are added to a ListView, any current stretch
should be released and a new touch should scroll and not
stretch.
Test: new tests. manual test
Test: If426eddf2e582169090e5e5e5694668c583288dc
Change-Id: I1f0ae1aa38b064dbb399e46869d8f14ac9d22a92
The system received the same multiple translation responses in a very
short time. We use a isShowingTranslation flag to determine if the
duplicated responses to call onShowTranslation. However the
isShowingTransation flag is set in a post runnable, this may cause the
system allow the duplicate responses can call onShowTranslation
because the isShowingTransaltion isn't set true yet.
Use multiple flags isShowingTranslation and a new isRunningAnimation
to check if the same translation response should skip to call
onShowTranslation.
Bug: 207457172
Test: manual
Test: atest CtsTranslationTestCases
Change-Id: I7003b7f49fc0a8ce2e909228bcb89acedee6d3d0
If the BitmapCache is not copied when cloning RemoteViews, then Bitmaps
will be dropped.
Fix: 208865678
Test: cts, verified locally
Change-Id: I7547ab3a60ac3ee16b9cfb8d592988d0e410172d
when we have overlapped SuggestionSpans, the
range of text being replaced can change depends on
the number of suggestions in the SuggestionSpans, so
accessibility services need to know the text being replaced.
We send text change event with the before text doesn't have the
SuggestionRangeSpan and after text has the SuggestionRangeSpan,
so a11y services can inform the user about the text being
replaced.
Other ui toolkits like compose can convert their style indicating
text being replaced to SuggestionRangeSpan.
Bug: b/143378480
Test: tested the event is sent.
Change-Id: I6d0d33e46f7c8ac9dbcc177ab54718184e715fb6
Bug: 206526994
When items are added to a ListView, any current stretch
should be released and a new touch should scroll and not
stretch.
Test: new tests. manual test
Test: If426eddf2e582169090e5e5e5694668c583288dc
Change-Id: I1f0ae1aa38b064dbb399e46869d8f14ac9d22a92
And implement it for editable text to show the popup
window for typo correction.
Bug: b/143378480
Test: tested with modified talkback.
Change-Id: I8bb1ec87f6bb2177fb4b8fb9a88bfbe10b374173
* It can not be null and before the statement rv has been already used.
Test: Make AppWidget on the front page.
Fixes: 168335785
Change-Id: If622ef693fb806a2b0d7a86182f9ccb10c80eba6
When user types space after a word, we receive a text
change event, but the suggestion span is not added to
the text yet. The spell checker adds the span after the
text change event is sent. Previously we send the event
in onSpanAdded in TextView, but we don't do anything or
update the before text for span removed. This is a bit
confusing and error prone. This change moves the send
event logic into spell checker.
Bug: b/143378480
Test: tested with talkback.
Change-Id: Ibd45843494304602b177df8da520a51058989f10
With this CL, EditText#setText() actually starts using
InputMethodManger#invalidateInput(),
which does not block the UI thread.
See the previous CL [1] about how that API actually works.
There should be no observable changes from the viewpoing of IMEs.
[1]: I3161755779080f98bcef0e47dd0c5247d8a3a256
Bug: 203086369
Test: atest CtsInputMethodTestCases:EditTextImeSupportTest
Change-Id: I8d2e0be22454b106ded15c78c876b55dc6e60a13
Previously, the recycling was only checked for multiple layout, as it
was assumed the AppWidgetHostView would make the basic check. However,
adapters views (e.g. ListView, ...) do not make any recycling check,
instead relying on caching using the Layout id. The caching cannot be
changed as it is common to other parts of Android.
Note, however, that some apps are already using this lack of test to
create the view themselves and use reapply to apply the RemoteViews. So
we limit the test to uses involving changing the viewId.
This CL ensures the view can be recycled when reapplied, always.
Bug: 181985606
Test: atest android.widget.cts.RemoteViewsRecyclingTest
Change-Id: Ib4f908c66a666faa4e6c27e2be38246eb7748f61
By using "squashing", each ApplicationInfo is only written to the parcel
once. Subsequent writes write only a single int as a reference.
This makes the earlier system with ELIDE_DUPLICATES unnecessary.
Squashing relies on testing for equality, and ApplicationInfo does not
implement equals, therefore I've added a shared cache based on package
name and uid so that we can force all RemoteViews of the same package to
use the same ApplicationInfo object.
There is also a mechanism to update the ApplicationInfo to a new one
(needed for dynamic colors).
This saves space for addView calls as well as RemoteCollectionItems
usage. After this change, each incremental item in a collection adds 48
bytes as a base (before this was multiple kilobytes).
This approach also supports collections with RemoteViews from multiple
packages. Each ApplicationInfo in the entire hierarchy is written at
most once.
Bug: 202831917
Test: locally, atest RemoteViewsTest, atest RemoteViewsFixedCollectionAdapterTest
Change-Id: Ie1b1dc8760247aa771451149243efd63d36da368
Revert "Add test checking view recycling is always tested"
Revert submission 16149646-betterRecycling
Reason for revert: Droidfood Blocking Bug: 205503898
Reverted Changes:
Ib01c511e4:Always check if the view can be recycled.
If11dcd323:Add test checking view recycling is always tested
Change-Id: Id08d5ea3602d9d3ca03e148e57a9f97435534e2c
Previously, the recycling was only checked for multiple layout, as it
was assumed the AppWidgetHostView would make the basic check. However,
adapters views (e.g. ListView, ...) do not make any recycling check,
instead relying on caching using the Layout id. The caching cannot be
changed as it is common to other parts of Android.
This CL ensures the view can be recycled when reapplied, always.
Bug: 181985606
Test: atest android.widget.cts.RemoteViewsRecyclingTest
Change-Id: Ib01c511e4a793cce1519157aea06e194a2d8f855
