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
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
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
TextView uses a sub-display list to 'cache' the rendering of its
text. This saves time when drawing an editable text, where the blinking
cursor forces a re-draw twice per second, which creates pauses during
scrolling.
Added a sub-display list invalidation when an appearance span is
modified/added/removed.
Also added an invalidation of the display list when selection range
is changed.
Change-Id: I41e8068a12902b8a745c5bb77de8c77def76a270
Don't consider a window as a candidate for the top fullscreen window
if it is not going to be a candiate for layout.
Also don't consider windows a candidate for layout if their app token
is hidden. This fixes a transient state where we are preparing to
unhide the window but have not done so yet.
Change-Id: Ife5299ffa003c1df1a4f787b7a2809cbf614ec16
The previous logic in AnimationSet when starting an animation
ignored the fillBefore behavior of its child animations. This caused
a bug where a delayed AlphaAnimation would automatically cause the
target view to become transparent, even though it was supposed to wait
until after some delay to do so.
The fix checks the fillBefore behavior of each child animation before
concatenating its transform with the transform of the AnimationSet.
Change-Id: I76a2dafbe6dd338dc5281b17612eae87af168d86
Currently, you must call initialize() on RotateAnimation or
ScaleAnimation prior to calling start(). The reason is that the
actual pivot point used in calculating the transform is not set
until that method is called. This makes sense in the typical case
where the animation is running on a View and is using values relative
to the size of the View or of its parent. But if the caller sets the
values to be ABSOLUTE types instead, the sizes of the view and the parent
are irrelevant and the call to initialize() should not be needed (and
is not intuitive).
This fix automatically sets the internal pivot values in the case where
the value types are ABSOLUTE.
Change-Id: I74a0e462486efae08aa76e72c0d19d82f2a2677e
The various Properties added to View in 4.0 (ALPHA, TRANSLATION_X, etc.)
were not final, making it possible to assign on property to another.
Not something that someone would want to do, but we should try to prevent
that kind of mess. This API change makes those properties final.
Change-Id: I7d0c7f738eb2074d0781b1ba6a7c19339bac4477
...rotating to landscape
When doing spell checking in the same process as the spell checker, we
need to make sure it is still done asynchronously.
Putting this in I noticed quite a few threading issues in this code, so
I also addressed those (which became very obviously a problem with the
async stuff here now).
Also tweaked the service side to run spell checking at background priority.
Change-Id: I01bafe3bec6bceeca911d6bf2f61a486a2fd4c48
We need to work more like before in determining whether the menu
key is needed -- in some cases look back in the window list to
determine this if we don't know the value from the current window.
This requires adding a new private flag indicating whether the
compat menu state is known for a window, which is set by
PhoneWindow as part of its existing process of computing the flag
for its own windows.
Now we can have a new API on WindowState to determine the value
of this flag for a window, which if needed walks back in the window list
to find a window the value is known for (or stops at what the policy
has determined is the top full-screen window, so we stop like we used
to at things like the lock screen or the bottom of an application).
Change-Id: I829de6d629b5af8bcb422cb85249ee4041c7205e
