3 ms·

Android as a framework is designed in such a way that most of the times you wish to access a feature of the device requires a permission you should be using com

Android as a framework is designed in such a way that most of the times you wish to access a feature of the device requires a permission you should be using components that can enforce a security check with the PackageManager or can handle the SecurityExceptions generated from not having a permission. Poorly architect-ed apps will have an issue with this, but those apps already have problems.

sp332 13y ago
Handling an exception is one thing. Designing your app to work gracefully with random permissions denied sounds like a combinatorial explosion of testing and UI design.
- king_jester 13y ago
  It's not very bad on Android. The framework really pushes for a kind of plug-in like architecture where you abstract your core components into things like Services, so thinking about those core features up front goes a long way to creating a common point to handle permission checks. If all else fails, an app could simply extend Application and check permissions at runtime.
veeti 13y ago
No. The Android API has always given the guarantee (and it still does) that your application's permissions will always be there. They can't be revoked during runtime. If it's in the manifest, it's perfectly fine to assume that you have it. No piece of documentation or sample code has ever encouraged a pattern of "checking if your app has permission X or Y" because it's a total waste of time. Likewise, none of the built-in Android apps or any of the open-source apps from Google developers I've seen do that. There is no point to doing so. In fact, it's actually bad practice because you're adding a bunch of error checking code for an error condition that's never going to happen. If you're getting a SecurityException for an action that you've explicitly requested the permission for, you're running on a broken API and it's not your responsibility to handle that. The framework does include methods for checking permissions, but they are generally meant for things like inter-process communication and library code. There's no need to use them for ordinary applications you are building yourself. And nobody does that, rightfully so.
- king_jester 13y ago
  I'm not suggesting that apps do this or even if it is a good idea to have this level of security checks in code. Rather, the Android framework encourages decentralized pieces of code that revolve accessing various capabilities of the API. The kind of paradigms in Android could be considered to be already a bit helpful in that they promote certain kinds of application architecture that may be more easily adapted to doing such security checks. Ultimately it is a matter of time before something like this does make its way into the core features of Android. It is worth thinking about how Android is both deficient and helpful with its design philosophy regarding that eventuality.

sp332 13y ago

Handling an exception is one thing. Designing your app to work gracefully with random permissions denied sounds like a combinatorial explosion of testing and UI design.

king_jester 13y ago
It's not very bad on Android. The framework really pushes for a kind of plug-in like architecture where you abstract your core components into things like Services, so thinking about those core features up front goes a long way to creating a common point to handle permission checks. If all else fails, an app could simply extend Application and check permissions at runtime.

veeti 13y ago

No. The Android API has always given the guarantee (and it still does) that your application's permissions will always be there. They can't be revoked during runtime. If it's in the manifest, it's perfectly fine to assume that you have it. No piece of documentation or sample code has ever encouraged a pattern of "checking if your app has permission X or Y" because it's a total waste of time. Likewise, none of the built-in Android apps or any of the open-source apps from Google developers I've seen do that. There is no point to doing so. In fact, it's actually bad practice because you're adding a bunch of error checking code for an error condition that's never going to happen. If you're getting a SecurityException for an action that you've explicitly requested the permission for, you're running on a broken API and it's not your responsibility to handle that. The framework does include methods for checking permissions, but they are generally meant for things like inter-process communication and library code. There's no need to use them for ordinary applications you are building yourself. And nobody does that, rightfully so.

king_jester 13y ago
I'm not suggesting that apps do this or even if it is a good idea to have this level of security checks in code. Rather, the Android framework encourages decentralized pieces of code that revolve accessing various capabilities of the API. The kind of paradigms in Android could be considered to be already a bit helpful in that they promote certain kinds of application architecture that may be more easily adapted to doing such security checks. Ultimately it is a matter of time before something like this does make its way into the core features of Android. It is worth thinking about how Android is both deficient and helpful with its design philosophy regarding that eventuality.