OSK consideration for life cycle changes in unity8 windowed mode

Access to the On-Screen-Keyboard, as provided by Maliit, is predicated on the application being “active”. Unity8’s life cycle management, in small screen devices had always stopped (via SIGSTOP) any application which was not the top most application. From a security perspective this provided protection from a nefarious app from taking over, while in the background, to the input stream of the user’s interaction with the top-most active application. With the advent of convergence, unity8’s life cycle management has grown to accommodate both small screen and large screen device configurations. For large screens, “windowed mode” is a mode that can be auto & user activated based on screen size and presence of keyboard/mouse. During “windowed mode” the life cycle permits applications to remain “active” if they are visible but not the top-most or “focused” application (the user experience example is working on a document in the top-most window while watching video in an active but unfocused window). Remaining active, while not in the user’s “focus” creates a risk in that an application could connect to Maliit and take over the user’s input intended for the focused application. So while this is bad, the top-most application will not reflect the input, as it would be consumed by the nefarious app. It’s worth noting this risk does not exist with hardware keyboard input, which is the largest majority of expected use case. Security team would classify the severity as “medium” but we need to treat with priority and sensitivity due to the marketing investment we have made in touting the security of Unity8/Mir.

our plan of attack is covered in this document
https://docs.google.com/document/d/1Y7p_8jee6Kiv4KQwZBClFl23RGFVFfBKoOcMh9ymdqw