[Nexus 7 General] eMPee584:
the source is with us..always. (attempt to document android orientation detection)

not my device but when investigating this same issue.. dug deep and figured it out. So0Oo..

The code in question resides in frameworks/base/core/java/android/view/WindowOrientationListener.java..

last change explains the current (Jelly Bean/Android 4.1+) algorithm very well:

commit 5aa73ae58f049379a97bc86add541f27170c02a4
Author: Jeff Brown <jeffbrown@google.com>
Date: [B]Fri Jan 13 15:29:21 2012 -0800[/B]
Improve heuristics for orientation detection.

1. Except as otherwise indicated, orientation change happens once
the predicted rotation has been stable for [B][U]40ms[/U][/B]. 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
[B][U]500ms[/U][/B] 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.

===========================================

The code in effect for Ice Cream Sandwich/Android 4.0 was somewhat simpler:

commit c0347aa19f354a8e1ff4fcd5372b134c0c7c16ad
Author: Jeff Brown <jeffbrown@google.com>
Date: Fri Sep 23 17:26:09 2011 -0700
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 [B][U]200ms[/U][/B]
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.)

[...]

// The number of milliseconds for which the device posture must be stable
// before we perform an orientation change. If the device appears to be rotating
// (being picked up, put down) then we keep waiting until it settles.
private static final int SETTLE_TIME_MS = 200;

Then the talked-about "orientation delay" option was added in AOKP:

commit 94d7c35becdbdb129541fd3aa60e6e9d5f9dca7a
Author: Roman Birg <romanbirg@gmail.com>
Date: Sat Jan 7 12:44:16 2012 -0600
use a custom setting for SETTLE_TIME_MS

which added this to frameworks/base/core/java/android/provider/Settings.java:

public static final String ACCELEROMETER_ROTATION_SETTLE_TIME = "accelerometer_rotation_settle_time";

That setting was then introduced into the AOKP's ROMControl app:

commit 6b208ed81ce18a76c87e448b78972c0dda37a23d
Author: Roman Birg <romanbirg@gmail.com>
Date: Sat Jan 7 14:36:53 2012 -0600
Update many things!
- fix white spacing in strings/arrays
- add rotation rotation options
- add advanced toggle settings

[...]

mAnimationRotationDelay = (ListPreference) findPreference(PREF_ROTATION_ANIMATION);
mAnimationRotationDelay.setOnPreferenceChangeListener(this);
mAnimationRotationDelay.setValue(Settings.System.getInt(getActivity()
.getContentResolver(), Settings.System.ACCELEROMETER_ROTATION_SETTLE_TIME,
200) + "");

<!-- animation rotation -->
<string-array name="rotation_animation_delay_entries">
<item>10 ms</item>
<item>25 ms</item>
<item>50 ms</item>
<item>75 ms</item>
<item>100 ms</item>
<item>150 ms</item>
<item>200 ms</item>
<item>250 ms</item>
<item>300 ms</item>
</string-array>

However, that option didn't live long and obviously a delay customization has to be reimplented for JB.. going to try out a delay of 0ms to figure out if it is even worth it..if it really is only 40ms on JB now then YTF does it still take so0O darn lo00O0ngzz^^^ :rolleyes:

maybe going to mess with that 200ms lowpass heh :cool: