NativeActivity created a pipe to wake up a Looper it's attached to, but
it failed to set the right options for the read part of the pipe. This
affects only the NativeActivity API call for AInputQueue_hasEvents
Change-Id: I02e5dad4e700f4c724b3187a4b7e0df931dd1eed
Bug 3416154
The origin of the problem is new display optimisations that enable
a scrollView to be scrolled without calling the onDraw method of its
children. As a result, the handles' positions were not updated on scroll.
DropDown popup menu have an integrated scroll listener that will fix the
problem. Using these indead is the first part of the solution.
The next problem is that when they get hidden, these popups try to move their
parent (the TextView in our case) which creates a scroll conflict. Fixed by
overriding findDropDownPosition.
Finally, when the handles get invisible, a new scroll listener has to be
installed that will show them back in case the view is scrolled back.
This is also an important step to fix Bug 3441308 (selectable text in list
views).
Debugging find outs:
Small optimization in PopupWindow to avoir unregistering then registering
back the listener when it is updated.
getHandle().show(); is not needed since updatePosition will do it through
moveTo().
Change-Id: I6bf6a3649538328257734ed1e651b23b889d65d9
Only initiate fallback key handling if the first key down was
not handled and there is no other fallback key already in progress.
This prevents spurious fallbacks from being generated when
applications handle the initial down but not repeated downs or the up.
Change-Id: I8a513896cf96b16dc502cd72291926d5532aa2ab
related-to-bug: 3474610
Change-Id: I6dab40e8b465922c62be9ee7f168718822c6caac
Now skipping extra header that the spec claimed shouldn't be present in LATM...
E.g. if an app is sensorLandscape and the device rotation is
locked to landscape, the activity should not be allowed to
flip to seascape even if the device is inverted.
If the rotation is locked 90° from the activity's
supported orientations, we must override the lock as before,
but we now suppress the sensor input (confining the activity
to one of its two orientations). This best preserves the
spirit of the rotation lock while still allowing the
activity to run in a supported configuration.
Bug: 3453407
Change-Id: I8ee255e0250ba7e4534f4622ac37b82d31cf9936
We were setting ACCELEROMETER_ROTATION to 0 before putting
in the proper USER_ROTATION value, and PhoneWindowManager's
content observer would eagerly rotate the screen to the last
locked orientation before re-rotating to the updated locked
rotation.
Now we set USER_ROTATION first. Additionally, the
content observer is now the only place we set
mUserRotation{,Mode} (previously we would race with it in
setUserRotationMode()).
Bug: 3425657
Change-Id: I04ba1a3631c6d985c2e406c4d148c39fb5c36216
