The following is the first few sections of a chapter from The Busy Coder's Guide to Android Development, plus headings for the remaining major sections, to give you an idea about the content of the chapter.

Plugin Patterns

Plugins have historically been a popular model for extending the functionality of a base application. Browsers, for example, have long used plugins for everything from playing Flash animations to displaying calendars.

While Android does not have a specific “plugin framework”, many techniques exist in Android to create plugins. Which of these patterns is appropriate for you will depend upon the nature of the host application and, more importantly, on the nature of the plugin. This chapter will explore some of these plugin patterns.


Having read the chapters on app widgets (to be exposed to RemoteViews) and the Loader framework would be useful, though neither is essential for grasping the core concepts presented in this chapter. Similarly, this chapter has a case study that covers a lockscreen widget, so knowing a bit about those will help, but is not absolutely essential. Another sample involves the use of custom permissions, which are subject to a vulnerability covered in another chapter.

Definitions, Scenarios, and Scope

For the purposes of this chapter, a “plugin model” refers to an app (the plugin “host”) that is being extended by other apps (the “plugins”) that are largely dedicated to that job.

Certainly, there are plenty of ways that apps can work together without one being a plugin to another. The user’s Web browser is not a plugin of your app when you call startActivity() to view a Web page, for example.

By contrast, the Locale app can be extended via plugins, written either by two forty four a.m. (the authors of Locale) or third parties. These plugins have no real value to the user other than by how they improve what Locale itself can do. This sort of structure, therefore, qualifies as a plugin model.

In particular, this chapter will focus on two general scenarios for wanting a plugin model, though others certainly exist:

  1. You want to allow third parties to extend the capability of your app, much as two forty four a.m. wanted with Locale, or
  2. You want to reduce the number of permissions in your core app by delegating some permissions to plugins, so users can “opt into” those permissions

The Keys to Any Plugin System

The preview of this section was fed to a gremlin, after midnight.

Case Study: DashClock

The preview of this section will not appear here for a while, due to a time machine mishap.

Other Plugin Examples

The preview of this section may contain nuts.