9

My Gradle project contains 4 libraries. In recent builds of my app I found that Android Studio is silently adding "read call log" and "write call log" permissions to the manifest. In the build folder is a "final" manifest that is packaged into the apk and it contains these lines:

<android:uses-permission android:name="android.permission.READ_CALL_LOG" />
<android:uses-permission android:name="android.permission.WRITE_CALL_LOG" />

Is there a way to either disable this weird behavior completely or enable some logging to know where this comes from? I don't like when software tries to be smarter than me.

tgf
  • 2,977
  • 2
  • 18
  • 29
Grishka
  • 2,465
  • 1
  • 20
  • 38

2 Answers2

16

You can use "Merge conflict markers" to remove this tag from your Android Manifest.

Then you can setup on your AndroidManifest the next code and they will be removed:

<uses-permission android:name="android.permission.READ_CALL_LOG" 
        tools:node="remove"/>
<uses-permission android:name="android.permission.WRITE_CALL_LOG" 
        tools:node="remove"/>
Jc Miñarro
  • 1,391
  • 10
  • 18
  • 1
    I confirm that adding this in my own manifest, just after my own permissions, worked to remove this useless permission from the final .apk (note that I had to remove the first `android:` prefix) : `` – Sébastien Sep 28 '15 at 09:07
  • This should be the accepted answer, since the structure of the output files is more AS dependent the script can fail easily. – danypata Nov 03 '17 at 13:17
0

The manifests are merged, so this is not supported yet.

You can archieve this by adding a new gradle task to your build.gradle, and attaching it as a dependence of processDebugResources and processReleaseResources gradle tasks. 

task('removeExtraPermissionsDebug') << {
    //Input the correct manifest file (could be under 'full' folder).
    def manifestFile = file("build/intermediates/manifests/full/debug/AndroidManifest.xml")
    def patternPermissions = Pattern.compile(".+(android\\.permission\\.ACCESS_NETWORK_STATE|android\\.permission\\.WAKE_LOCK).+")
    def manifestText = manifestFile.getText()
    def matcherPermissions = patternPermissions.matcher(manifestText)
    def newManifestText = matcherPermissions.replaceAll("")
    manifestFile.write(newManifestText)
}

tasks.whenTaskAdded { task ->
    if(task.name == 'processDebugResources'){
        task.dependsOn 'removeExtraPermissionsDebug'
    }
}

Notes:
If you have custom flavours and build types, take into account the names of the tasks you need to attach to: process{Flavour}{BuildType}Resources.
You may need to replicate the task to delete permissions also when generating the release.

Gero
  • 1,842
  • 25
  • 45
  • This would definitely work but I'd like a more nice solution. Here http://tools.android.com/tech-docs/new-build-system/user-guide/manifest-merger they say about logging and log format but nothing on how to turn these logs on... Any ideas? – Grishka Nov 06 '14 at 23:19
  • I've tried my code and it works. Logging is no useful for your task, as you can see on (http://tools.android.com/tech-docs/new-build-system/user-guide/manifest-merger#TOC-Merging-Policies), Node Type `uses-permission` has a Merging Policy of `merge` by `android:name` attribute. Meaning that all `uses-permission` are merged no matter what using `android:name` to avoid repeated ones. – Gero Nov 06 '14 at 23:28
  • No, I mean that these two uses-permission nodes are added automatically by the manifest merger during build process. They do not exist in any of libraries' manifests (I double checked) but they do exist in the merged one. Logging will be useful to see what causes the manifest merger to add these nodes. – Grishka Nov 06 '14 at 23:34
  • I understand, in that case, it could be related to this... http://developer.android.com/reference/android/Manifest.permission.html#WRITE_CALL_LOG `Note: If your app uses the READ_CONTACTS permission and both your minSdkVersion and targetSdkVersion values are set to 15 or lower, the system implicitly grants your app this permission. If you don't need this permission, be sure your targetSdkVersion is 16 or higher` – Gero Nov 06 '14 at 23:39
  • Sorry @Grishka, i would use the gradle task in your place. But as a last resource, if you are willing to try more workarounds, without knowing if this would work, you can try adding `manifestmerger.enabled=false` to your properties file and take care of manifest on your own (?). – Gero Nov 07 '14 at 00:11