Ever since Samsung “commercialized” the feature, multi-window support on Android has been a point of contention among users and developers, not to mention Google. OmniROM wants to include such a feature in its list but is approaching the matter with a bit more caution, research, and common sense.
Android is technically capable of supporting multi-window setup, be it split windows or floating windows. This is evidenced not only by Samsung’s proprietary implementation but also by other third-party apps out there. The problem, however, is not exactly technical. Some believe that Android was not designed for such a use case, with apps and windows intended to take up the full view. OmniROM seems to be from the opposite camp but, at the same time, wants to use a more well-thought out implementation rather than putting in all the bells and whistles.
There are currently two known multi-window modes available, both of which are implemented by Samsung on its flagship and S pen devices. There is a floating window implementation that makes supported apps behave like regular resizable and movable windows. The second is the split view window that is arguably a more useful mode. But OmniROM finds neither options to be practical or sensible and tried looking elsewhere for inspiration.
That inspiration came somewhat curiously from WebOS and its concept of stacks. This is basically a twist on split view mode. But instead of being limited to only two slots at any given time, this implementation allows windows to stack under the secondary window, which is the one the right. Only two apps are allowed to run in the foreground as normal, but the others are just paused underneath. As they say, a picture is worth a thousand words and moving pictures a thousand more. Note that the video below is just a concept video and not the actual finished implementation.
OmniROM’s multi-window feature is very much an early work in progress and can change, or maybe even yanked out, in the future. The good news is that the OmniROM devs are more forward-looking than others. For one, they want the feature to be available to as many apps as possible without requiring any change. Best of all, they want the code changes against AOSP to be as minimal as possible so that applying it to future Android releases won’t be a chore and can, perhaps, even be approved by Google in the future.
SOURCE: OmniROM
I’d rather see a well thought out implementation than a half baked one. This is why I like OmniROM – and run it on my phone.