On Mon, Aug 30, 2010 at 1:37 PM, Brad Gies <rbg...@gmail.com> wrote: > > I've been following the "Is there a way to request permissions from a user > as you need them?" thread with a lot of interest, but even if someone is > convinced to make the Android permissions system better, it doesn't do > anything for right now. > > So, I thought I'd start a thread for coming up with alternative ways to > reduce the permissions your app needs. > > My app absolutely needs internet access (it's useless without it), and it > uses Google Maps extensively (it's the main activity), so I have the > following : > > <uses-permission > android:name="android.permission.ACCESS_NETWORK_STATE"></uses-permission> > > <uses-permission > android:name="android.permission.ACCESS_COARSE_LOCATION"></uses-permission> > <uses-permission > android:name="android.permission.ACCESS_FINE_LOCATION"></uses-permission> > <uses-permission > android:name="android.permission.INTERNET"></uses-permission> > > I want to be able to know if I have a network connection, hence the > ACCESS_NETWORK_STATE. I also try to use GPS hence the > "ACCESS_FINE_LOCATION", and if GPS is not available I try to find the user's > location using something else hence "ACCESS_COARSE_LOCATION" and of couse > the "INTERNET" permission. I also use the "My Location' feature of Google > Maps. > > So... the question is : Is there a robust way to use Google Maps, and be > able to send requests to my server without all those permissions (in a user > friendly way) ? >
If you use maps with locations extensively, then internet and location permissions are *fundamental* to your app and I would argue that it would be entirely wrong for these to not be presented to the user when it is installed. Why are you thinking these should not be presented? From what you say, it sounds like this is what your app does. It doesn't seem to me that you should need a permission just to find out if there is a network connection. To be honestly, I am not that familiar with the networking parts of the system, so I don't know for sure how to address this... though from glancing at the API, it seems like the ConnectivityManager.CONNECTIVITY_ACTION broadcast is a sticky broadcast so you can retrieve the last broadcast state without any permission? Also this permission is a normal permission, not dangerous, so it won't be shown to the user unless they explicitly want to see it. > I'm also experimenting with C2DM, so I have the following: > > <permission android:name="com.bgies.hottonight.permission.C2D_MESSAGE" > android:protectionLevel="signature" /> > <uses-permission android:name="com.bgies.hottonight.permission.C2D_MESSAGE" > /> > <uses-permission android:name="com.google.android.c2dm.permission.RECEIVE" > /> > <uses-permission > android:name="android.permission.READ_SYNC_SETTINGS"></uses-permission> > If I want to use C2DM, it seems I am stuck with those... Anybody know > signature-only permissions are never shown to the user, so they are not of concern here. (And also since you are declaring the permission, if it was shown to the user, you could have it say whatever you wanted... such as "makes app work better than competitor X". Though actually, since the platform doesn't know about the perm until the app is installed, it just won't be displayed anyway.) The C2DM receiver permission... makes me unhappy. First because the permission text that gets displayed is utterly ridiculous. Second because I really question the value of this permission at all. At the very least, for the next release I hope to make this a normal permission so it isn't shown to the user unless they explicitly display it. I also really want to reword the text to make it less crazy. And as far as READ_SYNC_SETTINGS... why do you need that? I don't see it mentioned anywhere in the C2DM documentation. (Though this also is not an area I am super knowledgeable about.) > > Now... I also want to use the camera (optional) and vibrate (optional but > most users will want it) so I have to add : > <uses-permission android:name="android.permission.CAMERA" /> > <uses-permission android:name="android.permission.VIBRATE" /> > Here again, vibrate is a normal permission, so it will not be seen unless the user wants to dig into it. (And seriously, "makes your phone vibrate." I think the vast majority of users, if they *do* explicitly go to see it, will have no trouble figuring out that they are okay with it.) As for the camera permission, the only option I can offer is if you just need them to take a picture then you can start the intent to have the camera app take a picture and return it to you. However if you need to drive the camera yourself, you'll need to take the permission. > Total 10 lines of permissions in the manifest.... AND this is AFTER > removing 4 other permissions that a small percentage of users would have > found very handy, AND not adding a few other features because of the > permissions bloat they would have added > > CALL_PHONE > READ_CONTACTS > GET_ACCOUNTS > SEND_SMS > > So... given all of this, is there a way to reduce the permissions I need > any more than I already have? AND why do I need a total of 8 permissions > just to ask my server for the data they want, and try to keep them current > using C2DM? Surely those permissions could be reduced somehow. > Well, first of all -- the important thing is the permissions the user sees, not the ones you declare in your manifest. So I think you need to be looking this as what you see in the app details screen when you look at your app. That eliminates all signature-only permissions; one can also make an argument that it makes normal permissions basically not interesting. Also the permissions shown to the user have logical grouping, so some of these you can really consider to be one. In particular, the two location permissions when presented to the user really come out as "the app will be able to find out where I am." (The same is true for the internet permission and C2DM permission since they are both under the "Network communication" group... except C2DM has that ghod-awful text turning what gets shown there into a mess, but that definitely is in sight to be fixed.) And then looking at the other permissions you have removed -- from the perspective of the overall system/platform, if the app has dropped that kind of access, this is actually a positive. Whether you show the user the SEND_SMS permission when they install the app, or some time later when they are inclined to accept it, having apps be able to send SMSes from the device whenever and wherever they want... well, the less apps that can do that, the better we are. So if an app can avoid ever getting that permission, in favor of using some perhaps not quite as nice UX as invoking the SMS app to have the user send an SMS for them, then from the perspective of the overall platform I think this is a good thing. Anyway, looking at what you have, especially with the 4 you have dropped, the permission set of the app doesn't seem all that horrible. Do you actually have users complaining about them? If so, what are they objecting to? -- Dianne Hackborn Android framework engineer hack...@android.com Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to android-developers@googlegroups.com To unsubscribe from this group, send email to android-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
