Fix two issues that caused the exclusion for SeekBar thumbs to be to small and offset
from the thumb:
Account for padding and thumb offset; the thumb drawable is drawn with an offset
from the View's Canvas; the same offset must be applied when udpating the exclusion
rects.
The thumb is typically much smaller than the drag zone; the thumb rect alone doesn't
provide an appropriately large exclusion for reliably hitting it, so it is enlarged
to the height of the seek bar (up to 48dp).
Bug: 138992366
Test: manual, show exclusion zones with: adb shell setprop debug.pointerlocation.showexclusion 150 && adb shell settings put system pointer_location 1
Test: atest android.widget.AbsSeekBarTest
Change-Id: I2b670c6f3f33451bdccdfd3d75a75e90260257ff
In Q, these APIs were either:
- removed from the greylist entirely without good reason
- Moved to the restricted greylist without any public alternative
information added
So they are being moved back to the greylist for Q.
Test: Treehugger
Bug: 136102585
Change-Id: I5ac8b8b9b23c3789d80239cf456072cc7dfa1203
Touching the thumb on the Seek bar prevents the thumb from immediately jumping to a new position and changing the progress of the Seek bar.
Test: Place your finger on the seek bar thumb so that your finger touches the thumb. Take your finger away. Seek bar should not change progress and thumb's position.
Place your finger on the seek bar thumb so that your finger touches the thumb. Seek bar should not change progress and thumb's position. Then, without lifting your finger from the screen, move your finger towards the maximum or minimum value. Seek bar thumb should follow your finger while maintaining its position relative to your finger.
Change-Id: Ia72d247662ad5b8dd66d0b0578098b9a2b6060cd
android.text.format.Time is limited to 32-bit seconds from the
beginning of the Unix epoch and so classes that use it are limited
to 1901 - 2038. Switching to java.time avoids this issue.
Manual Testing:
AnalogClock is deprecated and not used anywhere so difficult to
test.
DateTimeView is used in the status bar. Behavior was verified with
current date/time and also Europe/London around 2019-03-31 01:00
(skip forward) and around 2019-10-27 02:00 (fall back). The time picker
in settings uses android.icu.util.Calendar which favored the later time
if there are two local times with the same display time (e.g. the
fall back case). The "repeat" case was tested with "date @1572137900"
to set the clock to "the first" 01:58, then waiting 2 minutes to
ensure that the 01:59 -> 01:00 transition occurs correctly.
Bug: 16550209
Test: build / boot / treehugger
Test: See above
Change-Id: Ibadad3041a2e54fe12d347960bf1e0f3ebe10c01
Before this CL, the magnifier could deadlock when the following
happened:
1. the renderer is asked to draw (and a frame callback is provided)
2. a #dismiss() happens on the UI thread. This acquires mDestroyLock
(previously line 309)
3. InternalPopupWindow#destroy() is called, and this calls
mRenderer.destroy(). This attempts to destroy the renderer on the UI
thread, however the UI thread will wait until the pending frame callback
corresponding to step 1 is executed on the render thread.
4. The frame callback starts executing on the render thread, and tries
to acquire mDestroyLock (previously line 1093). However, this is held by
the UI thread, so a deadlock happens.
This CL completely removes mDestroyLock, relying on the existing
synchronization between the UI and render threads described in step 3.
Bug: 134584742
Test: manual testing
Change-Id: Ia4c75b5b997e0ed94d5a3814dd4507a8fffa124d
Something can be clickable and disabled. Returning early here prevents that state to be reflected in ListView items.
The reported bug was happening because the items were disabled, but they weren't being reported as clickable.
Talkback doesn't read "disabled" for disabled items unless they are also actionable in certain ways.
Test: CTSAccessibility*, CTS AbsListViewTest, CTS ListViewTest, tried UI with sample app.
Fix: 131281972
Change-Id: Ic9b8c995398151f084d194e272ce082ec345e517
