SYSTEM_ALERT_WINDOW, Android O, and Disappointment

Two days ago, Check Point researchers breathlessly reported on something that I had pointed out well over a year ago: apps requesting the SYSTEM_ALERT_WINDOW permission automatically get it. The fact that Check Point thinks that this is news is… disappointing.

Check Point then goes on and claims that Android O’s TYPE_APPLICATION_OVERLAY is “a new restrictive permission”. Since TYPE_APPLICATION_OVERLAY is not a permission, Check Point’s claim is… disappointing.

So, let’s get caught up on the whole SYSTEM_ALERT_WINDOW situation.

Apps requesting that permission have the right to float windows over other apps. Any app can do this on a temporary basis — a Toast is a window floating over whatever is on the screen. To do this with custom windows and arbitrary duration, you need SYSTEM_ALERT_WINDOW. Anything you install in Android that pops stuff up out of nowhere (e.g., Facebook’s legendary “chat heads”) or has some form of always-available UI (e.g., drawers that you can slide open from the screen edge) are using this permission.

Originally, this permission was dangerous, so the user would be notified about it at install time. On Android 6.0, it was converted into an appop-style permission, one that the user has to grant manually in Settings. But, starting with Android 6.0.1, apps requesting that permission would get it automatically, without any notice to the user.

IMHO, this was a very poor decision from a security standpoint. On that, Check Point and I agree.

The change that Check Point is alluding to is that the particular window “types” that you can use via SYSTEM_ALERT_WINDOW has been reduced to a single TYPE_APPLICATION_OVERLAY, and this window type cannot float over core system UI (e.g., navigation bar, status bar). Of note, this allows the user to get into Settings, where they can then be blocked from making any changes by a floating window. The fact that Check Point thinks that this is a significant improvement is... disappointing.

This minor improvement does not really address the core security issues with `SYSTEM_ALERT_WINDOW`, though other changes that Google has been making help, such as blocking apps from knowing what app is in the foreground. That *might* be just about enough to allow the access-Settings-from-the-shade approach to work, though I am skeptical. Malware authors are very creative.

{UPDATE: Mishaal Rahman of XDA-Developers pointed out that Android O apparently now has a Notification that appears when an overlay is active. On the plus side, this provides real-time information about overlays, and if overlays cannot interfere with the notification shade, it provides rapid access for turning it off. It remains to be seen how effective this will be — for example, users may ignore the Notification if they regularly use apps that employ overlays. However, it is definitely a step in the right direction, and if it works as advertised, I will be very grateful.}

And, in other respects, Android O makes the SYSTEM_ALERT_WINDOW situation worse.

While most of my book examples are just examples, one that I run on my personal device is SAWMonitor. This listens for ACTION_PACKAGE_ADDED and ACTION_PACKAGE_REPLACED broadcasts, then raises a Notification if the app in question requests SYSTEM_ALERT_WINDOW. This way, I am notified in real time if an app that I just installed has the rights to draw over other apps, so I can go into Settings and disable that “feature”.

However, I have to modify SAWMonitor to deal with the implicit broadcast ban. We can no longer listen for ACTION_PACKAGE_ADDED and ACTION_PACKAGE_REPLACED broadcasts via the manifest, and Google is fairly forceful in stating that this is intended. So, instead, I will have to have SAWMonitor use alarms or jobs to find out which new/changed apps since the last check have requested SYSTEM_ALERT_WINDOW. So now, rather than having my process run only when I happen to install or update an app, I have to have my process run rather frequently, so I can find out about SYSTEM_ALERT_WINDOW changes in near-real-time. Android’s changes to reduce process churn, in this case, will dramatically increase process churn (and battery usage), and that is… disappointing.

And, of course, ODP1 continues to automatically grant SYSTEM_ALERT_WINDOW privileges to apps, without warning the user. “Disappointing” does not even begin to do justice to my sentiments on that subject. {UPDATE: Though the real-time Notification mentioned in the update from above certainly helps a fair bit.}

Nervous about how the newest version of Android affects your app? Consider subscribing, then asking questions in the office hours chats!