An earlier fix nooop'd invalidate calls on non-visible views. This
caused an issue where changes to the view while it was not visible
(such as changing the text of a TextView) would not get picked up
by the invalidation process.
The fix is to automatically invalidate() a view when it becomes
visible, to account for any changes that may have occurred to its
content while it was not visible.
Change-Id: Ia0f8fb42ca627b5a38f08761fa622b23f2dfa38b
It looks like this is caused by the change in HC to stop activities when
the screen is off. ViewRootImpl (a.k.a. ViewRoot) has special code to
avoid doing work when it is stopped, and it is now stopped when the screen
is off. The problem here is if the window's activity is stopped when the
window is first displayed, then it would never do the initial fitSystemWindows()
with the status bar offsets given by the window manager, and never do this
again until the status bar changes.
Also included here is some re-arranging of the code dealing with the offsets
changing, because it was dealt with in two places and only one had a bunch of
code dealing with HW accelerated drawing and performing the fade transition
between states. Now all of that is unified into one place.
Change-Id: I9828f02664cc622dbf186effb1f685a8aa4456a1
The content retrieval APIs are synchronous from a client's
perspective but internally they are asynchronous. The client thread
calls into the system requesting an action and providing a callback
to receive the result after which it waits up to a timeout for that
result. The system enforces security and then delegates the request
to a given view hierarchy where a message is posted (from a binder
thread) describing what to be performed by the main UI thread the
result of which it delivered via the mentioned callback. However,
the blocked client thread and the main UI thread of the target view
hierarchy can be the same one, for example an accessibility service
and an activity run in the same process, thus they are executed on the
same main thread. In such a case the retrieval will fail since the UI
thread that has to process the message describing the work to be done
is blocked waiting for a result is has to compute! To avoid this scenario
when making a call the client also passes its process and thread ids so
the accessed view hierarchy can detect if the client making the request
is running in its main UI thread. In such a case the view hierarchy,
specifically the binder thread performing the IPC to it, does not post a
message to be run on the UI thread but passes it to the singleton
interaction client through which all interactions occur and the latter is
responsible to execute the message before starting to wait for the
asynchronous result delivered via the callback. In this case the expected
result is already received so no waiting is performed.
bug:5138933
Change-Id: I382e2d8689f5189110226613c2387f553df98bd3
...(when turning display on after recently turning it off)
Also clean up when we decide to turn the screen on to improve that
transition. There are still problems here with turning it on
before the wallpaper gets dispayed.
Change-Id: I2bc56c12e5ad75a1ce5a0546f43a845bf0823e66
New UX interactions (the Paste action is no longer displayed after a delay)
suggestionEnabled flag replaced by existing input type flag.
removeSpans fixed in SpannableStringBuilder to always send notifications
SuggestionSpan handled by TextView instead of SpannableStringBuilder
New span update algorithm to correctly handle edition around word boundaries.
Change-Id: I52c01172f19e595fa512e285a565a3fd97c3c50e
There was a bug in the invalidation code that prevented some
animations fropm starting. An INVISIBLE view would mark some dirty
flags then propagate the invaliation up the parent hierarchy. This would
cause a redraw of the hierarchy, but would not include the invisible
view (invisible children do not get drawn). Thus the flags wouldn't get cleared.
Later, an animation to fade the view in (making it VISIBLE on start) would
be started on the view. But the invalidation triggered by that animation would
not propagate because the invisible view would see that it was already
invalidated, and wouldn't send the message along. No invalidation means no drawing,
so the animation wouldn't start because the invalidation didn't make it's way up to the
top and the child's parent did not redraw.
The fix is to noop the invalidate() call for GONE/INVISIBLE views which do not
have animations set on them. Making these views VISIBLE later will trigger
an invalidation, as will starting an animation on them, so the behavior should
not change except for the buggy situation.
Change-Id: I7a26a4bc7823f08fef56e52648e77ca256df6858
This introduces a new facility for code during the boot process
to display messages to the user through a progress dialog. This
is only for use when performing longer-than-usual post-upgrade
operations such as running dexopt on applications or upgrading
databases.
Change-Id: I0e78439ccec3850fb67872c22f235bf12a158dae
- Sometimes, the applyUpdate was applied through draw() and the
underlying matrix was not updated in time, causing "jitter". Add a
matrix update call in draw().
- Switch to invalidateParentIfNeeded() in setTransform().
Change-Id: I1cf9cdfe78f9d989821cdc9600984fc826430211
Bug: 5049148
Finished stylus support, including support for indirect stylus
and mouse tools.
Added TILT axis. When stylus tilt X/Y is available, it is transformed
into an orientation and tilt inclination which is a more convenient
representation and a simpler extension to the exiting API.
Touch devices now only report touch data using a single input
source. Previously touch devices in pointer mode would report
both absolute touch pad data and cooked pointer gestures.
Now we just pick one. The touch device switches modes as needed
when the focused application enables/disables pointer gestures.
This change greatly simplifies the code and reduces the load
on the input dispatcher.
Fixed an incorrect assumption that the value of ABS_(MT_)DISTANCE
would be zero whenever the stylus was in direct contact. It appears
that the correct way to determine whether the stylus is in direct
contact (rather than hovering) is by checking for a non-zero
reported pressure.
Added code to read the initial state of tool buttons and axis values
when the input devices are initialized or reset. This fixes
problems where the input mapper state might have the wrong initial
state.
Moved responsibility for cancelling pending inputs (keys down,
touches, etc.) to the InputDispatcher by sending it a device reset
notification. This frees the InputReader from having to synthesize
events during reset, which was cumbersome and somewhat brittle
to begin with.
Consolidated more of the common accumulator logic from
SingleTouchInputMapper and MultiTouchInputMapper into
TouchInputMapper.
Improved the PointerLocation output.
Change-Id: I595d3647f7fd7cb1e3eff8b3c76b85043b5fe2f0
- use the real TextDirectionHeuristics constants
- make more formal that LayoutDirection should be resolved BEFORE TextDirection
- reset TextDirection if LayoutDirection is recomputed
- remove non used TextDirectionHeuristic.isRtl(CharSequence...)
Change-Id: I1d53a7e3ee324cfd27785bb4d715d93de8d9ff4d
This will save apps the trouble of having to first remove
the lights-out or hide-navigation flags before reapplying
them (in situations where the system UI has decided to
override those flags).
Bug: 5052456
Change-Id: I31f6ca9105379ae5f0216ebe3c39fc8d5d935f92
Bug: 5165543
This change fixes some problems when the view hierarchy contains
duplicate ids, such as when ListViews contain nested custom views.
If the custom views contain next focused id hints, then the system
should prefer the other views within the ListView item over any
other views outside of the ListView item.
Change-Id: I5653ff6bac0bf9f08bd6ecbe5a3bb22ea47ab566
SeekBar widgets were not good citizens when placed in scrolling containers.
Detect when a SeekBar being touched is in a scrolling container and fall
back to a touch slop-based method for beginning a drag. Taps along the
seek bar itself will still change the value on touch up, even if the touch
slop never initiated a proper drag.
Factor out the code used to determine scrolling container status in View
into something that can be reused elsewhere in the framework; leave it
@hidden for now.
Change-Id: I59a21e8ab2c3b0092fafedbcd6ae1ee15f45971c
