History log of /frameworks/base/tools/orientationplot/orientationplot.py
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
e97c9a244b71b6376003c377b56f7a86bcd0049f 11-Jun-2015 Jeff Brown <jeffbrown@google.com> Configure auto-rotation tilt tolerance in config.xml.

This allows for the thresholds to be tuned differently for different
products as needed.

Bug: 18276856
Change-Id: I6c87e683dea6a17cf606203a894c8419e20d3658
282e181b58cf72b6ca770dc7ca5f91f135444502 24-Jan-2014 Adam Lesinski <adamlesinski@google.com> Revert "Move frameworks/base/tools/ to frameworks/tools/"

This reverts commit 9f6a119c8aa276432ece4fe2118bd8a3c9b1067e.
9f6a119c8aa276432ece4fe2118bd8a3c9b1067e 28-Aug-2013 Mike Lockwood <lockwood@google.com> Move frameworks/base/tools/ to frameworks/tools/

Change-Id: I3ffafdab27cc4aca256c3a5806b630795b75d5c8
daf5d894ef71c5674e83b11de8b408e3bdabe4c7 08-May-2012 Jeff Brown <jeffbrown@google.com> Small tweaks to orientation.

Improved threshold for detecting external acceleration.

Bug: 5976859
Change-Id: Iaf2298fba8eda72d1cacbb2f3aea72f460a9262f
5aa73ae58f049379a97bc86add541f27170c02a4 14-Jan-2012 Jeff Brown <jeffbrown@google.com> Improve heuristics for orientation detection.

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
c0347aa19f354a8e1ff4fcd5372b134c0c7c16ad 24-Sep-2011 Jeff Brown <jeffbrown@google.com> Prevent unintended rotations.
Bug: 4981385

Changed the orientation listener to notify the policy whenever
its proposed orientation changes, and changes the window manager
to notify the orientation listener when the actual orientation
changes. This allows us to better handle the case where the
policy has rejected a given proposal at one time (because the
current application forced orientation) but might choose
to accept the same proposal at another time.

It's important that the proposal always be up to date. A proposal
becomes irrelevant as soon as the phone posture changes such
that we can no longer determine the orientation with confidence
(such as when a device is placed flat on a table).

Simplified the orientation filtering. Now we just wait 200ms
for the device to be still before issuing a proposal. The idea
is that if the device is moving around a lot, we assume that
the device is being picked up or put down or otherwise in
the process of being moved. We don't want to change the rotation
until that's all settled down. However, we do want to tolerate
a certain amount of environmental noise.

(The previous confidence algorithm was also designed along
these lines but it was less direct about waiting for things
to settle. Instead it simply made orientation changes take
longer than usual while unsettled, but the extra delay was often
too much or too little. This one should be easier to tune.)

Change-Id: I09e6befea1f0994b6b15d424f3182859c0d9a530
4519f07e9c6b993fbe7a3d3df24d71d9450a54f1 23-Jan-2011 Jeff Brown <jeffbrown@google.com> New orientation listener.

The objective in this listener is to be more careful about the
signal processing to prevent spurious orientation changes
and to make all of the tweakable factors physically meaningful.

The calibration is defined in terms of time constants and
does not assume a particular discrete sampling rate. This is
useful because it allows us to change the accelerometer sampling
interval if desired without having to change the calibration.
Moreover, the accelerometer sampling interval can vary +/- 20ms
from one sample to the next even in normal circumstances.

Proposed orientation changes are weighted by confidence factors
that vary exponentially in relation to how close the device
is to the ideal orientation change posture (screen is vertical,
angle is exactly at the midpoint of the orientation quadrant,
and no external acceleration beside gravity). When not in an ideal
posture, the device takes proportionally longer to settle into a
new orientation state.

Added a little tool to plot the log output of the
WindowOrientationListener. Check the README for more information
about how to use it.

Change-Id: I787f02d03582ff26367df65eda8d9ce85c5cb343