19

Is there any way for an Android application to declare requested permissions as optional?

I.e. I want to write an app that requests a set of permissions, e.g. one of them being access to the user contacts. Now the application can work and do useful things without this access permission, but it can do more if it is granted.

Is there a way for and app to say "I want permission X, but you can refuse it in which case I'm happy to run with reduced functionality?"

Carsten
  • 4,204
  • 4
  • 32
  • 49

3 Answers3

9

I don't believe so, since permissions are set in the manifest and accepted by the user upon installing the .apk. You could build a light version of the application with reduced permissions and limited feature set and offer it as an alternative.

RawwrBag
  • 602
  • 5
  • 12
  • 1
    However, this answer can help: http://stackoverflow.com/questions/9299993/optional-permissions-so-an-app-can-show-on-all-devices-and-enable-optional-featu – Ilya Kogan Jun 26 '13 at 06:35
  • also check this http://www.londatiga.net/it/programming/android/solution-to-make-an-android-app-visible-to-all-devices-in-google-play-when-using-specific-feature-2/ for further info on how to use feature and permission – Lorensius W. L. T Feb 12 '14 at 00:15
  • I think this answer is no longer valid: https://developer.android.com/training/permissions/requesting.html – bvdb Nov 05 '17 at 16:09
5

It is not supported and not under development as of now. Star issue 6266 on Android bug tracker if you would like to see it implemented.

Ref: http://code.google.com/p/android/issues/detail?id=6266

dragon
  • 1,747
  • 15
  • 18
  • I note that issue 6266 has been closed as obsolete. It is not clear to me why, given that the issue is as pertinent as ever, as far as I know. – Max Murphy Nov 16 '15 at 09:27
5

It is possible to grant privileges to an already installed application by not requesting the permissions in the "main" app and by creating another application ("stub") using the same android:sharedUserId, which requests the features. You can then check if the permission-stub application has been installed by checking if

context.checkCallingOrSelfPermission(permission) == PackageManager.PERMISSION_GRANTED

evaluates to true (with context as a valid context and permission as one of the permission strings). If it is true, your stub app has been installed and you may unlock features requireing the permissions granted. If it is false, you just fall back to the basic features.

When designing your app that way you can easily re-introduce the optional permissions into the main apk without having to change any code, for example if you distribute multiple versions.

You can now query privileges from the user by triggering the installation of (one of) your stub application(s). So if your privileges are required after some user input in an activity, launch the apk to pop up if the privilege has not been granted (of course you may put an explanatory activity in front of it), and execute the feature when coming back from the package manager or when the permission was granted before. You may as well put the option to enable or disable permissions somewhere in your preferences or a firstrun dialog.

For lazy people (like me) a short summary on how to bring the package installer up: Create an Intent using Intent.ACTION_VIEW for a file://-URI using the Type "application/vnd.android.package-archive". Assets and Ressources do not work directly, you could for example bundle it as asset and copy it to the cache folder or similar.

Warning: This answer might not comply with the Google Play ToS, as this method has some uninstallation issues (might leak apps, see below) expecially when uninstalling via third-party mechanisms (like Google Play, as the user does not see the helper apps using these methods) and as optional privileges cannot get displayed in the play store afaik.

For the uninstallation issues I'd recommend to use names like "MyApp: XXX permissions", given the application name is "MyApp", so the user can easily remove them all in alphabetically listed lists. Alternately, if you can live with the stub applications getting more complex, use ACTION_PACKAGE_REMOVED as mentioned here.

Community
  • 1
  • 1
dst
  • 3,307
  • 1
  • 20
  • 27
  • nice hint! here a demo of it in action https://www.youtube.com/watch?v=u7bDg8EMEFM - code here https://github.com/ligi/AJShA – ligi Sep 02 '14 at 22:52
  • Related question about the UI for this "plug-in" model: [Would users understand splitting an Android app's functionality by permission?](https://ux.stackexchange.com/q/76183/40840) – Damian Yerrick Jan 04 '16 at 17:15
  • @tepples I don't think the user would actually understand that it is a separate app (unless the user understands the whole thing), but as I said in the answer this method is thus unlikely to be accepted in app stores. Also note that Android 6 does support some form of optional permissions, this answer is quite old. I, however, have not yet used enough it - so I can't provide a good "new" answer yet :) – dst Jan 09 '16 at 00:25