Sometimes a client needs to hold onto an accessibility node info and
this info may get into a stale state. The clent has to be able to
request a refresh of the info. This change adds a refresh call to
AccessibilityNodeInfo.
bug:6711796
Change-Id: I580a9a5d9fd1f705ea0a2cf4d3ff65543714c9c3
Bug: 7660973
RemoteViewsAdapter will now store the userId as part of the cache key
when caching remote views to optimize for orientation changes.
Change-Id: I7c4e52b3995d4f56ebfa35aa9516327e182ad892
1. The screen magnification feature was implemented entirely as a part of the accessibility
manager. To achieve that the window manager had to implement a bunch of hooks for an
external client to observe its internal state. This was problematic since it dilutes
the window manager interface and allows code that is deeply coupled with the window
manager to reside outside of it. Also the observer callbacks were IPCs which cannot
be called with the window manager's lock held. To avoid that the window manager had
to post messages requesting notification of interested parties which makes the code
consuming the callbacks to run asynchronously of the window manager. This causes timing
issues and adds unnecessary complexity.
Now the magnification logic is split in two halves. The first half that is responsible
to track the magnified portion of the screen and serve as a policy which windows can be
magnified and it is a part of the window manager. This part exposes higher level APIs
allowing interested parties with the right permissions to control the magnification
of a given display. The APIs also allow a client to be registered for callbacks on
interesting changes such as resize of the magnified region, etc. This part servers
as a mediator between magnification controllers and the window manager.
The second half is a controller that is responsible to drive the magnification
state based on touch interactions. It also presents a highlight when magnified to
suggest the magnified potion of the screen. The controller is responsible for auto
zooming out in case the user context changes - rotation, new actitivity. The controller
also auto pans if a dialog appears and it does not interesect the magnified frame.
bug:7410464
2. By design screen magnification and touch exploration work separately and together. If
magnification is enabled the user sees a larger version of the widgets and a sub section
of the screen content. Accessibility services use the introspection APIs to "see" what
is on the screen so they can speak it, navigate to the next item in response to a
gesture, etc. Hence, the information returned to accessibility services has to reflect
what a sighted user would see on the screen. Therefore, if the screen is magnified
we need to adjust the bounds and position of the infos describing views in a magnified
window such that the info bounds are equivalent to what the user sees.
To improve performance we keep accessibility node info caches in the client process.
However, when magnification state changes we have to clear these caches since the
bounds of the cached infos no longer reflect the screen content which just got smaller
or larger.
This patch propagates not only the window scale as before but also the X/Y pan and the
bounds of the magnified portion of the screen to the introspected app. This information
is used to adjust the bounds of the node infos coming from this window such that the
reported bounds are the same as the user sees not as the app thinks they are. Note that
if magnification is enabled we zoom the content and pan it along the X and Y axis. Also
recomputed is the isVisibleToUser property of the reported info since in a magnified
state the user sees a subset of the window content and the views not in the magnified
viewport should be reported as not visible to the user.
bug:7344059
Change-Id: I6f7832c7a6a65c5368b390eb1f1518d0c7afd7d2
An earlier fix to allow requestLayout() to be called during layout
didn't handle some of the requests properly, leaving some nodes
stranded with layout requests that didn't propagate all the way
up the hierarchy. The fix is to do, on the second layout pass, exactly
what we do in a normal layout pass: run measure, then layout.
Issue #7657033 Checkboxes not being updated immediately in Settings
Change-Id: I90be3992d3441e8f43629d26c8386c81a7c31482
This was initially about the Clock widget crashing repeatedly on some
devices with multiple users. Turned out that there were race conditions
when switching users that could result in remote views of one user calling
back to the RemoteViewsAdapter in keyguard that in turn sent an incorrect widget id
to a different user's widget, resulting in a crash.
Since KeyguardHostView is instantiated in the same process for different users,
it needs to carry a user identity to pass along to AppWidgetService so that
remote views services were bound to the correct user and callbacks were attached and
detached properly.
Added some aidl calls that take the userId to do the binding properly. A more
complete fix might be needed in the future so that all calls from Keyguard carry
the user id.
Also, there was a problem in comparing host uid for secondary users, since Settings
for a secondary user has a different uid than keyguard. Not an issue on single-user
systems. Changed the host.uid comparison to accomodate for the secondary user.
Bug: 7450247
Change-Id: Idbc36e3c60023cac74174f6cb7f2b2130dd3052c
1. Removed the support for infinite pool size which nobody was using and
does not make sense.
2. Update some classes in ViewGroup to use the poolable APIs.
Change-Id: Ifdb8c10968cd06fe53085ec9d3d649f7c9a944b7
- remove unnecessary calls to resetRtlProperties().
- now reset of RTL properties will only be done when adding a View
(and no more when removing it)
Change-Id: I0d42128c9f7df6085fb92bb5af5c9bd4d1ba88a3
