The example ImageView at the beginning of the class description now
includes a content description attribute. Also updated the links in
the first paragraph where code fonts aren't necessary.
Test: make ds-docs -j32
Bug: 138856073
Change-Id: I33a75dc31d68289d955979d2fe8afe2ae3d4770e
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
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
Sometimes widget providers hardcode colors in their remoteViews
by loading them from resources. On UI mode change, this can lead to
inconsistent UI if some widgets use a different configuration
than others.
Test: Verified with calendar widget on device
Bug: 133064045
Change-Id: If47a6b1973f55b7590f5d4116813d6a332951697
Update the documentation for WebView.findAddress, as well as the related
functionality in Linkify and TextView, to clarify why the method is
deprecated, why it should not be used, and that it can cause unexpected
exceptions to be thrown from several places on older OS versions.
Fixes: 24676033
Test: m offline-sdk-docs
Change-Id: I45d82b9a4c9cf62d9566898dd21cd2139ad98f37
The CL adds PixelCopy failure handling in Magnifier. Previously, if the
content copy failed, the Magnifier would still render the shadow,
therefore displaying an empty rectangle shadow frame. The CL fixes this,
avoiding displaying anything if the PixelCopy request fails.
Test: atest CtsWidgetTestCases:android.widget.cts.MagnifierTest
Bug: 132136368
Change-Id: I66715c56770380afafa5af5a3ee976bcaaa5ba1e
(cherry picked from commit 3aa46b2dd0)
Merged-In: I66715c56770380afafa5af5a3ee976bcaaa5ba1e
Background:
The applications with the granted INTERNAL_SYSTEM_WINDOW and
INTERACT_ACROSS_USERS_FULL means that it could show the same
window for all of users. i.e. to use user 0 presents all of
UI things to all of users.
INTERNAL_SYSTEM_WINDOW usually comes with INTERACT_ACROSS_USERS_FULL
because it will serve all of users to know the information that
comes from framework and system server.
Solution:
Because SystemUI never restarts after the user changing,
ClipboardService can't tell if the callingUid has the the same userId
with the current user or not. The solution is to use the permission
check. Especially, INTERACT_ACROSS_USERS_FULL and
INTERNAL_SYSTEM_WINDOW. To check INTERACT_ACROSS_USERS_FULL by using
ActivityManagerInternal.handleIncomingUser.
Caution:
The application with INTERNAL_SYSTEM_WINDOW usually use user 0
to show the window. But, the current user is user 10, WindowManager
know the focus windows is belong to user 0 rather user 10. That's
why user 10 can't copy the the text from systemui directly reply to
the other applications.
Readability:
ClipboardService use callingUid everywhere but actaully it is not
appropriated to fix this kind of bug. This patch refactor the naming
to produce two name. i.e. intendingUid and intentdingUserId that are
validated by ActivityManagerInternal.handleIncomingUser.
Test: manual test
Test: atest android.widget.cts.TextViewTest
Test: atest CtsTextTestCases
Test: atest CtsContentTestCases
Bug: 123232892
Bug: 117768051
Change-Id: Ie3daecd1e8fc2f7fdf37baeb5979da9f2e0b3937
Otherwise it's hard to keep track of things happening or not, since
the request would be postponed, leading to bugs elsewhere.
Test: Wait for time to pass on lock screen
Test: Enter/leave AOD
Fixes: 132955195
Change-Id: I54f806f9dd2d1cf4acac420bab08d4579f867a5f
This reverts commit 1600c5a615.
Reason for revert: Rolling forward for Q-Finalization
Bug: 129975435
Change-Id: I1ffb8162cb5e6f386fd3c417fabfd4298ef86ffd
A previous change restricted rules that are added to the rule dependency
graph to resource ids rather than just integers greater that zero.
Restore the previous behavior and also allow for negative resource ids
to work as expected.
Bug: 132447676
Test: loaded maps and view looks as expected
Change-Id: I88d86c77c696d1e494a743fdd2e398283383c64e
