Problems when handling orientation changes

Question

I need to handle orientation changes in my Android application. For this purpose I decided to use OrientationEventListener convenience class. But his callback method is given somewhat strange behavior.

My application starts in the portrait mode and then eventually switches to the lanscape one. I have some custom code executing in the callback onOrientationChanged method that provides some additional UI handling logic - it has a few calls to findViewById. What is strange is that when switching back from landscape to portrait mode onOrientationChanged callback is called twice, and what's even worse - the second call is dealing with bad Context - findViewById method starts returning null. These calls are made right from the MainThread

    @Override
protected void onCreate(Bundle savedInstanceState) {
    super.onCreate(savedInstanceState);
    listener = new OrientationListener();
}

    @Override
protected void onResume() {     
    super.onResume();
    // enabling listening
    listener.enable();
}
    @Override
protected void onPause() {
    super.onPause();
    // disabling listening
    listener.disable();
}

I've replicated the same behavior with a dummy Activity without any logic except for one that deals with orientation hadling. I initiate orientation switch from the Android 2.2 emulator by pressing Ctrl+F11 What could be wrong?

Upd: Inner class that implements OrientationEventListener

private class OrientationListener extends OrientationEventListener {
    public OrientationL() {
        super(getBaseContext());
    }

    @Override
    public void onOrientationChanged(int orientation) {

        toString();

    }
}

}

Answer 1

This is a documented bug in the emulator ONLY. A real device will not exhibit this double-lifecycle-events behavior. I had the same issue a while ago and it disappears on a real device.

I would suggest ignoring the problem if you can by only testing orientation changes in one direction until you get your hands on a physical phone. Otherwise you might be able to "skip" the second set of lifecycle calls by keeping a static boolean around indicating you've already gone through the first set.

See this issue report for more info.