New tiles in Android N with the Edit Screen showing

Android N introduced a new Quick Settings Tile API, which will no doubt be used innovatively and exploited by developers in the future when the version reaches release level. However, what exactly can we expect these tiles to be used for, how can they be used and how are they likely going to be abused?

Note: Although it has not changed between Preview 1 and Preview 2, the tile API may change before N’s release. It’s possible therefore if you’re reading this in the far future that there may be things that have changed

What exactly is this API?

Quick Settings in Android are not new. They’ve been in AOSP since 4.2 Jelly Bean and have taken a few forms; firstly their own page off the notification drawer, then as an expanded state from the drawer, and in N they gained a collapsed state also.

Although N is the first version to include a proper API, the ability to create custom tiles is not new, in fact the Broadcast (Intent) Tile has existed since 5.0 Lollipop, which provided a very non-user-friendly way of adding their own tiles with the help of third party apps for this purpose, including my own Custom Quick Settings. In N the Intent tile still exists in the code, however it does not appear to be able to be added from the “edit” interface of the quick settings.

Adding a tile using the edit interface in Android N

Instead, developers can create their own tiles, using the new TileService class, and declaring the tiles in the Manifest. They then appear in the “edit” interface and need to be dragged into their preferred position by a user before being able to be initalised by the app. (left)

This means that, in order to use the API, developers must declare all their tiles before the app is run in the Manifest, as they are extensions of Services. They then all appear in the edit screen with the default title and icon declared in that same Manifest node. There does not appear to be a maximum number of tiles that can be declared in the Manifest, however services can be enabled and disabled using the package manager as a normal service would, which allows for showing and hiding tiles from this screen, just so long as they were declared initially.

Similarly, deleting the tiles is done by dragging tiles back to the list from the currently added tiles. Note that when rearranging & deleting tiles, tiles will have their default title and icon from the Manifest, regardless of whether they have been updated by a TileService.

How will the API be used & abused by apps?

The following section is all speculation about how this API will be used. Only the future will bring what will actually happen.

In the API Overview for N, Google say this about Quick Settings:

Quick Settings tiles are reserved for controls or actions that are either urgently required or frequently used, and should not be used as shortcuts to launching an app.

This is advise, and I predict that it is unlikely to be followed by a fair few developers, especially when under pressure from companies and users.

The three main uses for tiles that are likely to surface are as follows:

Shortcuts

Shortcuts are what many would think as the first use for this new API, allowing for developers to simply open their apps from the Quick Settings, which some may argue falls under the “frequently used”, however many of these shortcuts will only clutter the “edit” interface. Not advised, but will probably happen. Google already broke this advise and added a Calculator tile in Preview 2

Activity Shortcuts

Arguably coming under shortcuts, however not exactly the same thing. Like launcher shortcuts, which allow a specific activity or part of an app to be opened, tiles could be used to do the same thing. A user may want to open the Bookmarks activity of Chrome for example. Again, this is not advised and is less likely to happen than just app shortcuts, but would have the same disadvantages to them.

Actions

The only real recommendation from Google, and possibly a chance for developers to get rid of single-button widgets. I’ve showed an example of a toggle that could turn on and off a smart-bulb, but it could be applied to millions of actions that are toggled frequently by the user. A good idea, however too many tiles will only cause the same cluttering…

Tile Abuse

Task killers, SD cleaners, offers/adverts (they’re technically not notifications, it may be a loophole around the notification advert restriction), app icons with tickers, you can probably guess what developers will come up with just to get a tile in the list. Thankfully, as all tiles must be added by the user, there’s far less chance of spam adverts and unwanted tiles simply appearing, and if they do you can just remove them.

Tile Restrictions

One major difference between system tiles and custom tiles is that the long click action is disabled for opening the “app info” screen. It’s possible to use double click however. Intent tiles on 5.0 to before N allowed for long click actions also, but were significantly slower at performing their action after being clicked.

Tiles can only have icons of a single colour, which is always tinted to either white (on state) or one of two shades of grey (for the inactive states). Unless an app icon is also a single colour and could work when being fully replaced with the listed colours, it’s not going to work here

Custom tiles can’t have RemoteViews, unlike system ones. You can’t have an expanded state for a tile, so you must either launch an activity on click or perform the activity there and then, and optionally update the tile to a new state to show what it’s done. It would be nice to see RemoteViews implemented in a future release, à la CyanogenMod, but this is the choice of Google.