App Ops Developer FAQ
Since Android 4.3’s “App Ops” has hit Techcrunch, The Verge, and and GigaOM in addition to the original reporting from AndroidPolice, developers need to start thinking about what App Ops’ availability will mean to their apps.
What follows is a set of questions and answers about App Ops. Since nobody has really asked me these questions, I have compiled them into a fictionally-asked questions (FAQ) list. I will update this post from time to time as details emerge. Feel free to contact me if you have additional details that you believe belong in this FAQ, or if you have corrections to anything reported here.
What is App Ops?
App Ops is an activity, within the Settings app, that allows users to enable or disable operations on a per-app basis. These operations cover many common scenarios identified by permissions (e.g., read contacts, write contacts, access location), though it is not a pure one-to-one mapping.
Operations blocked by App Ops are inaccessible by the affected app, though that may vary by device.
So, Users Can Get to App Ops Through Settings?
Well, no.
While App Ops is an activity in Settings, it is not linked to by the main Settings screen. At present, there’s no known way for a user to get to App Ops just through Settings.
However, the activity is exported and has an <intent-filter>. There are already several apps on the Play Store that effectively serve as “launchers” for getting to the App Ops activity. One might imagine that various security/privacy-related apps may also give their users the option of visiting App Ops.
What Devices Have App Ops?
App Ops is part of the Android 4.3 edition of the Settings app. It is definitely available on the retail Nexus 7 (2013) devices, and is also definitely available for the production images that you can flash on various Nexus-series devices. It is also likely that App Ops will be part of the OTA updates for those same Nexus devices, as they roll out.
Whether App Ops will be available on other Android devices that ship with (or are upgraded to) Android 4.3 remains to be seen. Device manufacturers are capable of disabling this activity, and some may elect to do just that.
Does App Ops Revoke Permissions?
No. An app that has a operation blocked by App Ops still retains its permission, and calls to checkPermission() on PackageManager will happily report that the app holds the permission.
What Can the User Control?
The following list represents the different operation categories seen in App Ops so far:
location
read calendar
modify calendar
read contacts
read call log
modify contacts
modify call log
read SMS
write SMS
receive SMS
receive MMS
send SMS
receive WAP push
vibrate
modify settings
access notifications
call phone
record audio
camera
draw on top
post notification
What Happens When An App Tries to Perform a Blocked Operation?
That depends on what the operation is and the behavior of App Ops on the device itself.
Not all devices appear to implement App Ops in the same way. There are reports of some operations (e.g., accessing location) working on some devices despite being blocked in the App Ops activity.
For devices that do actually block the operation, what happens to the calling app varies by operation. For example, here are the results for some operations performed on a Nexus 7 (2013):
location: no location data supplied, but isProviderEnabled() reports true
read calendar: empty query results
read contacts: empty query results
record audio: no effect (MediaRecorder still records audio)
camera –> getNumberOfCameras() returns the proper data, getCameraInfo() returns the proper data, but open() crashes with generic RuntimeException
post notification –> notification not displayed
How Do We Detect That We Are Blocked?
There is no known way for an app to directly detect that one or more operations are being blocked by App Ops. Hopefully, we will find one, and hopefully, by the time App Ops is officially available, we will have some way to determine what is and is not possible.
In the absence of direct detection, we will need to work out indirect mechanisms (e.g., a RuntimeException on your open() call on Camera may mean that you are blocked by App Ops) and hope for the best.
What Happens As Our App Evolves?
Preliminary evidence suggests that an in-place upgrade of an app does not affect the blocks established by App Ops. However, uninstalling and re-installing the app removes any App Ops blocks placed on the original installation.
How Do I Test My App?
First, you need an Android 4.3 environment. App Ops is available in the emulator, so if you normally test your app on the emulator, you can do so for App Ops behavior as well.
To bring up App Ops, either use one of the App Ops launching apps on the Play Store, or run the following command at a command line on your development machine (with the device or emulator attached):
adb shell am start -a android.settings.APP_OPS_SETTINGS
Note that this command assumes that the adb utility is in your PATH. You can find adb in the platform-tools/ directory of your SDK installation.
App Ops initially shows a ViewPager with four categories of operations: location, personal, messaging, and device. Apps that request permissions related to those operations will appear in lists in their respective page. Tapping on an app will show some of the possible blockable operations, with Switch widgets to allow you to allow (“ON”) or deny (“OFF”) those operations.
Note that not all operations will appear right away necessarily. You may need to run your app and actually perform the operation once before it will appear in the list.
Am I Screwed?
Well, that’s difficult to answer.
Some of these should not be a big deal, insofar as there are other existing ways that the operations can be blocked:
location: user can disable from Settings
camera: device admins can disable
post notification: user can disable from Settings
Similarly, some of these represent conditional capabilities that cannot be filtered by <uses-feature> or the equivalent, and so the results we get are within reason:
read calendar: user may not have any calendars
read contacts: user may not have any contacts
read call log: user may not have any calls (e.g., tablet)
vibrate: device may not have a vibration motor
For those in particular, your app should already be in position to cope with being unable to perform these operations, and so the fact that they happen to be blocked by App Ops should not be significantly different, other than perhaps in how the blockage becomes apparent to you.
Others you might specifically be allowing the device to lack some capability, via android:required="false" on your <uses-feature> element:
location: device may not have location providers
read SMS: device may not have telephony
write SMS: device may not have telephony
receive SMS: device may not have telephony
receive MMS: device may not have telephony
send SMS: device may not have telephony
call phone: device may not have telephony
record audio: device may not have a microphone
camera: device may not have a camera
Here again, if you are allowing the app to run on devices that lack some capability (e.g., telephony), you already have logic in your app to deal with such devices.
This rolls back to the question of detecting whether you are blocked by App Ops. With that, developers can blend in App Ops detection logic with existing detection logic (e.g., hasSystemFeature() on PackageManager to handle android:required="false" on <uses-feature>).
