Android混淆的一些坑儿

最新推荐文章于 2025-02-05 20:49:11 发布

原创最新推荐文章于 2025-02-05 20:49:11 发布 · 2.5k 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#混淆 #aapt-rules

Android 专栏收录该内容

15 篇文章

订阅专栏

本文探讨了在Android应用中，当一个自定义View同时被宿主和插件依赖时可能导致的ClassCastException问题。详细分析了如何通过调整混淆规则及采用动态生成View的方式避免这一问题。

转载请注明出处：http://blog.youkuaiyun.com/kester_/article/details/52461917

发现问题

一个Library里的自定义View同时被宿主和插件以compile的形式依赖，
在使用时有可能导致ClassCastException。

研究问题

同时被宿主和插件以compile形式依赖，会导致app有两个一样包名的类，
出现转换异常，一开始产生了两个思路：
1. 让这个类被混淆
2. 插件里这个Library以provided形式依赖

考虑到依赖库需要跟随插件即时更新，放弃第2种思路，而项目中因为加了混淆字典，
宿主和插件同时进行混淆的话，这个类在宿主和插件里就是不同包名的类从而解决问题，
所以从第1个思路入手。

防止自定义View被混淆(混淆保护)的代码是

-keepclasseswithmembers class * {  
    public <init>(android.content.Context);  
}  
-keepclasseswithmembers class * {  
    public <init>(android.content.Context, android.util.AttributeSet);  
}  
-keepclasseswithmembers class * {  
    public <init>(android.content.Context, android.util.AttributeSet, int);  
}

查看了宿主和插件的proguard文件发现，宿主中是有对自定义View进行混淆保护，
但是插件中是没有对自定义View进行混淆保护的，而看到的现象是宿主和插件都对
自定义View进行了混淆保护。

查看proguard文件上面默认备注，

# Add project specific ProGuard rules here.
# By default, the flags in this file are appended to flags specified
# in D:\Program Files (x86)\sdk/tools/proguard/proguard-android.txt
# You can edit the include path and order by changing the proguardFiles
# directive in build.gradle.
#
# For more details, see
#   http://developer.android.com/guide/developing/tools/proguard.html

# Add any project specific keep options here:

# If your project uses WebView with JS, uncomment the following
# and specify the fully qualified class name to the JavaScript interface
# class:
#-keepclassmembers class fqcn.of.javascript.interface.for.webview {
#   public *;
#}

可以发现，原来混淆规则不止使用Module里的proguard文件的规则，还需要加上SDK内
的默认混淆文件proguard-android.txt，然后对默认混淆保护文件进行修改验证后发现，
问题依然没有解决，这个自定义View还是被混淆保护了！那究竟还有哪里会影响混淆规则呢？

通过反向索引发现，这个类居然在一个奇怪的文件aapt_rules.txt里使用到了，还是被keep了。
这个奇怪的文件在build目录里，而且项目里也没有生成它的地方，所以可以知道，这是在代码
控制范围外的编译产物，网上对aapt_rules.txt的解释非常少，于是翻了gradle的源码，发现：

if (config.buildType.isMinifyEnabled()) {
    if (config.buildType.shrinkResources && config.useJack) {
        LoggingUtil.displayWarning(Logging.getLogger(this.class), scope.globalScope.project,
                "shrinkResources does not yet work with useJack=true")
    }
    ConventionMappingHelper.map(processResources, "proguardOutputFile") {
        new File("$scope.globalScope.buildDir/
                ${FD_INTERMEDIATES}/proguard-rules/${config.dirName}/aapt_rules.txt")
    }
    } else if (config.buildType.shrinkResources) {
        LoggingUtil.displayWarning(Logging.getLogger(this.class), scope.globalScope.project,
                "To shrink resources you must also enable ProGuard")
    }
}

aapt_rules.txt是在ProcessAndroidResources 处理资源过程产生的，并且

if (config.isMinifyEnabled()) {
    conventionMapping(jackTask).map("proguardFiles") {
        // since all the output use the same resources, we can use the first output
        // to query for a proguard file.
        BaseVariantOutputData variantOutputData = variantData.outputs.get(0)

        List<File> proguardFiles = config.getProguardFiles(true /*includeLibs*/,
                [getDefaultProguardFile(DEFAULT_PROGUARD_CONFIG_FILE)])
        File proguardResFile = variantOutputData.processResourcesTask.proguardOutputFile
        if (proguardResFile != null) {
            proguardFiles.add(proguardResFile)
        }
        // for tested app, we only care about their aapt config since the base
        // configs are the same files anyway.
        if (testedVariantData != null) {
            // use single output for now.
            proguardResFile =
                    testedVariantData.outputs.get(0).processResourcesTask.proguardOutputFile
            if (proguardResFile != null) {
                proguardFiles.add(proguardResFile)
            }
        }

        return proguardFiles
    }

    jackTask.mappingFile = project.file(
            "${project.buildDir}/${FD_OUTPUTS}/
            mapping/${variantData.variantConfiguration.dirName}/mapping.txt")
}

通过上面代码可以看出，在进行混淆的时候，gradle会把aapt_rules.txt也加入到混淆规则文件proguardFiles中，所以也就是这里导致了插件中自定义View无法被混淆。

解决问题

官方答复说是这个问题在最新版的gradle中已经去掉了，对于这个系统级别的BUG形式存在的规则，只好妥协了，既然无法从代码上让这个类混淆（想想也是，xml中需要使用的自定义View如果被混淆了在R文件中索引资源可能都出问题了），就把这个自定义View在代码中进行动态生成了，只要它不在布局文件中，就不会在编译资源时被加入到aapt_rules.txt 的混淆保护中了，验证通过，aapt_rules.txt中没有出现这个自定义View的混淆规则了，mapping.txt也没有发现该类被混淆保护了，问题解决。

概括结论

在使用Android Studio进行编译混淆时，gradle会使用SDK默认proguard-android.txt，Module中
proguard-rules.pro，再加上资源编译产物aapt_rules.txt三个文件作为混淆保护规则处理。布局文件
中自定义View如果不想被混淆保护，就从布局文件中去掉吧，在代码中动态生成也是OK的。