When IME is being moved as part of a window going away, it could flicker
as it immediately moves behind the window. Fix this.
Also make the default soft input mode for PopupWindow to be to not change
the IME visibility, since it is a rare pop-up window that should cause your
IME to close.
Change-Id: I0b43e080ad012739e9a3e5842794c778c859ac1a
Some parts stubbed out but you can plug in a mouse and move
a green cursor around to interact with the UI.
Change-Id: I80d597a7f11d3bd92041890f74b3c77326975e6e
* commit '672ebb61a755e4bbe60e4e884b1adadf186733b6':
Improved ignore-backoff handling Allow a non-epidited ignore-backoff op to pass through an expidited backed off op.
The previous change only hid the fragment when the transition animation
ended. But if there is no animation, the fragment would never be hidden.
This change adds an else clause that handles the non-animating case.
Change-Id: Ie35b2ae98cb5c21193dadefbef71b8542fcf5f7d
...android.app.Fragment.startActivityForResult(Fragment.java)
Make sure to remove all pending messages when AbsListView is detached
from its window.
But... that's not enough.
It turns out that when a fragment's views are animating away, they of
course don't get detached until after the animation is done. However
the fragment itself is immediately destroyed, leaving its live views
still going after that.
Here's a possible solution: when fragment manager initiates an animation
on a fragment whose views are being removed, it makes note of that so
it can hold off on destroying the fragment until the animation is over.
There are a lot of interesting race conditions here, if further operations
happen on the fragment while it is being animated. I think the code here
does something sensible, and it does seem to work for the situations I
have tested, but it is hard to know all of the edge cases that may happen.
Change-Id: I4490ce8862a9bb714c7ea54baca3072c62126388
Allow the hosting application to do what they want if the
control key is pressed. In particular, let our Browser
map Ctrl-arrow to back and forward.
bug:3270434
Change-Id: I2dfa648edbf5a0e48b674df5023182b4a70985f6
Treat the numeric keypad enter as the regular enter for the
purposes of completing a text entry or activating the currently
selected link.
Add a little keyboard-related debugging.
Don't call select text to extend the selection if the tap
point hasn't moved.
A separate change to the Browser app adds more keyboard
accelerators.
bug:3270434
bug:3191699
Change-Id: I8a38b26196e93e344dc2a4b39a6968fe0c158d47
These can be included as desired by particular devices to configure
their Dalvik heap in a standard way.
Change-Id: I487c751d7c583b0e93552f16ab43a93314219778
This complements the secure rfcomm API.
The link key is unauthenticated and is subject to MITM attacks.
The link key may be encrypted depending on the type of Bluetooth device.
This helps apps which don't need the extra security or
have their own security layer built on top of the rfcomm link.
Change-Id: I71b2fa8de469ef98faa204b4dafac18a8e21d0d9
Context from an Activity are not meant to be store past the
lifetime of the Activity.
Fix for bug 3306898
Change-Id: Ib2f12cbdc3ec8aa0a6adf4770e6be4569fa6402c
Rewrote interceptKeyBeforeQueueing to make the handling more systematic.
Behavior should be identical except:
- We never pass keys to applications when the screen is off and the keyguard
is not showing (the proximity sensor turned off the screen).
Previously we passed all non-wake keys through in this case which
caused a bug on Crespo where the screen would come back on if a soft key
was held at the time of power off because the resulting key up event
would sneak in just before the keyguard was shown. It would then be
passed through to the dispatcher which would poke user activity and
wake up the screen.
- We propagate the key flags when broadcasting media keys which
ensures that recipients can tell when the key is canceled.
- We ignore endcall or power if canceled (shouldn't happen anyways).
Changed the input dispatcher to not poke user activity for canceled
events since they are synthetic and should not wake the device.
Changed the lock screen so that it does not poke the wake lock when the
grab handle is released. This fixes a bug where the screen would come
back on immediately if the power went off while the user was holding
one of the grab handles because the sliding tab would receive an up
event after screen turned off and release the grab handles.
Bug: 3144874
Change-Id: Iebb91e10592b4ef2de4b1dd3a2e1e4254aacb697
Allow a non-epidited ignore-backoff op to pass through
an expidited backed off op.
To do this, I first refactored the complicated if statement:
if (best == null
|| ((bestSyncableIsUnknownAndNotARetry == syncableIsUnknownAndNotARetry)
? (best.expedited == op.expedited
? opRunTime < bestRunTime
: op.expedited)
: syncableIsUnknownAndNotARetry)) {
best = op;
bestSyncableIsUnknownAndNotARetry = syncableIsUnknownAndNotARetry;
bestRunTime = opRunTime;
}
Into a more readable:
boolean setBest = false;
if (best == null) {
setBest = true;
} else if (bestSyncableIsUnknownAndNotARetry == syncableIsUnknownAndNotARetry) {
if (best.expedited == op.expedited) {
if (opRunTime < bestRunTime) {
// if both have same level, earlier time wins
setBest = true;
}
} else {
if (op.expedited) {
setBest = true;
}
}
} else {
if (syncableIsUnknownAndNotARetry) {
setBest = true;
}
}
if (setBest) {
best = op;
bestSyncableIsUnknownAndNotARetry = syncableIsUnknownAndNotARetry;
bestRunTime = opRunTime;
}
The refactoring was all done automatically with IntelliJ to avoid human error
in the conversion.
After verifying this code still behaved as expected including the error
condition in the bug, I added handling for the cases when a non-expidited op
may override an expedited op if certain conditions occur, specificaly, if the
expidited op is backed off and the non-expidited op is not.
Finally, refactored to make it testable and added tests and logging.
Bug: 3128963
Change-Id: I131cbcec6073ea5fe425f6b5aa88ca56c02b6598
Prior to this change, saveInstanceState would
call directly to Activity.onSaveInstanceState(),
rather than performSaveInstanceState().
This meant that saveManagdDialogs() was not called,
so Activities running under a LocalActivityManager
do not get their dialogs restored on configuration changes.
Change-Id: Id45110a8716a86958c14f4b1ea5a84c9cdf107f1
