TL;DR: Implementing it in your apps is more hassle than it’s worth.
To answer the most common question; Yes, the two apps on one screen functionality of the Galaxy Note 10.1 is limited to a few apps. All of them ship with the device.
The code to support multi-window mode is baked into the core Android framework on the device (so much so that the classes are in the framework library odex), which means that it could be submitted to the #AOSP to become part of Androids core functionality.
The APIs reside in the android.sec.multiwindow package, and applications can use the MultiWindowManager class in that package to check to see if multi-window mode has been enabled (You can get an instance of the MultiWindowManager class by calling MultiWindowManager.getInstance(Context)). The getInstance method is a shortcut for getting a reference to the MultiWindowManager service which runs under the name “multiwindow”, so it seems to be closely modelled on Androids existing WindowManager (which isn’t a big surprise).
MultiWindowManager.isMultiWindowServiceEnabled allows modified applications to detect if Multi-Window mode is available, which allows them to adapt their layouts to show the MultiWindow options. This indicated to me that Samsung may use this code on other devices, and, sure enough, when I checked my S3, it too has the multiwindow classes in it’s framework jar file. The S3’s screen is too small to make multiwindow mode useful, but I wouldn’t be surprised if someone gets a proof of concept going to show it can be done.
Implementing multi-window support in an app doesn’t appear be too difficult from what I’ve seen if an SDK is available. Currently the applications which support MultiWindow mode are part of the firmware and assume the MultiWindowManager will be there, which isn’t great approach for third party apps because on most devices it wont. You could get round this with a bit of java reflection, but it’d be nice to see an API which handles that for developers.
The apps all use Fragments to present their layouts (as every app now should), and the main layout quirks focus on providing the multi-window mode options to users. Reassuringly most of the functional code is unchanged for the stock apps between the AOSP and what’s installed.
Personally I’m happy to hold off to see what happens with Multi-Window mode. If the changes don’t end up in the #AOSP then Samsung shouldn’t find it too difficult to release a stand alone SDK, but they would need to rename the package to something obviously Samsung related in the same way they have their SPen SDK (which uses com.samsung.spensdk). Either way I’d rather wait for that to happen than build an app with the current code which could create some maintenance headaches when the API becomes public.
Hope you guys find this useful. It’s given me a Friday afternoon away from +Funky Android work, so I’ll be catching up with emails for the rest of the day which means comments may go unanswered for a bit.