Alt-TAB should have different semantics from the APP_SWITCH key
or long-press on HOME. Accordingly, remove the fallback action
for Alt-TAB and initiate the task switching behavior directly
in the policy.
Modified RecentApplicationsDialog to be more precise about the
initial modifiers that it considers to be holding the dialog.
The dialog is now dismissed by a second press on the APP_SWITCH
key or by a second long press on HOME.
Change-Id: I07e72dc4e1f3cd8edaf357c1d49e79f60d6d1604
Also fix not writing the settings file when an admin is removed.
And take care of an old to-do about not removing an admin until
after it has received the broadcast about it being disabled.
Change-Id: I4ebe0ea0461222b65425b2c5438b646b572f18c8
We now correctly adjust display metrics, fixing for example issues
seen in Barcode Scanner. In addition the decision about when to use
compatibility mode has a bug fixed where certain apps would not go
out of compatibility mode even though they should be able to.
Change-Id: I5971206323df0f11ce653d1c790c700f457f0582
If webkit wasn't in a drawing mood, post a WEBKIT_DRAW event to
assure that the update is not lost.
bug: 4474358
Change-Id: Ib0c4cedb10f58821f95c439824c30043a906f8b8
Also be more careful about canceling fallback keys during focus
transitions, when the application handles the key, or when the
policy decides to do something different.
Fixed a crash due to JNI CallObjectMethod returning an undefined
value (not null) when an exception is thrown.
Fixed a crash due to the policy trying to create a Dialog for
recent apps on the dispatcher thread. It should happen on the
policy's Looper instead.
Bug: 4187302
Change-Id: I043f82913830f411b3bb4018d6422467b6ca454f
Fix a bug where we were always setting the focused application
handle to NULL. This broke ANR processing while starting
applications and caused input events to be dropped while
starting applications.
Bug: 4174573
Change-Id: Ice7ce3a2b65219568a8227fc1383bafb294666b5
When 10 fingers are down, reduces the CPU time spent by the InputReader
thread from ~30% to ~5% on Stingray.
Change-Id: I42ee5c67b8521af715cbab43e763a4af4eb1f914
4 hours is excessive, and we want to save bandwidth on the NTP servers
Change-Id: Ic5ac4f4a8e62167206f3f620ea51635a2ea771d6
Signed-off-by: Mike Lockwood <lockwood@android.com>
Added a timeout mechanism to EventHub and InputReader so that
InputMappers can request timeouts to perform delayed processing of
input when needed.
Change-Id: I89c1171c9326c6e413042e3ee13aa9f7f1fc0454
Replaced VelocityTracker with a faster and more accurate
native implementation. This avoids the duplicate maintenance
overhead of having two implementations.
The new algorithm requires that the sample duration be at least
10ms in order to contribute to the velocity calculation. This
ensures that the velocity is not severely overestimated when
samples arrive in bursts.
The new algorithm computes the exponentially weighted moving
average using weights based on the relative duration of successive
sample periods.
The new algorithm is also more careful about how it handles
individual pointers going down or up and their effects on the
collected movement traces. The intent is to preserve the last
known velocity of pointers as they go up while also ensuring
that other motion samples do not count twice in that case.
Bug: 4086785
Change-Id: I95054102397c4b6a9076dc6a0fc841b4beec7920
1. Single finger tap performs a click.
2. Single finger movement moves the pointer (hovers).
3. Button press plus movement performs click or drag.
While dragging, the pointer follows the finger that is moving
fastest. This is important if there are additional fingers
down on the touch pad for the purpose of applying force
to an integrated button underneath.
4. Two fingers near each other moving in the same direction
are coalesced as a swipe gesture under the pointer.
5. Two or more fingers moving in arbitrary directions are
transformed into touches in the vicinity of the pointer.
This makes scale/zoom and rotate gestures possible.
Added a native VelocityTracker implementation to enable intelligent
switching of the active pointer during drags.
Change-Id: I7b7ddacc724fb1306e1590dbaebb740d3130d7cd
Breadcrumbs move to the action bar on certain configs.
Padding around fragments and to the left of preference items
adjusted for different display sizes.
Change-Id: Ie899f9742f4ebd7044f158b1c7db06df82ad2d75
When the version is reported as a codename, use the previous version
in the user agent string.
Bug: 4347787
Change-Id: I4ed804a7334d6ca242446176ff042c4ac7938a0f
The current browser pause/resume logic uses an integer count to track
the pause/resume behavior, which is mostly working fine in phone. The interger
count is usually 0 when browser is paused, and its value is usually 1
when the browser is resumed and will trigger any delayed timer.
But in tablet, where tabs can be easily created/switched/deleted, this
logic will not work well and sometimes cause resources timers get stuck.
For example, in case multiple tabs are created, and you reload one of the
tabs, when it's almost finished, switch to another tab, and hit home or power
button, at this point of time, the browser will be suspended at
Controller.java::onPause, hence the integer count will be 0; but since
the other tab is also finished after the pause, the current logic at
Controller.java::onPageFinished will call pause timer again, which will make
the integer count to be -1. Before the time the browser is resumed, it's very
possible some tabs will have some resources, such as images/flashs,
scheduled to be loaded, these will be in delayed timer in
ResourceLoadScheduler.cpp's m_requestTimer.
Now when the browser is resumed, the integer count will be 0, which will not
trigger delayed timer. Then all the new timers will be stuck as well since
old timers are not executed yet.
The fix is to simplify the pause/resume logic by just using a boolean variable
instead of error-prone integer counting.
issue: 4177932
Change-Id: Id10af9298c7be1f82222d0b94c34c5dc68403630
