1. Currently the system fires accessibility events to announce the
start and end of a touch exploration gesture. However, such a
gesture starts after we have decided that the user is not
performing a gesture which is achieved by measuring speed of
movement during a threshold distance. This allows an accessibility
service to provide some feedback to the user so he knows that
he is touch exploring.
This change adds event types for the first and last touches
of the user. Note that the first touch does not conincide with
the start of a touch exploration gesture since we need a time
or distance to pass before we know whether the user explores
or gestures. However, it is very useful for an accessibility
service to know when the user starts to interact with the
touch screen so it can turn the speech off, to name one
compelling use case.
This change also provides event types for the start and end
of gesture detection. If the user has moved over the threshold
with a speed greater than X, then the system detects gestures.
It is useful for an accessibility service to know the begin
and end of gesture detection so it can provide given feedback
type for such a gesture, say it may produce haptic feedback
or sound that differs for the one for touch exploration.
The main benefit of announcing these new events is that an
accessibility service can provide feedback for each touch
state allowing the user to always know what he is doing.
bug:7166935
Change-Id: I26270d774cc059cb921d6a4254bc0aab0530c1dd
1. The layout containing the text of a Switch is initialized on measure
and if an accessibility event is fired before that then a NPE happens.
bug:7169419
Change-Id: Iee3c01ca9157d14d228c4ff33c0810507e0e25a7
Bug #7165793
A ViewRootImpl's root view can be null. Check for this condition to
prevent an NPE invalidateWorld(). Other messages perform a similar
check to properly handle the case where mView == null.
Change-Id: I5bcfc41c48a469d38b21be74df2f6c715b0f9352
Oops. Stacked bugs: first, the desired user handle was not properly
being passed from the call() entry point to the database operations;
then on top of that, the client-side cache management was still
looking in the local user's cache for the data, so a request to read
a different user's settings would return the local user's instead if
that key was already known to the local user's cache.
Reads and writes of a different user's settings are now uncached,
so they're relatively much slower. They're rare, however, so this
is not something to worry about unless we encounter a real world
case where it's a significant factor.
This CL also adds a bit of cross-user settings read/write testing
to the existing provider suite. These new tests caught both the
known wrong-user-write bug and discovered the client-side cache
bug, so yay.
Finally, the existing wholesale mutual-exclusion approach would
deadlock in certain circumstances due to the fact that the
settings database creation code might have to call out to the
Package Manager while populating the bookmark/shortcut table,
and the Package Manager would then call back into the settings
provider in the course of handling that request. The synchronization
regime has been significantly tightened up now: now the database
code [which is known to deal with concurrency itself] is allowed
to cope with multiple parallel openers of the same db; this
allows the settings provider to avoid calling out to other parts
of the system even implicitly while its internal lock is held.
Change-Id: Ib77d445b4a2ec658cc5c210830f6977c981f87ed
1. For accessibility purposes it is important to be able to associate
a view with content with a view that labels it. For example, if
an accessibility service knows that a TextView is associated with
an EditText, it can provide much richer feedback.
This change adds APIs for setting a view to be the label for another
one and setting the label for a view, i.e. the reverse association.
bug:5016937
Change-Id: I7b837265c5ed9302e3ce352396dc6e88413038b5
Activities which help select an account gather the list of accounts only during create and dont update it agian. When a user moves out of the account selection activity by clicking home page, deletes an accout in the background and comes back to the earlier accout selection activity, the deleted account still exists as an option. This cl fixes this by updating the account list on resume.
Bug: 7135608
Change-Id: Idc9a2fa6451b032310c0ad66f6db0e2f0967feeb
The mAttachInfo.mSystemUiVisibility value was changing in
View.dispatchAttachedToWindow but
mAttachInfo.mRecomputeGlobalAttributes was not being set.
Consequently ViewRootImpl.collectViewAttributes was returning
without updating the subtreeSystemUiVisibility. This is fixed
by calling needGlobalAttributesUpdate in dispatchAttachedToWindow.
WIthin ViewRootImpl.collectViewAttributes the assignment to
subtreeSystemUiVisibility was only being made if
mAttachInfo.mSystemUiVisibility was changed within
collectViewAttributes. But mAttachInfo.mSystemUiVisibility
was changing outside of collectViewAttributes in
dispatchAttachedToWindow. Consequently subtreeSystemUiVisibility
was never updated. By looking for a mismatch between
subtreeSystemUiVisibility and mSystemUiVisibility
subtreeSystemUiVisibility gets assigned whenever it is out of
sync.
Fixes bug 7091817.
Change-Id: I1e97a7dec14dc9594876175ae26370fb9030a8a6
* changes:
DO NOT MERGE Push event logging down into libcore.EventLogger
DO NOT MERGE Added event logging for config installation failures.
DO NOT MERGE Create intermediate directories when installing config data.
DO NOT MERGE Add components for the Android Config Updater to system server.
Now we can bind to just one instance of DCS, instead of requiring
one-per-user. This also means we can operate on otherwise-stopped
users.
Bug: 7003520
Change-Id: I4881e064ae8942907f6a02c6b868926223455cdc
This changes the default behavior of the EventLogger from logging
to the normal logs to logging to the event logs.
Change-Id: I4338a1605928b82246a369adb3514bd31cd552e8
Conflicts:
core/java/android/app/ActivityThread.java
Also tidy up the bookkeeping for a few settings that were earlier
moved to Global without the redirect tables being fixed up.
Change-Id: I69275db3b2636cd6ba9c8c51b88e97d8ba4b7b7d
Previously, an animator that had been reverse()'d (and was thus
playing backwards) would not end() at the right value. That is, a call
to end() would cause the animation to snap to its original end value, not
the reverse-playing end value (i.e., its start value). Logic to handle
calculating the proper end value was not taking the reversing behavior
into account.
Issue #6583656 When you call end() after calling reverse() on an animation that has not started leads to forward animation finishing.
Change-Id: Ifca60a32d4973c21b85aed9c459f802526c0207e
