Floating apps have become emblematic of Android's unique flexibility and range. No other mobile OS allows non-system apps to directly interact with users and overtake the screen while another app is supposed to be in the foreground. This capability allows for a powerful and customizable user experience, but it can also quickly become a problem if an app is poorly implemented or its developer abuses this privilege for malicious purposes.

Android 6.0 Marshmallow is setting some new rules for drawing on the screen. Starting with Developer Preview 3, apps targeting API 23 (or above) will have to ask users to grant permission for them to draw on top of other apps. This won't be done through the new à la carte-style permission system with friendly pop-up dialogs, but instead with a more daunting context switch to a list of toggles like we're accustomed to visiting after installing a new software keyboard.


The system permission in question is named android.permission.SYSTEM_ALERT_WINDOW and it has been around since API Level 1. The developer documentation is fairly brief, describing it simply as a way to open a window on top of other apps and warning developers that it's only intended for system-level activities.

Allows an application to open windows using the type TYPE_SYSTEM_ALERT, shown on top of all other applications. Very few applications should use this permission; these windows are intended for system-level interaction with the user.

Facebook Messenger debuted "Chat Heads" just over two years ago, giving users a perpetually available tap target on their screens to quickly see and respond to messages. While Messenger was far from the first app to make use of a floating UI, it can be credited with popularizing the feature and the now-familiar floating bubble interface. Since then, quite a few notable developers have either added floating elements (e.g. LastPass and MusixMatch) or built entire apps around the functionality (e.g. Link Bubble).

Why Change Anything?

So far, Google hasn't released any official statements regarding this change. In fact, this particular detail was left out of the API Overview for Preview 3. It's probable the Android team doesn't consider this important enough to describe along with all of the new capabilities listed on that page; but strangely, it has also been left out of the Behavior Changes page, where it almost certainly should have been documented. The only place with any record appears to be the Android API Differences Report, a somewhat unwieldy set of automatically generated pages that list modifications from one API level to the next. I'm really not trying to paint a picture where Google is trying to hide this change, but there's obviously no effort to make developers aware of the new behavior, either.

While there's no official explanation, the reasons for locking down this permission aren't hard to guess. The ability to draw on top of other apps is a profoundly risky proposition, especially given that the Android OS doesn't add any decoration to signify a background app is responsible for content on the screen.

For example, a malicious developer could display a cloned login screen for a popular app – let's say Facebook or Twitter – in an effort to steal credentials.

One interesting detail has surfaced thanks to the Developer Preview Issue Tracker. A Googler responded to a question by noting that the SYSTEM_ALERT_WINDOW permission had been "raised to be above dangerous." Android permissions are technically ranked as either 'normal' or 'dangerous' as described by the protection levels. (Note: 'signature' and 'signatureOrSystem' are also options, but they aren't relevant to this discussion.) In rare instances, certain capabilities have been given special attention because they necessarily have to grant very high-risk access to be functional. Some examples are input methods like software keyboards, and device administrators like Android Device Manager, which has the ability to initiate a factory reset. Drawing on top of other apps will now rank in this exceptionally high-risk category.

What Does This Mean For Users?

Users can look forward to yet another prompt asking for a permission, but this one won't look or feel like the new Android M permission dialogs. There's no way to authorize apps to draw onto the screen without a context switch. Developers will have to send their users to a special screen in the Settings app with specific instructions to enable the permission. If this sounds familiar, it's because the same pattern has been used for years when we're setting up Input Methods, and more recently with Accessibility and Device Administrators.

Developers can send users directly to the right screen for each app. There's only a quick context switch, a toggle, and then returning to the calling app with the back button. It's easy enough, but make no mistake, this flow is meant to feel intimidating. People are expected to feel nervous when an app gives them instructions and sends them to an unfamiliar part of the system, at which point they will be faced with a warning message that further reminds them that this might not be safe. For somebody who has never done this before, it should feel a little scary, like carrying a stranger's luggage through security at an airport.

2015-09-07 09.20.092015-09-07 09.20.232015-09-07 09.20.32

Left: LastPass notification. Center: List of apps that use System Alert Window. Right: Confirmation screen.

Some major apps are already being updated to support this new requirement. Credit for first raising the flag on this new policy belongs to Sebastiano Gottardo, a MusixMatch developer who discovered the issue while working on an update. Likewise, LastPass has been quick to add support for Android 6.0 permissions, and has already released an update to the Play Store. LastPass' flow simply involves posting a notification the first time a login form is detected, so long as the App Fill-In feature is enabled.

Not all apps that draw on top of the screen will be asking users to go through this step right away. Apps that target API Level 22 or below are automatically granted permission, presumably to maintain compatibility. Only by targeting API Level 23 (Android M) will developers have to send users through the extra steps. At least, that's how it works in Developer Preview 3 – Google could plausibly change this behavior for the final release, but don't bet on it. Regardless of API Level, users can revoke this permission from any app by visiting: Settings -> Apps -> Advanced (the gear button) -> Draw over other apps.

For Developers

If you're working on an app that makes use of the SYSTEM_ALERT_WINDOW permission, there are a few things you'll probably want to know. The Android 6.0 SDK introduces a couple of things to the API that make this new process relatively painless to implement.

To begin with, a call to Settings.canDrawOverlays() reports back whether or not your app has been granted permission to draw on the screen. If permission hasn't been granted yet, create an Intent and set its destination to Settings.ACTION_MANAGE_OVERLAY_PERMISSION and add a URI in the form of "package:<package name>" to send users directly to your app's page. Alternatively, you can leave off the URI to send them simply to the full list of apps. For sample code, check out this StackOverflow answer.


Unlike the new permission dialogs, this one should definitely include a custom UI to explain why users are being sent to another screen and what they should do there. The steps to support this change aren't complicated and don't add very much work for developers, but the change in context is an intentional hurdle. Developers will have to earn trust from users before asking for too many permissions, and this one may be just a step too far for some.

Android M may soon earn a reputation for an overabundance of confirmation dialogs, at least that's how it will feel to anybody setting up a new device. Fortunately, we need only grant each permission to an app once, so things will never get as bad as Windows Vista.