Plug a couple of apparent code paths (one not obviously reachable, but
fixed here on general principles) that could lead to a backup pass
getting confused partway through and simply never properly completing.
In this state it would leave its wakelock held forever until next
reboot. Bug 5828859.
Those fixes are a total of two lines of code. The rest of the patch
adds a textual journal of the most recently completed (or ongoing!)
backup pass's progress, with an eye to being able to isolate any such
issues that may crop up in the future.
Change-Id: If8a5e8aba11db5a1e618d8b9c9ba3038dd5377a1
Bug 5806267
Use visual selection to determine the webkit selection.
The webkit selection can be used to cut text from an editable
area. It can also be used to do better complex character text
copy.
Webkit change: I194c6d9e2add67151b97092a1a54f5c081296000
Change-Id: I56543d17670a8c98484314c89c7fa6a94cb809e4
Similar to what is done in GestureDetector
Removed all gesture constants. Only one one them is used on MOVE
(added an early exit test), the 2 others on UP or DOWN where
performance is not such an issue.
Change-Id: Icd58ead5078f94f86786f934ddf81aa5ec9bf549
Adds the new interface to the user dictionary, which includes
a clean way of inserting words in any locale and support for
shortcuts.
Change Ib318c047 implements the provider part of this.
Bug: 4646172
Change-Id: Id3ca792f2555fac46728f9d404ab0199971f6503
This fixes a bug where the device fails to lock when DevicePolicyManagerService
requests the device to be locked and the screen was off because the user hit
the power button.
The change allows DPMS to directly invoke screen lock, bypasssing the screen state.
Change-Id: Iecdda6fc61e9c519119de495be23c69c3b983921
1. Except as otherwise indicated, orientation change happens once
the predicted rotation has been stable for 40ms. Noise is
suppressed by a low-pass filter with a 200ms time constant which
seems to be about as small as is practical given the quality
of the sensor data.
2. If the magnitude exceeds a threshold (excessive noise or freefall),
resets the predicted orientation.
Doesn't happen very often even when shaking the device.
This heuristic mainly protects the detector from spurious tilt due
to inaccurate determination of the gravity vector.
3. If the device was previously in a flat posture (on a table for at
least 1000ms), then it must move out of that posture for at least
500ms before the next orientation change will happen.
This heuristic suppresses most spurious rotations that happen while
picking up the device.
4. If the device is tilted away from the user by 20 degrees within
a span of 300ms, the device is said to be swinging and at least
300ms must elapse after the device stops swinging before the
next orientation change will happen.
This heuristic suppresses some but not all spurious rotations that
happen while putting down a device. Unfortunately, this heuristic
sometimes triggers a false positive when turning the device very
rapidly due to accelerometer noise. The 300ms pause is a compromise
so that occasional mispredicted swings don't significantly delay
the rotation.
Bug: 5796249
Change-Id: Id7b36c4c563e35b70d6a7ac36d04f3c3d6ea5811
Use the AUDIO_STREAM_* constants defined in <system/audio.h> instead of
dynamically looking up stream types from AudioManager.
Replace a series of "if" statements by a switch.
Change-Id: I6d015bc151c9ab97a02492e84c63298b1f6f31ac
When javascript request exit full screen, WebViewCore need to handle the
message from webkit thread and hide the custom view.
Webkit part:
https://android-git.corp.google.com/g/#/c/158652/
Change-Id: I9edbb5a4059f330fb29df116ae076ec52f81a1af
-> This prevents collection widgets from flashing loading
views when they are updated with new content
Change-Id: I1241ff9a09edfd990ad03f76449d18b9359246b4
Improve volume management by keeping track of volume for each type
of device independently.
Volume for each stream (MUSIC, RINGTONE, VOICE_CALL...) is now maintained
per device.
The main changes are:
- AudioService now keeps tracks of stream volumes per device:
volume indexes are kept in a HashMap < device , index>.
active device is queried from policy manager when a volume change request
is received
initalization, mute and unmute happen on all device simultaneously
- Settings: suffixes is added to volume keys to store each device
volume independently.
- AudioSystem/AudioPolicyService/AudioPolicyInterface: added a device argument
to setStreamVolumeIndex() and getStreamVolumeIndex() to address each
device independently.
- AudioPolicyManagerBase: keep track of stream volumes for each device
and apply volume according to current device selection.
Change-Id: I61ef1c45caadca04d16363bca4140e0f81901b3f
AccessibilityEvent and AccessibilityNodeInfo have a property className which is set to the source
Java class. This is problematic since leads to leaking private classes which would allow an
accessibility service to load classes from other packages. This is strongly undesirable since
not trusted code can be loaded, and hence executed, in the accessibility service. To address
that the class name is set to the most concrete framework class extended by the info/event
source.
bug:5878943
Change-Id: I7b3114ece8772ea2773f5151e21b8a6f2006882a
incorrectly specified.
This affected search bars and alert dialogs spawned from activities
using Theme.DeviceDefault.Light as a base.
Change-Id: I219d38d486498db5b4b283560256afd7d6051535
Remove UnsupportedOperationException
Add primitive support for clipPath/clipRegion
Add support for quickReject(Path, EdgeType)
Change-Id: Ie7a80df7f380f488710bac31103772a9eab21612
This is a fix for http://code.google.com/p/android/issues/detail?id=17508
Adding some logs and a forced GC, I'm now reliably able to reproduce it. Here is the scenario.
1. The IME handles an event. It retrieves the current InputConnection (IC) using
ic = getCurrentInputConnection() and calls ic.beginBatchEdit();
2. The call is propagated to the UI thread and TextView's mBatchEditNesting
is correctly increased through beginBatchEdit()
3. A listener calls setText(), which imm.restartInput(this);
4. As a result, the InputMethodManager creates a new ControlledInputConnectionWrapper
with a new InputConnection from the TextView
5. A GC happens at that point. The previous InputConnection is no longeri
referenced by the InputMethodManager's mServedInputConnection.
The weak reference in the previous ControlledInputConnectionWrapper is nulled.
6. The IME thread finishes its process and calls ic.endBatchEdit(); on its version
of the original InputConnection.
7. The message is passed through the InputConnect, but when the weak reference in the
original IInputConnectionWrapper is dereferenced, we get a null InputConnection in
executeMessage().
8. As a result, the TextView's endBatchEdit() method is not called, leaving this TextView
with a non zero mBatchEditNesting.
9. From now on, all edit actions on this TextView will be considered part of a nested edition
and no invalidation is performed, which is the visible manifestation of this bug.
The core problem is that the begin/end batch edit contract is broken when:
1. These are initiated by the IME thread (as opposed to the UI thread)
2. The input connection is reset between these calls
3. A GC happens in the mean time and the WeakReference is lost (otherwise
calling endBatchEdit on a no longer active InputConnection is fine
Solution to keep TextView's mBatchEditNesting balanced:
- The IMM should notify the IC when it is no longer used. We're using the
existing FINISH_INPUT_CONNECTION to do that.
- The InputConnection should keep track of its nesting contribution to the TextView.
When finished the IC makes sure its contribution is reset to 0.
Moreover, further asynchonous calls to begin/endBatchEdit that may arrive from the IME
should be ignored. This is achieved using a negative value as a flag.
Notes:
- finishComposingText may be too broad of a method to perform such a cleaning step
but is seems to only be called in cases where the IC will not be used anymore.
If that's too broad, we have to introduce a new method in the IC interface.
- This is has been implemented in EditableInputConnection and not in a more general
BaseInputConnection because this is where we have a notion of TextEdit, and the
nesting problem is here specific to TextView.
However, the same unbalanced begin/end problem will happen in these classes. They
should override finishComposingText as has been done here if that matters.
- We cannot re-use the TextView's mBatchEditNesting since it may take into account
batch edit from various sources and resetting it on InputConnection close could
then lead to an inconsistent negative count value.
Patch Set 2: added synchronized blocks around mBatchEditNesting
Change-Id: I1ec5518fdc16fb0551fbce9d13f5d92eb4bc78c0
- compute total advances correctly by iterating on the advances array for up to mShaperItem.num_glyphs
- update unit tests
Change-Id: I00af68bef88702215e9222ed80dbffcc81df51a7
