Multi-Window, and Multi-Instance, Like It or Not

Due to the way that multi-window modes in Android are implemented, third-party app developers can cause your app to behave in ways that you might not expect. In particular, third-party developers can:

• Cause 2+ instances of your exported activities, like your launcher activity, to run simultaneously in multiple windows

• Cause your non-resizeable exported activity to appear in a window, even though you are trying to avoid this by using android:resizeableActivity="false"

How do I know this? Because I did it myself, in response to seeing reports of this sort of thing hitting the Play Store.

In a couple of hours, I cobbled together Sidecar. The user can pick a supported launcher activity from apps on the device, then add a “Sidecar” tile to their notification shade. Tapping the tile will launch their chosen activity in a separate window (assuming that the device is already in split-screen mode). This works even if there is already an instance of one of your activities in another window, and this works even if you are trying to avoid multi-window mode via android:resizeableActivity="false".

Sidecar has lots of usability warts. After all, I only spent a couple of hours on it. However, it illustrates the situation.

I have no idea if these capabilities are intentional. Outside of accessing one hidden field via reflection, my code uses stock API capabilities, and that reflection is helpful but not essential. Heck, Sidecar doesn’t even need any permissions, let alone scary ones. So, I don’t know if this sort of stuff was part of the plan, whether it is an accident of the APIs, or something else.

Ideally, your activities are fairly self-contained and make few assumptions about the world around them, such that if more than one instance winds up on-screen at once, the activities can survive without crashing. And, ideally, all of your activities are resizeable. This is not an ideal world, and so it will not be shocking if you decide that some of your activities fail on one or both of these counts. In fact, the big reason I wrote Sidecar is so people can understand a bit more how their apps behave when used this way.

Activities that cannot support these things may require some adjustments to block multi-instance and forced-resize scenarios. Having singleTask or singleInstance for android:launchMode on the <activity> breaks Sidecar, which is why I filter them out of the list of Sidecar-supported apps that users can choose from. There may be other ways that block these features as well.

The fact that some power users wind up with apps like Sidecar is not that big of a deal. Even if some popular home screen replacements and utility apps start offering this sort of capability, they still only affect a tiny percentage of the Android user base. What worries me is the possibility that device manufacturers might start offering these features. And even then, the “worry” is more about unexpected app behavior than security concerns.

In summary:

• Consider testing your app where more than one instance of your activities are visible at a time, to see if that causes problems

• If you get crash reports from the field with a seemingly-impossible scenario (“it’s like Activity X is in both State Y and State Z at the same time!”), Sidecar-style multi-instance behavior may be the source of the problem

• Try really really hard to allow all of your activities to be resizeable, since they may be resizeable whether you like it or not

• Hope that this all works out