We added APIs to allow an accessibility service to extend the
selection while moving the cursor at a given granularity such
as word, character, etc. The problem is that the traversal was
extending only the end of the selection while moving forward
and the start of the selection while moving backward. This leads
to a case in which the user cannot shrink/extend the selection
because for example instead of shrinking the end of the selection
the implementation was extending the start.
Now extending the selection moves only the selection end. This is
the same behavior as text view using a keyboard.
Tests: https://googleplex-android-review.googlesource.com/#/c/307062
bug:8839844
Change-Id: Id6965b102647df909f61301fcc8ec05458dd5881
This lets apps get the audio session id of the video being played, so
they can apply effects to the audio track.
b/8767565
Change-Id: Iaa39d97d0b6fb528ed04b52d579afa58444ebcfe
AbsListView is backed by an adapter. After the adapter data changes
the view sets a flag that its state is dirty and requests a layout.
If an accessibility service asks for the state of a list item at
this point, it may incur an error since the views and the adapter
are not in sync.
Now if an accessibility service queries for a list item when the
data set is changed and the item views are dirty, we pretend the
children do not exist. After the layout happens, we notify the
accessibility layer that the screen content changed so it can
refetch the views if desired (this notification mechanism is
already in place in AbsListView#handleDataChanged()).
bug:8433433
Change-Id: I4287a0ac2ef6bb33f1f988d5ddad973556c305ca
1. UiAutomation#executeAndWaitForEvent method was invoking the passed
runnable while holding the lock which may lead to a deadlock. For
example: a runnable that calls getActivity() gets us into a state
like this.
2. UI automation services did not get all capabilities such a
service can have. Now a UI test service gets all of them.
3. When UiAutomation was exiting for event fired as a result of a
performed action, it was checking whether the received evnet time
is strictly before the time of executing the command that should
fire the event. However, if the execution is fast enough, i.e.
less than one millisecond, then the event time and the execution
time are the same. This was leading to a missed signal in rare
cases.
4. AccessibilityNodeInfoCache was not clearing the relevant state
for accessibility focus clearing event.
5. Accessibility text traversal in TextView was partially using text
and partially content description - broken. Now we are using the
text since for text view and content desc for other views. In other
words, we are using the most precise text we have.
6. AccessibilityManagerService was not granting capabilities of a
UiAutomation service - plainly wrong.
CTS change:https://googleplex-android-review.googlesource.com/#/c/300693/
bug:8695422
bug:8657560
Change-Id: I9afc5c3c69eb51f1c01930959232f44681b15e86
The fix in:
https://googleplex-android-review.googlesource.com/#/c/300346/
worked but the constant used had an extra trailing zero - which was confusing
and put a 1 in the 'flag' space of the measurement spec.
The intended number was:
0x00800000
Unfortunately, this intended constant doesn't fix this bug.
The constant submitted in this fix is:
0x00010000
which is outside the 'flag' space of measurement specs and appears to steer clear of overflow
problems in the scenario of this bug.
As suggested in the submission above, it would be preferable to rework of the RTL code to avoid
the use of such a constant as it seems very unlikely indeed that any choice of integer can
avoid problems in all cases.
Change-Id: I0c6744257ef2aebe8dbc8c041a447f9b90ee4b84
GridLayout is working as intended here. The bug is appears to be in RelativeLayout
(and possibly LinearLayout).
The value of RelativeLayout.DEFAULT_WIDTH = Integer.MAX_VALUE/2 is 0x3FFFFFFF has bits
set in the range that is used to flag certain conditions and states by the layout system.
In View we have:
MEASURED_SIZE_MASK = 0x00ffffff
MEASURED_STATE_MASK = 0xff000000;
MEASURED_STATE_TOO_SMALL = 0x01000000
This change fixes this bug, though it looks as if that a safer solution would be to not introduce
this constant and code path in the first place - as RelativeLayout's measurement algorithm operates
in the LTR case without it.
Change-Id: I01c51ae854620f08dd63047594486a3464c86f3a
The rendering code optimizes by rejecting drawing operations that
lie outside of the bounds of their views. This works in most
situations, but breaks down when containers have called
setClipChildren(false), because we reject drawing that is outside
of that container, but which should be drawn anyway.
Fix is to pass in the value of that flag to the DisplayList drawing
routines which take that flag into account when deciding whether
to quickReject any particular operation.
Issue #8659277 animation clipping
Change-Id: Ief568e4db01b533a97b3c5ea5ad777c03c0eea71
Fix for bug 8656899 API REVIEW:
android.util.PropertyValueModel/ValueModel,
android.widget.ValueEditor etc
Revert the change that added this API to remove it outright.
This reverts commit 989709a973
Change-Id: I9018cd8dadb1b1a54ad8749c816bd02bb7e7a38b
- in AbsListView, force setScrollbarPosition() when RTL properties change
- in FastScroller, invalidate the correct rectangle when in RTL mode and in STATE_EXIT
Change-Id: Ie9fe4f826e179eb993e443d10e171b9dda3b6f3f
Adding features which round out the animation APIs (missing
getters, etc.). Also fix doc typos.
Issue #8350510 Add APIs needed for future animation capabilities
Change-Id: I063736848ba26e6d6c809b15fc3a103c74222f46
In single line mode, changing the text from LTR to RTL (or vice versa)
affects the alignment, which in turn means that bringTextIntoView is
needed to update the scrolling. A registerForPredraw should be done to
make this happen, but it was missing. This patch tests explicitly for
direction changes in this case, and schedules a predraw if so.
Change-Id: I16e0e23141c244dc8adc00ea8306dfe4c9bf487d
Several conditions can cause an AbsListView's data set observer to be
removed and nulled out. If for some reason the view receives duplicate
onDetachedFromWindow events this could cause AbsListView to attempt to
unregister a null observer. Skip this unregister process if this
happens.
Bug 7088152
Change-Id: Ib0c630d1ee598640512023e4ef158f01e3ed474d
1) Make the box with the permission really go away when a
permission is revoked, not just invisible.
2) Change the order of the buttons, making the negative
button the "revoke" button, and the positive button "ok".
Change-Id: I73694583cbd014d3820f8df6c6b770caae299499
Add UI support for revoking optional permissions. When the user
taps on an optional permission, two new boxes will appear:
[Cancel] | [Revoke]
Selecting [Revoke] will revoke the permission from the app.
The [Cancel] / [Revoke] options are only shown for apps which support
optional permissions.
Bug: 8332307
Change-Id: I27e374773747737e3a6d7f48ea1448a0178e3393
Check for file:// Uris inside Intents, ClipData, Notifications and
RemoteViews when StrictMode option is enabled.
Also introduces Intent.prepareToLeaveProcess() to uniformly handle
Intents about to leave an app process.
Bug: 8529070
Change-Id: I8efb43877cbc5f21eb029fc6492b3ee1415059ef
Modify isDisplayablePermission to display a permission if the
app update will grant a new optional permission to the app.
Change-Id: Ic647826b0c48f9f7ec8e4f69b90197211f83278d
Add optional permission support to isDisplayablePermission.
A permission is displayable if it's required, or was previously
granted to the app.
Currently, this change is a no-op. The package parser code
does not currently honor <uses-permission android:required="false"> in
the application's manifest, and assumes a permission is always required.
This change sets the ground for future optional permissions work.
Change-Id: I2ec4a49adbfab9980e116ed43354f16bdeaa301d
The earlier patch 3cf7b3c59 introduced a stability regression. Perform
the appropriate bounds checking alongside the fix it implements.
Bug 8264185
Change-Id: I943d6c05bacdd777f89243fdac97788b16639dc6
