3

I pushed a beta version to Google Play that accidentally added more permissions compared to the version that's current in production.

Before pushing the final new version to production via a staged rollout, I removed those permissions, but despite that, users are still complaining about the new permissions when they received the update on the Play Store.

Why are the new permissions still visible? I removed the APK from the beta channel, neither of the production APKs (both the old one, and the new one in staged rollout) have the new permissions. I even see those new permissions in the Play Store listing.

EboMike
  • 76,846
  • 14
  • 164
  • 167
  • 3
    You're really sure that the permission are gone, and are not being added there by a library that you are using? Put a copy of your APK up on Dropbox or some other private Web host that knows about the APK MIME type, and try installing it from there. If you still see the permissions, they're a part of the APK file, and you'll need to look at manifest merger reports to try to determine why. If the permissions are not there, then the permissions are definitely not in the APK file, and the Play Store presumably is the source of the difficultly. – CommonsWare Jun 02 '15 at 16:56
  • Thanks Mark, I forgot that libraries can add permissions - I just looked at the main AndroidManifest.xml. Are there tools that can extract permissions from an APK? – EboMike Jun 02 '15 at 16:57
  • 1
    **`aapt dump badging`** should do that. – CommonsWare Jun 02 '15 at 16:59

1 Answers1

2

By using a newer SDK but not changing the targetSdkVersion of all my imported modules, I automatically inherited some implicit permissions.

For one, there is one library with a targetSdkVersion of 3 - that will automatically add READ_PHONE_STATE, as already documented in this answer, and the official docs.

This can be easily seen by looking at the manifest merger log in build/output/logs/manifest-merger-release-report.txt:

android:uses-permission#android.permission.READ_PHONE_STATE
IMPLIED from AndroidManifest.xml:2:1 reason: com.foo.library has a targetSdkVersion < 4

The other problem was having READ_CONTACTS set, but at least one library used both minSdkVersion and targetSdkVersion < 15. That automatically added READ_CALL_LOG. See the documentation about this. Curiously enough I didn't see a mention of that in the merger log, but I may have missed it.

The final APK permissions can be checked with aapt:

aapt dump badging build\outputs\apk\foo-release.apk

That prints out the list of permissions.

Full credit to CommonsWare for leading me to this. Thanks Mark!

Community
  • 1
  • 1
EboMike
  • 76,846
  • 14
  • 164
  • 167