Since CONTEXT_RESTRICTED is not a default flag of createPackageContext,
we can't rely on it for preventing unexpected font injections.
To protect developers and existing apps from a risk of font injection,
stop loading font from other package's resouce unless the developer
explicitly set CONTEXT_IGNORE_SECURITY.
This CL contains Iac2a6fb3d82ef23d5ca6ee33f4aaa9ed28455271 by manual
merging to handle repository split.
Bug: 62813533
Bug: 62879353
Test: Manually done
Merged-In: I4442ddc48dadb5c968b444be86038b602074d301
Change-Id: I4442ddc48dadb5c968b444be86038b602074d301
While a negative height is pretty silly, crashing apps on
the new version of android makes them sad.
Test: Existing CTS passes.
Bug: 62434804
Change-Id: I5fc3fc50fb6ccfa9e96f38ded4fb8e338f263f09
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
bit CtsWidgetTestCases:android.widget.cts.EditTextTest
Bug: 62271937
Change-Id: Ib3447281f3bd1abc811a25fc55ad55e34e155bbb
Because cloning wasn't synchronized, the notification
could become a non-root temporarily which in turn could
lead to a crash.
1. We're now properly synchronizing the cloning, such that
this can't happen anymore
2. We're now only cloning the old statusbar notification lightly
instead of heavily to avoid this altogether
Test: manual, update decoratedcustomview notifications really fast
Change-Id: Ia6525eec64ad9a26956ca2198e20198f55b2173c
Fixes: 62181033
Remove throwing an error and instead clamp
the selected date to min/max when changing
ranges.
Bug: 36636681
Test: manually verified that the case in the
bug does not happen again
Change-Id: If540f58d21375d2320df5215504d4569e5c2be2e
* splits the auto-size setup part from the execution
function:
** in TextView CTOR we only setup and we leave the
actual auto-sizing execution to happen in the
view||text layout phase
** encapsulated the conditions needed to start
applying auto-size in the execution function
* introduces a private way to set the text size
without requesting a new layout pass; auto-size
always uses this practically setting the text
size on the paint object and creating a new
layout
* calls execution autoSizeText() from within
TextView#checkForRelayout() if not requestLayout()
is needed => this makes sure that auto-size will be
performed even if a view layout is not requested,
but only a text layout
* fixes the calculation of the sizes available for
auto-size when configured via granularity
Bug: 62050646
Bug: 38409622
Bug: 38440435
Bug: 62109627
Test: run cts --test android.widget.cts.TextViewTest -m \
CtsWidgetTestCases
Test: manually tested the new behaviors in demo apps
Test: new test attached in topic
Change-Id: I4ccaa0a0afa3b5aa47213442d0029da2c74e7eb4
This commit specially checks isDefaultFocusHighlightNeeded for
ImageView. We should also check with the content drawable of the
ImageView besides its foreground or background.
Bug: 62141891
Test: cts-tradefed run singleCommand cts --skip-device-info
--skip-preconditions --abi armeabi-v7a -m CtsViewTestCases -t
android.view.cts.View_DefaultFocusHighlightTest#testIsDefaultFocusHighlightNeeded
Change-Id: Iaf12a5863d7760d9361d0196a46de07a9ccda74e
This CL early returns from auto sizing text if the view is not measured
yet.
Test: run cts --test android.widget.cts.TextViewTest -m CtsWidgetTestCases
Test: Added cts.TextViewTest#testAutosizeWithMaxLines_shouldNotThrowException
Test: Manual test with sample app for the failing case.
Bug: 38440435
Change-Id: Ic03c991f33a2b7701623f00f44cba7fb6cdfce46
Use the looper from the TextView's thread for the helper
Bug 62043115
Test: Manual, type on edit field and select text
Change-Id: I501430a500016a81963a9f9fa636474b708b9b36
See Ia9081d92ae9aea50d863455be770eecd0c73be1a for multi-selection
counts.
Test: Manually checked logging happens as per go/tron-howto and verified
nothing is broken in related classes by running:
bit FrameworksCoreTests:android.widget.TextViewActivityTest
bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Bug: 32572232
Change-Id: I4ceab136ab73a20c6bc56732f7606ed103fe64d3
Fix a bug where the internal date/time picker views reused view IDs
causing state save/restore bugs when placed within AlertDialogs and
other places. Since the pickers already save/restore their state at a
higher level leaving this enabled was redundant.
Bug 32654446
Test: manual
Change-Id: I3df2fc932ac5296ab6eb0a5013dddef8d1117635
Previously, onDragEvent() tried to set the anchor even if
the text was not Spannable. Now we check to make sure it is
Spannable before trying to set the selection.
Test: cts-tradefed run cts-dev --module CtsTextTestCases
Change-Id: I835bf3d6024bf3c85e1d248458829eef496ad93d
Fixes: 37261326
Running cancel after toast is shown and adding some UI stress (or sleep
on UI thread) causes a crash from toast when trying to add the toast
window to the display. The toast must be triggered from app that is
above N MR1 (25).
The steps that crash the app are:
1. Show toast (Toast.makeText(...).show()), window token is created
2. Immediately cancel toast (Toast.cancel()), window token is removed
3. Stall UI thread (Thread.sleep, heavy task), both show and cancel
events are queued to UI thread from window manager
4. Crash trying to add toast but no window token exists
In Toast:handleShow(), the mNextView is required to add the toast to
display, if the mNextView is null before posting to window manager, then
when handleShow() runs later, it will ignore adding the toast to
display. The issue before is that mNextView is set to null after cancel
runs back from window manager in UI thread but the show post will always
happen first. Therefore set mNextView to null at the beginning of
cancel will ignore adding the toast to display and avoid the crash.
Bug: 37606432
Test: manual - write an app to Toast.show(), Toast.cancel(), then
Thread.sleep(), set app's sdk usage above 25 (N MR1) and show the
toast
Change-Id: I352e296c47b1b8776c78b6b0943b1dc809963026
We decided its better for tab to do something than to have no
tab navigation within GridView.
Also fixed a small bug that made backwards focus order not work
right.
Bug: 38264959
Test: Manually tested in test-app. Added basic CTS for tab keys
Change-Id: I8236deed26e6d8b8cae0130359b104af4d9a244d
Previously the icon was an event icon, but a clock icon is
more appropriate so we are switching to that instead.
Bug: 37351390
Test: Open time picker
Change-Id: I47e6caf3c341c10264168004628288fd00e4601a
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Change-Id: I0b5ebb8d6f1af1a9938151f758a2feedb14fcb9f
Fixes: 38244876
Some apps were relying on TextView favoring focusable over
focusableInTouchMode when they were explicitly set to
opposite values in XML (usually because they start with an
EditText and only set focusable=false). This behavior is
undefined (and is, in-fact opposite to every other View).
In order to keep backwards-compatibility, this restores
the old behavior.
Bug: 36497135
Bug: 37916052
Test: Tested those apps and they behave like they used to.
TextView CTS still passes.
Change-Id: I65bd1b343a6dfb087f41c9fc8af4b5c1e4c71493
Logs:
- Smart selection occured
- TextView menu item activated on smart selection
- Smart selection reset
- Smart selection modified
Test: Manually checked logging happens as per go/tron-howto and verified
nothing is broken in related classes by running:
bit FrameworksCoreTests:android.view.textclassifier.TextClassificationManagerTest
bit FrameworksCoreTests:android.widget.TextViewActivityTest
Bug: 32572232
Change-Id: Ia9081d92ae9aea50d863455be770eecd0c73be1a
When configuring a TextView to auto-size via min/max/granularity
do the calculations in float pixels and only convert to int (via
rounding, see TypedArray#getDimensionPixelSize) to produce the
final text size values to be used by the auto-size algorithm.
This is because the previous version where the values were
initially directly converted to pixels and only after used in
calculations was losing precision and was not consistent with how
we deal with preset configuration (and the developer
expectations).
Practically
textView1.setAutoSizeTextTypeUniformWithConfiguration(10, 20, 2,
TypedValue.COMPLEX_UNIT_SP)
and
textView2.setAutoSizeTextTypeUniformWithPresetSizes(
new int[] {10, 12, 14, 16, 18, 20},
TypedValue.COMPLEX_UNIT_SP);
produce exactly the same values in pixels to choose from when
auto-sizing (on any device) =>
(TextView#getAutoSizeTextAvailableSizes())
Bug: 38185233
Bug: 37265610
Test: attached in the same topic
Change-Id: I95cbbf4674e98f080d7752ae350df26b4adf31b4
