Launcher swiping looks choppy. It's because we deliver the
motion events of the drags asynchronously, and sometimes we
may get an event to redraw before the motion event is posted, so we
end up drawing again without updating to the latest motion
information.
This fix makes input event processing more proactive. Every time
we run ViewRootImpl.performTraversals() (which is what
happens whenever we need to layout, measure, and/or draw), we
first process all pending input events, ensuring that we are
completely up-to-date with posted events prior to drawing, so that the
drawing we do is synchronous with the events we've received.
This eliminates the choppiness and means that we can now get the full
refresh rate on the screen with drag events.
The fix was done for Launcher, but it is pervasive in the system,
so this may fix other laggy drag behavior as well.
Change-Id: I8dbed6acadc2662f317f736e769f536f555701aa
Also use the AlarmManager instead of messages so the delays
are consistent whether sleeping or not.
Bug: 5534004
Change-Id: I24118b30214dddf8183c1200a89555d6c528e606
Causes problems on our wext driver and potentially on cfg
based driver as well.
NLP can trigger very quick acquire and release within seconds
leading to driver switching between start and stop state.
We now keep driver up for atleast couple of minutes after a start
Bug: 5478196
Change-Id: I1b261578252c5fb9a65446241b51e5686d4d9cc3
Fixes bug 5544556: All email content is wrapped prematurely.
Previous change (I5a22dd20) didn't take a few other cases of
mViewScale>0 into account.
Change-Id: I4f9578f3558f026c472492ac07d19004416dc228
Setting persist.sys.strictmode.disable to 'true' will disable strict
mode on eng/userdebug builds where it is turned on by default.
Explicitly enabling it in the Settings UI will override this, so
it's still possible to toggle it there even when this property
has been set on the device.
Change-Id: Ifd971f948fb2f803d509c2a06112c4bb932a5b1f
Before calling NewStringUTF, check that the metadata value is actually
valid utf-8, and replace the offending characters with "?" if it is not.
b/5534491
Change-Id: I43de4307e739ae0b7d4177937ed33aa1dfb90d98
The addition of low power audio playback mode made that audio buffer consumption
by audio HAL can now happen in bursts. This makes that requesting audio data
from an AudioTrack for mixing can happen at much shorter intervals than before.
This revealed an existing problem where AudioFlinger would consider a track ready
for mixing although not enough frames were ready to completely fill one output buffer,
thus creating short periods of silence.
The fix consists in waiting for enough frames to be ready in AudioTrack buffer before
declaring a track ready for mixing. This minimum is not applied when the track is stopped
to allow the buffer to be emptied completely.
Change-Id: I6d04f9b65db5af85b0b53f0a5674be7ec02f9e9f
- ActivityManager now keeps track of previous app as you
move across the home app.
- Better debug info about why an activity is being destroyed.
- New performance tests.
Change-Id: I3a5ae7cb1b9f1624c6792a4f6184353f532b8f3b
