isInMultiWindowMode() Race Condition

In Android N, you can call isInMultiWindowMode() on your Activity. This should return true if you are in multi-window mode, false otherwise.

However, that is not always the case. In particular, if your activity was just recreated due to the configuration change that stemmed from the user exiting multi-window mode, and you call isInMultiWindowMode() during your onCreate() processing, it may still return true, even though we are not actually in multi-window mode at the time.

But, if you wait ~300ms, all of a sudden isInMultiWindowMode() will start returning true, even if you didn’t return control of the main application thread back to the framework. Apparently, the data that drives the isInMultiWindowMode() value is being updated in a background thread, independently of what is going on with respect to the configuration change.

This makes using isInMultiWindowMode() risky, particularly during onCreate() processing. You might find yourself doing one chunk of work in onCreate() based on isInMultiWindowMode() returning true, then having to turn right around and re-do that work in onMultiWindowModeChanged(), when you are informed that actually you are not in multi-window mode. Since the behavior is being driven by the timing of two independent threads, it is not even safe to assume that we will get consistent behavior here – sometimes, isInMultiWindowMode() might return false, because that thread finished its work before we got a chance to ask for the value in our onCreate() processing.

I would describe this as a race condition and a bug. Google describes it as working as intended. Hence, I would be very careful about relying upon isInMultiWindowMode().