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 tocheckPermission()onPackageManagerwill 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, butisProviderEnabled()reportstrue
- read calendar: empty query results
- read contacts: empty query results
- record audio: no effect (MediaRecorderstill records audio)
- camera:getNumberOfCameras()returns the proper data,getCameraInfo()returns the proper data, butopen()crashes with genericRuntimeException
- post notification: notification not displayed
{UPDATE 2013-07-29} A Nexus 4, with the OTA update to Android 4.3, shows the same results, plus:
- vibration: requests to vibrate the device are ignored
{UPDATE 2013-07-31} A Galaxy Nexus, with the OTA update to Android 4.3, shows the same results as does the Nexus 4.
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., aRuntimeExceptionon youropen()call onCameramay 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 yourPATH. You can findadbin theplatform-tools/directory of your SDK installation.
App Ops initially shows aViewPagerwith 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, withSwitchwidgets 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, viaandroid: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()onPackageManagerto handleandroid:required="false"on<uses-feature>).
扫一扫
3595
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
