一次Android权限删除经历

**

1.事发经过

** 近期google play发布了新的政策，其中一部分是限制权限使用，只允许满足条件的使用场景才能申请权限，小编所在的项目被检测出使用了RECEIVE_SMS权限，但是从app下的Androidmanifest文件中并未发现有该权限的注册，所以该权限是哪里来的呢？

2.初步定位

首先使用android studio查看了打包出来的apk中的Androidmanifest文件，发现其中确实存在RECEIVE_SMS权限，也就是说打包到apk中的Androidmanifest文件并不是app下的该文件，从android开发者官网中合并多个manifest文件的文档来看，实际上打包到apk中的manifest文件是由多个menifest文件合并而来的，其合并顺序如下：

优先级由低到高分别是： 第三方库中 < app模块 < app模块的源集 当合并发生冲突的时候，可以使用合并规则标记来处理冲突，所以我这里使用了tools:node=”remove”来处理移除RECEIVE_SMS权限，重新打包查看结果发现，仍然存在该权限，也就是说该标记失效了吗？再思考一下，是否有记录合并过程的文件呢？答案是有的，如下： 合并规则结束生成的android manifest文件：app/build/intermediates/manifests/full/googleplay/debug/AndroidManifest.xml 合并操作记录文件： app/build/outputs/logs/manifest-merger-googleplay-debug-report.txt 上述的googleplay是自定义的productFlavors，如果未定义就是app。 查看AndroidManifest.xml发现确实存在RECEIVE_SMS权限，但是查看manifest-merger-googleplay-debug-report.txt却找不到该权限的合并记录；也就是说，在正常的合并流程中，并没有RECEIVE_SMS权限的写入，会不会有人破坏了正常的合并流程呢？没办法，需要追踪到具体是哪一个第三方库引入了该权限，仔细对比了下apk中的Androidmenifest文件和app下的该文件，发现每次都是在该文件末尾多出了RECEIVE_SMS和其他一些东西，仔细一看发现是mobsdk相关的，于是剔除了该库，再编译发现还是存在该权限。。仔细想下，有点不对，因为要破坏manifest文件的合并，那么普通的第三方库是不行的，至少需要第三方gradle插件，于是移除了“com.mob.sdk”插件，再打包发现确实没有RECEIVE_SMS了

3.原理解析

到此已经找到了问题的制造者，接下来就是看下他是怎么实现的，面向google编程，搜索com.mob.sdk source code 找到maven仓库，可以找到其实现核心如下：

project.afterEvaluate {
			def android = project.extensions.getByName("android")
			if (globalVariants.autoConfig == null) {
				globalVariants.autoConfig = true
			}
			if (globalVariants.autoConfig) {
				if (android != null) {
					configShareSDKXML(android)

					def variants = null
					boolean appModel = false
					try {
						variants = android.applicationVariants
						appModel = true
					} catch (Throwable t) {
						try {
							variants = android.libraryVariants
						} catch (Throwable tt) {}
					}
					if (variants != null) {
						variants.all { variant ->
							variant.outputs.each { output ->
								output.processManifest.doLast {
									configManifest(output, appModel, variant)
								}
							}
						}
					}
				}
			}
		}

private void configManifest(def output, boolean appModel, def variant) {
	        ...
		manifestFiles.add(new File(output.processManifest.manifestOutputDirectory, "AndroidManifest.xml"))
		manifestFiles.each { manifestFile->
			if (manifestFile != null && manifestFile.exists()) {
				...
				shouldAdd.each { per ->
					String lastPermission = "<uses-permission ${ns} android:name=\"${per}\" />"
					if (packageName != null && lastPermission.contains('${applicationId}')) {
						lastPermission = lastPermission.replace('${applicationId}', packageName)
					}
					def permission = parser.parseText(lastPermission)
					manifest.appendNode(permission)
				}
				...
				def nsCustom = 'xmlns:android="http://schemas.android.com/apk/res/android"'
				def level = 'android:protectionLevel="signature"'
				shouldAddCoustom.each { per ->
					String lastPermission = "<permission ${nsCustom} android:name=\"${per}\" ${level}/>"
					if (packageName != null && lastPermission.contains('${applicationId}')) {
						lastPermission = lastPermission.replace('${applicationId}', packageName)
					}
					def permission = parser.parseText(lastPermission)

					manifest.appendNode(permission)
				}

				...

				manifestFile.setText(XmlUtil.serialize(manifest), "utf-8")
			}

可以看出其hook了gradle的解析了配置之后注入了gradle任务（任务相关可以参考官网），详细的gradle的构建周期函数可以参考这个文章。在processManifest任务执行之后执行了他自己的动作，也就是更改androidmanifest文件的内容

4.修复方案

了解了其实现原理之后，开始整理其修复方案，主要需要解决的是，在合适的时间点去移除权限，也就是需要在其修改完Androidmanifest文件之后，和Androidmanifest文件被打包到apk中之前这段时间，这里涉及到gradle打包中的各个函数调用顺序，详细的打包流程参考这里，详细的任务在这里，我这里选择的切入点在processResources的任务执行之前，详细代码如下：

project.afterEvaluate {
        project.android.applicationVariants.all { variant ->
            variant.outputs.each { output ->
                output.processResources.doFirst { pm->
                    String manifestPath = output.processResources.manifestFile;
                    def manifestContent = file(manifestPath).getText()
                    manifestContent = manifestContent.replace('<uses-permission android:name="android.permission.RECEIVE_SMS"/>', '')
                    file(manifestPath).write(manifestContent)
                }
            }
        }
    }

主要的处理就是剔除其中的RECEIVE_SMS权限相关。当然，前提是项目中确实没有使用该权限，所以移除不会导致相关问题。

5.复盘

解决该问题主要涉及到 Androidmanifest.xml的合并，gradle构建生命周期，android打包流程和相关的gradle知识，当前对gradle的了解不够，导致阅读和理解比较耗时，接下来需要多关注，此外还有一个问题没解决，就是采用.processManifest.finalizedBy这种方式时，发现androidmanifest文件经历了如下情况： 没有注入权限->注入权限->删除权限->又注入了权限 不知道是在哪一步又被注入了权限，还是其他情况？