Mark Murphy - Beginning Android

For example, suppose you have created a content provider that retrieves RSS and Atom feeds from the Internet based on the user’s feed subscriptions (via OPML, perhaps). The content provider offers read-only access to the contents of the feeds, with an eye toward several applications on the phone using those feeds versus everyone implementing their own feed-poll-fetch-and-cache system. You have also implemented a service that will get updates to those feeds asynchronously, updating the underlying data store. Your content provider could alert applications using the feeds that such-and-so feed was updated, so applications using that specific feed could refresh and get the latest data.

On the content-provider side, to do this call notifyChange()on your ContentResolverinstance (available in your content provider via getContext().getContentResolver()). This takes two parameters: the Uri of the piece of content that changed, and the ContentObserverthat initiated the change. In many cases, the latter will be null; a non- nullvalue simply means the observer that initiated the change will not be notified of its own changes.

On the content-consumer side, an activity can call registerContentObserver()on its ContentResolver(via getContentResolver()). This ties a ContentObserverinstance to a supplied Uri — the observer will be notified whenever notifyChange()is called for that specific Uri. When the consumer is done with the Uri, unregisterContentObserver()releases the connection.

In the late 1990s a wave of viruses spread through the Internet, delivered via email, using contact information culled from Microsoft Outlook. A virus would simply email copies of itself to each of the Outlook contacts that had an email address. This was possible because, at the time, Outlook did not take any steps to protect data from programs using the Outlook API, since that API was designed for ordinary developers, not virus authors.

Nowadays, many applications that hold onto contact data secure that data by requiring that a user explicitly grant rights for other programs to access the contact information. Those rights could be granted on a case-by-case basis or once at install time.

Android is no different, in that it requires permissions for applications to read or write contact data. Android’s permission system is useful well beyond contact data, and for content providers and services beyond those supplied by the Android framework.

You, as an Android developer, will frequently need to ensure your applications have the appropriate permissions to do what you want to do with other applications’ data. You may also elect to require permissions for other applications to use your data or services, if you make those available to other Android components. This chapter covers how to accomplish both these ends.

Requesting the use of other applications’ data or services requires the uses-permissionelement to be added to your AndroidManifest.xmlfile. Your manifest may have zero or more uses-permission elements, all as direct children of the root manifestelement.

The uses-permissionelement takes a single attribute, android:name, which is the name of the permission your application requires:

android:name="android.permission.ACCESS LOCATION" />

The stock system permissions all begin with android.permissionand are listed in the Android SDK documentation for Manifest.permission. Third-party applications may have their own permissions, which hopefully they have documented for you. Here are some of the more important built-in permissions:

• INTERNET, if your application wishes to access the Internet through any means, from raw Java sockets through the WebViewwidget

• READ CALENDAR, READ CONTACTS, and the like for reading data out of the built-in content providers

• WRITE CALENDAR, WRITE CONTACTS, and the like for modifying data in the built-in content providers

Permissions are confirmed at the time the application is installed — the user will be prompted to confirm it is OK for your application to do what the permission calls for. This prompt is not available in the current emulator, however.

If you do not have the desired permission and you try to do something that needs it, you may get a SecurityExceptioninforming you of the missing permission, but this is not a guarantee — failures may come in other forms, depending on if something else is catching and trying to handle that exception.

The other side of the coin, of course, is to secure your own application. If your application is merely activities and intent receivers, security may be just an outbound thing, where you request the right to use resources of other applications. If, on the other hand, you put content providers or services in your application, you will want to implement inbound security to control which applications can do what with the data.

Note that the issue here is less about whether other applications might “mess up” your data, and more about privacy of the user’s information or use of services that might incur expense. That is where the stock permissions for built-in Android applications are focused — can you read or modify contacts, can you send SMS messages, etc. If your application does not store information that might be considered private, security is less of an issue. If, on the other hand, your application stores private data, such as medical information, security is much more important.

The first step to securing your own application using permissions is to declare said permissions, once again in the AndroidManifest.xmlfile. In this case, instead of uses-permission, you add permissionelements. Once again, you can have zero or more permissionelements, all as direct children of the root manifestelement.

Declaring a permission is slightly more complicated than using a permission. There are three pieces of information you need to supply:

1. The symbolic name of the permission. To keep your permissions from colliding with those from other applications, you should use your application’s Java namespace as a prefix.

2. A label for the permission: something short that is understandable by users.

3. A description for the permission: something a wee bit longer that is understandable by your users.

android:name="vnd.tlagency.sekrits.SEE SEKRITS"

android:label="@string/see sekrits label"

android:description="@string/see sekrits description" />

This does not enforce the permission. Rather, it indicates that it is a possible permission; your application must still flag security violations as they occur.

There are two ways for your application to enforce permissions, dictating where and under what circumstances they are required. You can enforce permissions in your code, but the easier option is to indicate in the manifest where permissions are required.

Activities, services, and intent receivers can all declare an attribute named android:permission, whose value is the name of the permission that is required to access those items: