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.
{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.}