When we fix uris by adding the user id they belong to, the extras
of the intent are unpacked and repacked. This must not happen
inside the system process. It happened when ResolverActivity was
handling an activity intent coming from a different user.
BUG:18198630
Change-Id: I869897013bb2e5522584b404e87a8f20e7943b60
When printing from two apps at the same time the second print UI is
getting stuck. There were a couple of issues here:
AdapterView was not notifying for item selection if the data changes
after scheduling a dalayed selection notification and the notification
execution. The code assumed that a layout pass will occur and posponed
the notification after the layout pass but it is not guaranteed that
such a layout pass will occur. Now we delay only if a layout pass is
being scheduled.
Also when binding to the PDF rendering service the print spooler was
using the same intent and as a result two print activites were getting
the same renderer instance while they should get separate ones. Now
we use different data in the intent to ensure we get separate renderer
instances.
Change-Id: I6aa7c7b041957804b4273549dd837a6d70064efc
Also adds IntArray, which is like LongArray for integers, and prevents
the AM/PM label text in the time picker header from wrapping.
BUG: 17468036
Change-Id: I7120089885709f23e20368927e4b3ed9db2e5393
- Change 'protected' to 'package private'.
- Change '@hide' to '{@hide}' for methods which should be still hidden
for linting.
- Rename addVendorCommandListener to setVendorCommandListener and make sure to be called once.
- Fix the implementation of removeHotplugEventListener().
Bug: 18063669
Change-Id: I5c032736f17bab9518f21596f7adeac2f88ba4c1
Bug 17936593
Instead of calling setLeft(), setTop(), setRight(), setBottom()
separately, make one call that does all at the same time.
Change-Id: I986274f3a98b3136e71204501ffc272986ad31dd
For now, only animators use it but we can consider migrating
drawable cache to it as well.
Bug: 17456416
Change-Id: I571b96856805edb171f0fc52e6bff5a365f46b70
In explore by touch mode the user performs a double tap to click on
an item. In this case the system sends down and up events at the
location of accessibility focus. The accessibility focused view may
be partially covered. In order to click in this view we compute a
point where to send the down and up events. This clicking strategy
is a bridge-gap and we will switch to accessibility actions in the
future.
When computing the point to click we were taking into account whether
the view was covered by a clickable sibling or a clickable sibling of
a predecessor. Despite our expectation cases in which this is not
enough happen in practice. In particular, the focused view may be
covered by a clickable descendant of a non-clickable sibling of a
predecessor that covers the focused view. This change takes care
of handling this case. Note that computing the click point is a fair
amount of work but this happens very rarely and on demand. Also the
code is short circuiting where possible.
Change-Id: I4d3cd8b67a7baf0bcc12f370ea7ba1b04c42c355
