Bug: 65354043
When an empty AnimatorSet is used in a fragment animation,
it can end immediately. This CL properly detects this
case and handles it properly.
Test: manual, ran fragment CTS
Change-Id: I63bee3818106f9c8e86cdc94af61d6bc8407c789
Line height calculation with maxLines set to zero displayed a single
line when BoringLayout was used. This CL fixes it to show zero lines.
Test: Added related CTS tests to TextViewTest and EditTextText
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: bit CtsWidgetTestCases:android.widget.cts.EditTextTest
Bug: 65435738
Change-Id: Ic21eb50b31666b2dcc2398278010fa072ea1ff67
This logs when the selected text is changed e.g. by typing on
the hard or soft keyboard.
Bug: 64914512
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Merged-In: I82b3b2157856c607d08a82c0a3d9fb938af4c06a
Change-Id: I82b3b2157856c607d08a82c0a3d9fb938af4c06a
- Fix count with selection start index inside a word
- Properly handle whitespace characters
- Set the model version tag
Bug: 64914512
Test: bit FrameworksCoreTests:android.widget.TextViewActivityTest
Test: bit CtsWidgetTestCases:android.widget.cts.TextViewTest
Test: Manually tested that logs are correct. Will follow up with automated tests.
Merged-In: Ib73b52ebce999f2cb6e5734e556cd09e47c89a29
Change-Id: Ib73b52ebce999f2cb6e5734e556cd09e47c89a29
No change to logic, docs only.
This documents shouldInterceptRequest request behavior when Safe
Browsing is enabled, with recommendations for how this can be avoided
depending on the application's needs.
Bug: 65555402
Test: make docs (manually verify links all work)
Change-Id: I055254bfae3a06061402c519e8740ec4d9779e8f
This CL reverts my previous CL [1] that aimed to get rid of
a nasty compatibility hack that was introduced for Bug 36345857.
For those who are interested in, what happenned are:
1. @hide method SurfaceView#setWindowType() was removed [2].
2. It broke some app (Bug 36345857). We had to work around
it by re-introducing SurfaceView#setWindowType()
temporarily [3].
3. Some app switched to the correct implementation when
running on Android O devices.
4. We removed that compatibility hack [1] (Bug 62054282).
5. Android O MR1 is set to be "REL" [4].
6. It broke some app, probably because of some unfortunate
mistake in the version check logic in that app.
7. We end up introducing the same hack again for O MR1.
[1]: Icee198c554de558cfa4ffe0b264064969839654e
7a1ad6d97c
[2]: Ie56b6f7ab16f32d7fc459b8eba26594337ad55de
d5c7dd6da8
[3]: I5217f6417a73690ae8a978754218b7b089070fdd
3b5011afc9
[4]: I054e3ecff49803e61e7741753fe6764a567d72c4
62a835d0ef89e51f4a97fecf8576224551b545a5
Bug: 36345857
Bug: 62054282
Fixes: 65508814
Test: Manually verified that Bug 65508814 is not reproducible
Change-Id: If8a3f726789daa22f73e1962e938f071d3c09414
...and screen was flickering badly
Don't crash if we get a bad pointer ID, just log a wtf
for us to find in APR.
Bug: 65333586
Test: manual
Change-Id: I6f522e05735a64b672c011012c3e3514d454dd8f
Bug: 65268614
When an activity transition was used with the top activity being
translucent, and the top activity calls finish() instead of
finishAfterTransition(), the transitioned views were not being
drawn properly. The source of the problem was that
setTransitionVisibility() was being used instead of setVisibility().
Transitions normally use setTransitionVisibility() to modify
the view's visibility without triggering an invalidation. But
when we want the view to be invalidated by the visibility change,
setTransitionVisibility() prevents the invalidate() from
actually invalidating the view.
Test: manual
Change-Id: I250ea232052d1a1309d3341504cba77543a94eec
This is needed to help with differential aging.
The nav needs to be white with a 1dp divider on it, so add support
for the divider and add hidden attribute to set the nav buttons
inverted.
Change-Id: I4a5329f7486a6774ca4de8362caebbe8ba421aad
Test: Open settings
Bug: 63630024
No longer used by Settings as the logic was wrong.
Test: gts-tradefed run gts -m GtsOemLockServiceTestCases
Bug: 65124732
Change-Id: I44e5f697aabd2b5eefecf64060502b5c9ef5f911
(cherry picked from commit d37fe2d3e1)
TextView#performLongClick() calls View#performLongClick which
calls View#performLongClickInternal() which, if handled, performs
the longpress haptic feedback and returns handled. TextView
looks at this return value and if it is true then makes another
call to perform longpress haptic feedback. Remove the duplicate
call in TextView as the one in the parent (View) is sufficient.
Bug: 65397911
Test: manual
Change-Id: Ic73a86637486d5382b63f1c1b37783e238452841
