Drawing over other apps — Marshmallow edition

One floating component fits, well, not everyone.

If I had to pick a trend for the most wanted/advertised type of feature for 2014/2015, I would blindly choose the “floating component” one over all the others. And “over the others” is particularly appropriate, now more than ever: because the floating component is designed to hover over the screen, on top of every other component.

Typical examples of Android apps that provide a floating component (from left to right): Facebook Messenger [Chat Heads], Musixmatch [FloatingLyrics], Link Bubble, Pocket.

The apps that you see above are just the tip of the iceberg of all the floating components that were added in the last year or so.

One could argue that this is what makes Android so extremely flexible. Which I would agree upon. But changes might be just around the corner with Android’s latest, soon-to-be-released Marshmallow version.

Before that, let’s see what makes these floating component great for a whole lot of users out there.

Context is king

“Why would you even want something that pops up and gets in the way of whatever you were doing before that?”

The answer to this question is the reason why (some) people love floating components so much. And the answer is: context. To give a better understanding of what context means, let’s go through a few examples.

Take Link Bubble, for instance. It basically opens web pages without taking up the whole screen, with the ability of collapsing them to a single floating bubble. Why is it so popular? Well, if you’re reading a feed (be it on Twitter, on Reddit, on Facebook, ..), here’s what usually happens:

1. You click on a link
2. You wait for the browser to open up [using Chrome? Well, wait more then]
3. You wait for the page to load
4. You finally enjoy the content

Sounds like a lot of waiting right there. Here’s what happens when you use Link Bubble:

1. You click on a link
2. Link Bubble shows up and starts loading the page, but it does not take up all the screen space, being just a small bubble
3. You keep reading the feed, eventually clicking more links
4. When you’re done, read all the pages you’ve opened by tapping the small bubble

Waiting times are simply erased. Gone. Disappeared. Ceased to exist. This is great, right? All that thanks to a floating bubble that appears right when you need it.

Another example is Musixmatch. You’re a music addict, constantly listening to your favorite songs on Spotify and singing along them. What if you want to see the lyrics to that song? Typically, here’s what happens:

1. You open the browser
2. You search on Google for the lyrics
3. You navigate through the sea of ads on some lyrics web sites
4. You finally enjoy the lyrics

All of that changes with Musixmatch. Every time you play a song, Musixmatch conveniently prompts you the lyrics by means of a floating bubble (called FloatingLyrics), so that you can learn the words and sing on time. So, the experience is shrunken down to:

1. Select a song on Spotify
2. FloatingLyrics loads the lyrics by means of a bubble, which you can minimize/maximize at will

Have you started noticing a pattern? It’s all a matter of getting the content that you want to see, right when you want to see it, without blocking whatever you were doing before.

In some cases, the context is suggested by the user (e.g., when you click on a link) and, in some others, it is inferred automatically (e.g., when you play a song on Spotify).

Have you ever wondered what sorcery is required to display these awesome and disruptive floating bubbles?

Up to Lollipop

Floating components can be displayed by requiring the following permission:

android.permission.SYSTEM_ALERT_WINDOW

App info screen for an app that has requested the SYSTEM_ALERT_WINDOW permission.

As the name suggests, this permission indicates a window that is used by the system to show an alert to the user, hence staying on top of everything else.

This is all it is required for an app to display a so-called floating window. It is merely a question of creating a View and manually adding it to the WindowManager.

The permission is shown only once at install time and can be viewed by navigating to the “Apps” section in the Settings screen.

No big surprise here. But then comes Marshmallow…

Marshmallow

Android Marshmallow is right around the corner and, thanks to its latest Developer Preview 3, it seems to have reached a close-to-final version. Of course, the biggest addition is most likely the new app permission model, which now resembles what iOS is sporting since the beginning and allows for a granular, runtime per-app permission control. In a down to earth way of putting it, permissions can now be enabled and disabled by the user at his own discretion.

What does this mean for the SYSTEM_ALERT_WINDOW permission and for all the floating components out there? Well, a whole lot of troubles.

It appears that this capability has caught Google’s attention, because they decided to dedicate an entire settings screen to apps that take advantage of this feature.

The bad news is: this permission is disabled by default. Even worse, this permission cannot be requested by programmatically prompting a request dialog to the user, but must be explicitly enabled by navigating to the settings screen, selecting the app and triggering the switch; a bit like when you need to manage the Device Administrators (Android Wear, Device Manager, PushBullet, ..).

The recommended approach, both by common sense and by Google itself, is to guide the user as much as possible through the required steps: for instance, offering a quick shortcut to the “Draw over other apps” page could be of great help to the user.

Considerations

I endorse the decision of emphasizing the “draw over other apps” permission, given the fact that some users simply do not want anything popping up on their screen without their explicit approval. In a more general sense, the direction that Android is taking by making use of runtime permissions is undeniably right for many reasons, in particular when it comes to more privacy control for the user and faster adoption for updates.

What I’m a bit baffled by is the decision of disabling the permission by default. By doing so, the whole context-triggered magic is somehow lost and the user is left with yet another additional step to take advantage of a feature that could help him save some time or enjoy more content: and we all know how hateful it is to enable stuff in the settings, particularly stuff that we do not yet know.

My educated guess is that Google wants to slow this floating trend down, either because it circumvents the standard components (apps, widgets and notifications), or because Android users were annoyed by floating bubbles popping on their screen, or because it might be dangerous.

I still tend to disagree, regardless of the three aforementioned reasons. Developers (and, in turn, companies) that craft, tailor and publicize a floating component are perfectly aware of how badly users can react to a floating thing that suddenly pops up, unwanted, unrequested; and in the end, developers/companies are the ones that need to deal with the reactions and the consequences. It is in their own interest to ease the process of disabling the floating component for those users who do not want them. All the examples that I have mentioned before manifest this sense of knowledge on the subject, since almost each one of them provides a way of disabling entirely the floating feature.

It’s easier to deal with a single user that dislikes a feature, rather than dealing with a horde of users that do not understand why you are asking them to enable a feature that they do not yet know.

It is extremely unlikely that this is going to change when Marshmallow becomes publicly available. But I feel like Android is losing an important aspect of its great flexibility, whilst users are losing a new and great way of interacting with some apps’ features.