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:

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.