While reading a book, Android Wireless Application Development, it tells that

Applications might also enforce their own permissions by declaring them for other applications to use. The applications can declare any number of different permission types, such as read-only or read-write permissions, for finer control over the application.

I couldn't get why do applications need to set read-write or read-only permissions for allowing another application to use its applications.

For example, as illustrated in Android Developer, it shows how an application uses another Map application to show its address. But why do the app needs to set read-only or read-write permissions for allowing another app to use it?


Because if the app is storing your data, it's responsible for keeping it secret. To take an example, let's say there's an app to store something you'd rather keep quiet, such as your collection of Jason Donovan albums. This app would have a database with the relevant information inside, and this database is private to the app. No other app can read it (without root), and thus your embarrassing music taste is kept secret.

Now let's say the app author wants to allow other apps to use the same data. It could be another app by the same author, or he could widen it to allow other authors to access the data. That way, other apps would be able to add a home screen widget with a Jason Donovan album of the day, or create calendar entries for the anniversary of each album's release, or import anything else. He does this by creating a content provider, adding it to the manifest, and publishing instructions for developers on the format of the data and how to access them. The content provider is like a server: it provides a way for other apps to query the app's data and get results back, without accessing the database directly.

If that's all he does, then any installed app can access the data. You install an innocuous-looking flashlight app that only has "INTERNET" permission, and suddenly it's able to find out all your embarrassing music and email it to scammers for blackmail purposes. Obviously this is undesirable: an app developer who would let this happen should not be trusted with your data.

The app developer can prevent this by creating a new permission, and giving it a human-readable description, such as "Read your favourite Jason Donovan albums". Creating the permission doesn't do anything itself: he also needs to change the content provider so that when an app queries it, it checks that that app has the permission before responding to the request. If the app has the permission, it gives it the data it asked for; if the app doesn't, it might choose to give it an exception (an error that tells the program what the problem is), or simply to return no or partial results. For example, it might tell the app about the Rolling Stones albums you're not ashamed about, but not the embarrassing Jason Donovan albums.

This way, the innocuous-looking flashlight app can't access your data. Before you install an app that wants access to the data, you can see "Read your favourite Jason Donovan albums" in the list of permissions, and you can abort installing if you don't trust the app author with that information.

How many permissions the app creates depends on what kind of access it offers other apps, and how fine-grained the controls should be. In our example, the app doesn't have a way for other apps to add albums, so there's no need for a read-write permission. Even if it did, it may be that the app only has a read-write permission, which other apps need to have to either see the list of albums or edit the list. This might be enough for a simple app like this. But for something like a social media app, it's more important to limit how many apps can send messages (or write content) on your behalf, so two separate permissions might be used in that case. It's up to the app author to decide how many permissions are appropriate for the app, giving users control over their privacy without creating confusing combinations that are hard to understand.

  • That's a good descriptive answer.But could you tell me why did you say about blackmail.I think for your secret songs no one would blackmail you or did you just meant to give an example.Is there any app that uses both read and write permission for giving data to another app.Also who really grants the permission(to another app):is it the author or the author acts on behalf of the user?Could you help me. – justin Dec 6 '14 at 5:29
  • Blackmailing you about Jason Donovan songs is just an example. I'm sure you have other data on your phone that you wouldn't want in the hands of bad guys. The built-in Contacts app is an example that uses separate read and write permissions. Granting the permissions is no different to built-in ones: the user grants the permission when he installs the app that needs that permission. – Dan Hulme Dec 6 '14 at 8:59
  • :okay.But is there any need of write permission.I'm asking this because in a Contacts app even if one(another app) would add contacts to the Contacts app(if he has write permission) is there any security breach taking place?I think adding contacts would merely have no security issues isnt't it? – justin Dec 8 '14 at 5:10
  • Write permissions aren't just about adding new data. One common practice of malware on PCs is to send all your data to the attacker and then delete it from your computer, or encrypt it, and then extort money for the return of the data. – Dan Hulme Dec 8 '14 at 8:21
  • :How could the example(malware on PC) deal with write permission?I think it just involves sending the data to the attacker.Do you mean that even sending the data from an app to someone is included in the write permissions? – justin Dec 8 '14 at 8:30

Not the answer you're looking for? Browse other questions tagged or ask your own question.