gradle3.0 new command

Excerpt from the original text https://mp.weixin.qq.com/s/6UZhaI9cILJiPGYHkXd73g

No1 ：

Implementation

The compile instruction is marked as an obsolete method, and two new dependent instructions are added, one is implement and api, and the api is no different from the previous compile

Explain the image of implementation: for example, a library depends on a library, and the main project depends on this library, but cannot use the contents of that dependent library. That is to say, the implementation hides the library inside the library and does not use it for other projects outside, which avoids the problem of jar conflicts.

No2：

compileOnly

Equivalent to provided, it is only valid at compile time, will not participate in packaging, and will not be included in the apk file. Can be used to resolve conflicts with duplicate imported libraries

No3：

Custom plugin https://blog.csdn.net/eclipsexys/article/details/50973205 is a bit difficult

No4:

The version conflict under the same configuration will automatically use the latest version; and the version conflict under different configurations, gradle will directly report an error when synchronizing. Conflicts can be resolved using exclude and force

No5

If two different jar packages exist locally at the same time, or if there are existing jar packages locally, and then rely on different versions of jar packages remotely, an error will be reported. You can use compileOnly to replace implementation with one of them

No6：

Depends on the local aar package: the path declaration stored in the aar package and the dependency import are separated

repositories {
    flatDir {
        dir "../${project.name}/libs"
    }
}
dependencies {  
    implementation (name: 'aar', ext: 'aar' )  
}

If there are many aar packages, you can also add all packages in one folder like a jar package:

def dir = new File('app/libs')
dir.traverse (
        nameFilter: ~/.*\.aar/
) { file ->
    def name = file.getName().replace('.aar', '')
    implementation(name: name, ext: 'aar')
}

When other Modules refer to the module of this library, they also need to add the following configuration to his build.gradle, otherwise it will prompt that the file cannot be found:

repositories {  
    flatDir {  
        dirs 'libs', '../module name containing aar package/libs'  
    }  
}  

It is recommended to add it uniformly in the root build.gradle of the project, and list all the module names containing the aar package, so that neither this Module nor other Modules need to configure the path separately:

allprojects {
    repositories {
        jcenter ()
        google()
        flatDir {
             dirs "../moudle-A/libs,../moudle-B/libs,../moudle-C/libs".split(",")
        }
    }
}

No7：

The jniLibs directory is the default placement directory for so files

No8 ：

All x86/x86_64/armeabi-v7a/arm64-v8a devices support armeabi architecture so files. So in order to reduce the package size, in order to reduce the size of the apk, you can only keep one folder of armeabi. But if you want to introduce multiple platforms, you need to keep the number of so files consistent, that is, each so file under armeabi file must find the corresponding so file under armeabi-v7a, but the volume of the apk package will be increase.

No9：

If the resource files in the aar package are duplicated

packagingOptions {
    exclude 'META：-INF/LICENSE.txt'
}

exclude contains duplicate files

No10 ：

If the manifest file of the aar package conflicts with our app manifest file attributes: use tools:replace="attribute name" to resolve.