Until we can reference these managers through the current context,
we should hide the constants that are utilized to retrieve them.
Current implementations should stick to the singleton getInstance
pattern.
Change-Id: I6c084a3a5b0745b0b6c5d10e000a40f5e61117ea
Create a simple CustomTile object with builder which lets a 3rd party
application publish a quick settings tile to the status bar panel.
An example CustomTile build:
CustomTile customTile = new CustomTile.Builder(mContext)
.setLabel("custom label")
.setContentDescription("custom description")
.setOnClickIntent(pendingIntent)
.setOnClickUri(Uri.parse("custom uri"))
.setIcon(R.drawable.ic_launcher)
.build();
Which can be published to the status bar panel via CMStatusBarManager#publishTile.
The CustomTile contains a click intent and click uri which can be
sent or broadcasted when the CustomQSTile's handleClick is fired.
This implementation closely mirrors that of NotificationManager#notify for
notifications. In that each CMStatusBarManager#publishTile can have an appended
id which can be kept by the 3rd party application to either update the tile with,
or to remove the tile via CMStatusBarManager#removeTile.
Change-Id: I4b8a50e4e53ef2ececc9c7fc9c8d0ec6acfd0c0e
Adnan Begovic