Preface原文地址:http://tools./tech-docs/new-build-system/gradle-experimental 特别说明:本文主要是方便墙后面的人使用,建议如果网络没有问题,尽量原文查看。 IntroductionThe new experimental plugin is based on Gradle’s new component model mechanism, while allows significant reduction in configuration time. It also includes NDK integration for building JNI applications. This user guides provides details on how to use it and highlights the difference between the new plugin and the original plugin. WARNING: Note that this is plugin is at the experimental stage. The Gradle API for the new component model is not final, which means it’ll only work with a specific version of Gradle until the APIs are final. Additionally, the DSL is likely change significantly, as APIs to create the DSL are finalized. This is a very early preview of the plugin for feedback on performance and NDK integration. Requirements
Migrating from Traditional Android Gradle PluginA typical Android Studio project may have a directory structure as follows. File that needs to be change is highlighted in red: There are some significant changes in the DSL between the new plugin and the traditional one.
./gradle/wrapper/gradle-wrapper.properties
./build.gradle
./app/build.gradle There are significant changes to the DSL of the plugin. We understand that many of the changes are frustrating and seem unnecessary, and our goal is to remove some of these current changes to minimize the migration process from the traditional plugin in the future. DSL Changes:
Current DSL Limitations that will hopefully go away:
Signing ConfigYou can refer to another model element using the $() syntax. To use this syntax, “-Dorg.gradle.model.dsl=true” has to be added as an argument to the Gradle command line for version below 2.10. This is useful for specifying signing configs.
Ndk IntegrationThe experimental plugin comes with NDK integration for creating native applications. To use the NDK integration:
The build.gradle of a simple NDK application may look like this:
*Note that the moduleName is required. It determines the name of the resulting native library. Source SetBy default, it will look in src/main/jni for C/C++ file. Configure android.sources to change the source directory.
The JNI source set may contain both C and C++ files. All files in the sub-directories are included. Files with extension ‘.c’ is considered as C files, whereas C++ files has may have any of the following extensions: ‘.C’, ‘.CPP’, ‘c++’, ‘.cc, ‘.cp’, ‘.cpp’, ‘.cxx’. Files may be excluded with the exclude method, whereas include is ignored:
Other Build OptionsVarious build options can be set within the android.ndk { } block. For example,
Known Limitations
SamplesAdditional samples can be found at https://github.com/googlesamples/android-ndk. Multiple NDK ProjectsPlugin 0.4.0 added the preliminary support for NDK dependencies and the ability to create just a native library. Please be aware this is a preview of the direction we are going and the implementation is not complete. Note that while it is possible to compile the native project for Gradle, editing and debugging support in Android Studio is not yet implemented. Standalone NDK PluginIn gradle-experimental:0.4.0, a new plugin is created to allow creation of just the native library without creating an Android application or library. The DSL is similar to the application/library plugin. The following example build.gradle can create a libhello.so from sources in “src/main/jni”
Known Issues
NDK DependenciesThe syntax for specifying dependency follows the style of Gradle’s future dependency system. You can set a dependency on an Android project or a specific file. For example, let say you have a subproject in “lib” using the standalone NDK plugin: lib/build.gradle:
Any projects with a JNI dependency will include the directories specified in the exportedHeaders.. You can add dependency on the lib project from your application for your JNI code: app/build.gradle:
You can specify a build type and/or product flavor of your target project. Otherwise, the plugin will try to find the same build types and product flavor as your application. You can also specify the linkage type if you would like the native library to be linked statically. E.g.
To declare a dependency on a file, you will also need to specify the ABI. E.g.,
Caveat: The next version will have a DSL change to follow Gradle’s built in support for prebuilt library, similar to https://github.com/gradle/gradle/blob/master/subprojects/docs/src/samples/native-binaries/prebuilt/build.gradle. You can add native dependency to either ‘jniLibs’ or ‘jni’ source set. When dependency is added to “jniLibs” the native library will be package into the application/library, but it will not be used for compiling the JNI code. E.g.
DSL ChangeThe plugin is still in experimental stage. DSL will change throughout the development of the plugin. This section documents the changes that occurs between different versions to help with migration. 0.4.x -> 0.6.0-alpha1The DSL for specifying dependencies on a specific library files have changed to follow Gradle’s native dependency DSL. (see https://github.com/gradle/gradle/blob/master/subprojects/docs/src/samples/native-binaries/prebuilt/build.gradle)
is replaced by:
0.2.x -> 0.4.0+= no longer works for collections. Adding items to the list can be done with the ‘add’ or ‘addAll’ method. e.g. CFlags += “-DCUSTOM_DEFINE” can be replaced with CFlags.add(“-DCUSTOM_DEFINE”) 0.1.x -> 0.2.x
Change Log0.6.0-alpha3
0.4.0
|
|
来自: Dragon_chen > 《JNI》