Google has big plans for multi-window usage on Android beginning with the next iteration of the OS and directly inspired by the upcoming introduction of folding smartphone-specific developments announced during this year's Android Dev Summit. While most of the recently announced changes were covered in previous reports, there is at least one, referred to as "multi-resume," that appear to be applicable to all handsets and which may be even more impactful. Multi-resume will allow multi-windows to run concurrently and, perhaps best of all, it can be incorporated relatively easily with a simple addition to an app's manifest. That means that users will be able to run multiple apps at the same time on a single display without having those apps pause. With Android Q, that will get even better with full integration at the OS level and further optimizations, Google says.
Background: Prior to the new announcement, multi-window apps have already been available but have been severely limited in terms of actual functionality and real-world usability. More specifically, that's the "split-screen" feature that was introduced in Android 7.0 Nougat and it allowed users to rescale an app, if enabled by that app's developers, and show it side-by-side with another app. The task was also made simple and intuitive to accomplish, through a long-press on the recent apps icon or capacitive button or by long-pressing an app on the recent apps screen itself. However, it did not actually allow both apps to run at the same time, in spite of the multitasking prowess that Android has had baked-in since long before the split-screen feature's introduction.
Instead, it set the two as an active application - whichever the user had most recently interacted with - and an "OnPause" app. The OnPause app, as that term implies, was essentially paused. In short, that meant that unless a user interacted with the panel, what the user was seeing was a frozen preview of the app's last screen. While Google had introduced a series of recommendations for supporting multi-window, developers mostly just left things 'as-is', so the above situation remained true for the vast majority of apps. On the tablet side of the equation, that initial split-screen functionality went further still and allowed for multiple apps beyond just the first two but the underlying problem has, up to this point, remained.
It appears as though that's finally going to change with multi-resume and, building on the introduction of multi-display capabilities introduced with Android 8.0 Oreo, it's really about time that happened. However, the change really seems to be inspired by the fact that some devices will soon be splitting screens between multiple virtual displays encompassed within a single display panel. Namely, those are the previously revealed changes to the Android UI and associated code to support Samsung's recently announced foldable smartphone displays. As outlined with those announcements, those displays will require an OS that can adapt between one display or expanded display modes - or that supports two displays that separated virtually when they're folded up. In other cases, that will mean incorporating a level of continuity between panels and creating a consistent experience across display hardware that can change, from the user and code-side perspective, within seconds and repeatedly.
Impact: Bearing that in mind, that change is going to have benefits for those who can't afford to buy into that functionality too. For starters, it should allow better multi-app experiences - or at least multi-display experiences - when an Android smartphone or tablet is connected or mirrored to a secondary display. But it should also mean a better experience when using two or more applications displayed simultaneously on a single screen since users will be able to have two apps that are visibly running in real-time and at the same time. Once implemented at the system level, that will open up a new range of possibilities in entertainment, convenience, and productivity as long as developers are targeting the appropriate API.