Since the core implementation of TabHost is LocalActivityManager, which
was deprecated for several years. It does not make sense to maintain
TabHost and TabWidget.
Test: flash and build
Bug: 137825207
Change-Id: Ifb62dbe68c8ada8499dd5336a189c803f2ae3dc1
Test: Twisted talkback code to perform scroll down when scroll forward
is called. Verfied that scroll down is successfully performed in the
framework code and the number picker behaves correctly. Also verifed the
scroll up/down actions are correctly added to AccessibilityNodeInfo.
Bug: 136277517
Change-Id: I540d2ed3bf4e6b733668853182bd38faa8545997
Sys UI runs on user 0. This can lead to the TextClassifier (TC)
running for the wrong user. Consequencies are user A can launch apps
in user B via the TC's predicted actions and selected text being
unintentionally shared from user A to an app running in user B.
This fix ensures that the correct user id is passed and verified for
every TC request going across process boundaries (i.e. via SystemTC).
- Sys UI sets the appropriate user id in the TextView
- TextClassificationManager (TCM) system service is constructed using
a context generated from this user id
- SystemTC sets this user id before querying the TCMService
- TCMService validates the user id before forwarding the request to
the TCService belonging to that user id.
Bug: 136483597
Test: atest android.view.textclassifier
atest android.widget.TextViewActivityTest
(manual) Verified according to steps in bug 123232892
Change-Id: I2fdffd8eb4221782cb1f34d2ddbe41dd3d36595c
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
Updated all callers of SC.remove to use Transaction.remove(sc) and apply
immediately since that's the equivalent. Eventually, the transactions
that contain remove could combine with other transactions if it makes
sense to avoid duplicate applies.
Test: SurfaceControlTest
Change-Id: I13c6ec86de6a6d60f142c2269337557510dd006d
This wasn't happening for RecyclerView, and that resulted in lost focus after scroll animations.
This is cause Talkback relies on changes in getScrollX/Y to determine if it should do anything about a TYPE_VIEW_SCROLLED AccessibilityEvent.
This squashes a big subset of "losted focus" bugs.
This is most painfully felt when you fling a RecyclerView and in ViewPager page transition, both resulting in slightly longer animations.
Also, change the default value of m[Max]Scroll[x/y] to reflect the above.
Change-Id: Ibe66260fbfc61c98ca88e1b2d9552ed116e44c15
Fix: 125385883
Test: CTSAccessibility*, Tried a few RecyclerViews on device, and ViewPager2 sample app.
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
