4 ms·

>(a) applications behaved well in the absence of permissions As an app developer, I sympathize, but if you've got a reasonably complex app that requires 8 perm

>(a) applications behaved well in the absence of permissions As an app developer, I sympathize, but if you've got a reasonably complex app that requires 8 permissions, that's 255 permutations of code paths that you need to test (that you don't need to test right now) to make sure your app performs correctly. And that's not a reasonable request to make of an app developer. Aside from that, some apps rely on, e.g., INTERNET permission to do their monetization. Aside: It's majorly not cool to "block ads" just because you don't like ads; pay for the ad-free version if you don't want to see ads. It's cheap in almost all cases. It's HARD to make money as an app developer; it may not be technically stealing to block ads, but it's ethically indistinguishable. That said, as an app developer I would love to have the ability to request OPTIONAL permissions, or even better, request them at runtime (basically, let the OS bring up a "Do you want to let this app have PERMISSION_A, PERMISSION_B, and PERMISSION_C, to enable the following feature: FEATURE DESCRIPTION"). Again, though, I'd want to request a SUITE of permissions at once, so I don't have to worry about testing with random user-configured permutations of permissions. There are some features I'd love to add, but they wouldn't be needed by everyone -- and I wouldn't want to scare people away from downloading my app, so I don't add them at all. But I absolutely would still want guaranteed permissions: If my app needs Internet to make money, then I don't want someone to be able to use it if they're blocking Internet for the app, or otherwise blocking ads on the phone. You don't want the ads? You're free to use another app, or pay to turn the ads off.

jasomill 13y ago
As an app developer, I sympathize, but if you've got a reasonably complex app that requires 8 permissions, that's 255 permutations of code paths that you need to test (that you don't need to test right now) to make sure your app performs correctly. And that's not a reasonable request to make of an app developer. Not really; this depends on how the OS developer implements denying various permissions. For example, your app already has to handle empty address books, location services reporting valid, fixed locations, and SMS messages not arriving; it also can't assume network and messaging services are available, even in the absence of permission problems. But I absolutely would still want guaranteed permissions: If my app needs Internet to make money, then I don't want someone to be able to use it if they're blocking Internet for the app How do you currently handle limited, filtered, or no Internet access for reasons other than lack of permission grants? Why can't you handle permission-based Internet blocking in the same way?
- SomeCallMeTim 13y ago
  On Android, if a permission isn't granted, then when you try to use it, it throws an error in the app. If you're not expecting that throw, the app will crash. It's not the kind of "throw" that Java forces you to handle; it's more like a null pointer exception, and no, I don't put blanket try/catch blocks on every block of code. That would mean writing code that would almost never have coverage, which is a poor practice itself. If the OS handles it transparently, then sure, it could work. But as I understand things, that's why the CyanogenMod "feature" of selective permission disabling fails: If I ask whether the Internet has a valid signal, and it unexpectedly throws an error, then my app will either crash or behave in an untested way (depending on whether I'm catching top-level errors and continuing to run anyway). I don't know how the 4.3 feature handles it. I don't want users to have the ability to disable Internet, though; not if I'm writing an ad-supported app. I don't want to kill the app on devices that simply never connect to the Internet either, so I'd prefer if the OS guaranteed that, IF there's an Internet connection, it will give me full access to it.
  - rquirk 13y ago
    Reading from the SD card permissions at least was more subtle. IIRC the File you got back was simply null, no Exception or anything at all. This isn't what you would expect from the API call or documentation. Perhaps that's the hardest part to test about the Cyanogen-style permissions disabling: that there's no uniform way Android handles a missing permission. Sometimes the API will throw an exception, while other times it returns a null Object.
MaulingMonkey 13y ago
> As an app developer, I sympathize, but if you've got a reasonably complex app that requires 8 permissions, that's 255 permutations of code paths that you need to test (that you don't need to test right now) to make sure your app performs correctly. And that's not a reasonable request to make of an app developer. Your average app already has significantly more than 255 permutations of code paths. While testing every permutation with e.g. automated tests is a great way to try and ensure full coverage, simply handling each once will often be sufficient: a significant number of these permissions, properly handled, will be orthogonal to the others. Many disabled permissions aren't adding fundamental complexity: What's the functional difference to your code when it reads 0 contacts from my address book because I don't have any, vs when it reads 0 contacts from my address book because I disabled the permission? You already need to handle the former.
- SomeCallMeTim 13y ago
  The way permissions work, the difference between reading 0 contacts where the contact list is empty, and reading them with a disabled permission, is that the latter throws an exception. You're right in that it would be possible to have the OS report "0 contacts" instead of throwing an error, and THAT case should be handled. In fact, I'd love to have the ability to block reading of contacts from all apps except ones I explicitly allow. It's the more basic "INTERNET" permission that is core to monetizing apps that I take umbrage with blocking; if someone is using my contacts somehow to monetize their app, that's not cool, and I absolutely wouldn't want to use an app that did that.
  - MaulingMonkey 13y ago
    > You're right in that it would be possible to have the OS report "0 contacts" instead of throwing an error, and THAT case should be handled. ...or to write your own wrapper which does the same by handling the exception, and to then exclusively use that wrapper in your client code.
    - SomeCallMeTim 13y ago
      It's not just one case of "query for contacts" I'm talking about. One permission is trivial to test for. But if we're going with my example of eight permissions, then you probably have 24+ calls in various places in your code, some of which relying on others. Catching the error isn't even half the battle, either. If you want the app to "work," you need to explicitly test the full set of permissions any particular block of code might need prior to enabling aspects of your UI that require them, or your app is going to behave badly. At best, your proposed solution would prevent the app from crashing, though it could still get into a bad state -- a non-modal dialog waiting for a particular result could never be closed, for example, because of an unexpected throw that skipped over the proper cleanup code. Yes, that code SHOULD be in a finally{} clause, but what if you missed something? I'm an awesome developer in a lot of ways, probably even a 10x+ developer, but I don't consider myself perfect. Do you? Have you developed apps for Android as an indie developer? Or for iOS? How much extra time would you want to spend to cover corner cases like this, instead of adding features that might actually improve your revenues or ratings? How likely is it that you'd successfully handle all 255 extra permutations with no real testing? And don't think unit tests would solve the problem: You'd really need full functional and UI tests, probably with a human to really be sure that you're covered. Some apps really don't work without certain permissions (say an Internet chat app with no INTERNET permission), so be sure you have reasonable error messages that explain to the user that the app can't work if you don't give it the right permission. And word the message so that your average non-techie will understand it, or be prepared for lots of negative ratings with "app doesn't work! uninstalled!" comments. No, making it easy for people to kill permissions on an app is the wrong answer. Giving developers the ability to optionally query sets of permissions reduces the complexity from exponential to constant, and allows for optional features to exist in an app.

jasomill 13y ago

As an app developer, I sympathize, but if you've got a reasonably complex app that requires 8 permissions, that's 255 permutations of code paths that you need to test (that you don't need to test right now) to make sure your app performs correctly. And that's not a reasonable request to make of an app developer. Not really; this depends on how the OS developer implements denying various permissions. For example, your app already has to handle empty address books, location services reporting valid, fixed locations, and SMS messages not arriving; it also can't assume network and messaging services are available, even in the absence of permission problems. But I absolutely would still want guaranteed permissions: If my app needs Internet to make money, then I don't want someone to be able to use it if they're blocking Internet for the app How do you currently handle limited, filtered, or no Internet access for reasons other than lack of permission grants? Why can't you handle permission-based Internet blocking in the same way?

SomeCallMeTim 13y ago
On Android, if a permission isn't granted, then when you try to use it, it throws an error in the app. If you're not expecting that throw, the app will crash. It's not the kind of "throw" that Java forces you to handle; it's more like a null pointer exception, and no, I don't put blanket try/catch blocks on every block of code. That would mean writing code that would almost never have coverage, which is a poor practice itself. If the OS handles it transparently, then sure, it could work. But as I understand things, that's why the CyanogenMod "feature" of selective permission disabling fails: If I ask whether the Internet has a valid signal, and it unexpectedly throws an error, then my app will either crash or behave in an untested way (depending on whether I'm catching top-level errors and continuing to run anyway). I don't know how the 4.3 feature handles it. I don't want users to have the ability to disable Internet, though; not if I'm writing an ad-supported app. I don't want to kill the app on devices that simply never connect to the Internet either, so I'd prefer if the OS guaranteed that, IF there's an Internet connection, it will give me full access to it.
- rquirk 13y ago
  Reading from the SD card permissions at least was more subtle. IIRC the File you got back was simply null, no Exception or anything at all. This isn't what you would expect from the API call or documentation. Perhaps that's the hardest part to test about the Cyanogen-style permissions disabling: that there's no uniform way Android handles a missing permission. Sometimes the API will throw an exception, while other times it returns a null Object.

MaulingMonkey 13y ago

> As an app developer, I sympathize, but if you've got a reasonably complex app that requires 8 permissions, that's 255 permutations of code paths that you need to test (that you don't need to test right now) to make sure your app performs correctly. And that's not a reasonable request to make of an app developer. Your average app already has significantly more than 255 permutations of code paths. While testing every permutation with e.g. automated tests is a great way to try and ensure full coverage, simply handling each once will often be sufficient: a significant number of these permissions, properly handled, will be orthogonal to the others. Many disabled permissions aren't adding fundamental complexity: What's the functional difference to your code when it reads 0 contacts from my address book because I don't have any, vs when it reads 0 contacts from my address book because I disabled the permission? You already need to handle the former.

SomeCallMeTim 13y ago
The way permissions work, the difference between reading 0 contacts where the contact list is empty, and reading them with a disabled permission, is that the latter throws an exception. You're right in that it would be possible to have the OS report "0 contacts" instead of throwing an error, and THAT case should be handled. In fact, I'd love to have the ability to block reading of contacts from all apps except ones I explicitly allow. It's the more basic "INTERNET" permission that is core to monetizing apps that I take umbrage with blocking; if someone is using my contacts somehow to monetize their app, that's not cool, and I absolutely wouldn't want to use an app that did that.
- MaulingMonkey 13y ago
  > You're right in that it would be possible to have the OS report "0 contacts" instead of throwing an error, and THAT case should be handled. ...or to write your own wrapper which does the same by handling the exception, and to then exclusively use that wrapper in your client code.
  - SomeCallMeTim 13y ago
    It's not just one case of "query for contacts" I'm talking about. One permission is trivial to test for. But if we're going with my example of eight permissions, then you probably have 24+ calls in various places in your code, some of which relying on others. Catching the error isn't even half the battle, either. If you want the app to "work," you need to explicitly test the full set of permissions any particular block of code might need prior to enabling aspects of your UI that require them, or your app is going to behave badly. At best, your proposed solution would prevent the app from crashing, though it could still get into a bad state -- a non-modal dialog waiting for a particular result could never be closed, for example, because of an unexpected throw that skipped over the proper cleanup code. Yes, that code SHOULD be in a finally{} clause, but what if you missed something? I'm an awesome developer in a lot of ways, probably even a 10x+ developer, but I don't consider myself perfect. Do you? Have you developed apps for Android as an indie developer? Or for iOS? How much extra time would you want to spend to cover corner cases like this, instead of adding features that might actually improve your revenues or ratings? How likely is it that you'd successfully handle all 255 extra permutations with no real testing? And don't think unit tests would solve the problem: You'd really need full functional and UI tests, probably with a human to really be sure that you're covered. Some apps really don't work without certain permissions (say an Internet chat app with no INTERNET permission), so be sure you have reasonable error messages that explain to the user that the app can't work if you don't give it the right permission. And word the message so that your average non-techie will understand it, or be prepared for lots of negative ratings with "app doesn't work! uninstalled!" comments. No, making it easy for people to kill permissions on an app is the wrong answer. Giving developers the ability to optionally query sets of permissions reduces the complexity from exponential to constant, and allows for optional features to exist in an app.