Android Studio 1.3 配置编译NDK参考文档

Experimental Plugin User Guide

Introduction

The 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

  • Gradle 2.5 only
  • Android NDK r10e (if you are using NDK)
  • SDK with Build Tools at least version 19.0.0 and we aim to minimize the amount of changes needed for the migration process in the future. Some features may require a more recent version.

Migrating from Traditional Android Gradle Plugin

A 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.

.

├── app/

│   ├── app.iml

│   ├── build.gradle

│   └── src/

├── build.gradle

├── gradle/

│   └── wrapper/

│       ├── gradle-wrapper.jar

│       └── gradle-wrapper.properties

├── gradle.properties

├── gradlew*

├── gradlew.bat

├── local.properties

├── MyApplication.iml

└── settings.gradle

 

./gradle/wrapper/gradle-wrapper.properties

  • The new plugin supports only gradle-2.5.

#Wed Apr 10 15:27:10 PDT 2013
distributionBase=GRADLE_USER_HOME
distributionPath=wrapper/dists
zipStoreBase=GRADLE_USER_HOME
zipStorePath=wrapper/dists
distributionUrl=https\://services.gradle.org/distributions/gradle-2.5-all.zip

./build.gradle

  • Classpath for the plugin is com.android.tools.build:gradle-experimental instead of com.android.tools.build:gradle.

  • The current version is 0.2.0.

// Top-level build file where you can add configuration options common to all sub-projects/modules.

buildscript {

      repositories {

            jcenter()

      }

      dependencies {

            classpath 'com.android.tools.build:gradle-experimental:0.2.0'

          // NOTE: Do not place your application dependencies here

        // in the individual module build.gradle files

      }

}

allprojects {

      repositories {

            jcenter()

      }

}

 

./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:

  • Plugin name is com.android.model.application instead of com.android.application. Or use apply plugin: 'com.android.model.library' if you want to create an Android aar library.

  • Configuration is wrapped with the model { } block

  • Most properties require the = operator

  • Adding elements to a Collection should be done using the += operator.

Current DSL Limitations that will hopefully go away:

  • buildTypes, productFlavors and signingConfigs must be place outside of the  android { } block.

  • Nested options within the android { } block must be configured using the with keyword.

  • Properties are only set with their direct types only, with no way to accept other types and adapting them. For instance:

    • Properties of type File accepts only File instead of File and String objects.

    • minSdkVersion cannot directly receive either an integer or string (for codename).

  • Creating a buildType or productFlavor requires calling the create method.  Modifying an existing one such as the release and debug buildType can be done using the just the name.

  • The DSL for modifying variants and their tasks is very, very limited right now.

apply plugin: 'com.android.model.application'

model {

      android {

           compileSdkVersion = 22

           buildToolsVersion = "22.0.1"

           defaultConfig.with {

                applicationId =  "com.example.user.myapplication"

                minSdkVersion.apiLevel = 15

                targetSdkVersion.apiLevel = 22

                versionCode = 1

                versionName = "1.0"

                buildConfigFields.with {

                     create() {

                     type = "int"

                     name = "VALUE"

                     value = "1"

                     }

                }

           }

      }

      android.buildTypes {

           release {

                minifyEnabled = false

                proguardFiles += file('proguard-rules.pro')

           }

      }

      android.productFlavors {

           create("flavor1") {

                applicationId = ‘com.app’

           }

      }

      // Configures source set directory.

      android.sources {

           main {

                java {

                     source {

                          srcDir 'src'

                     }

                }

           }

      }

}

dependencies {

      compile fileTree(dir: 'libs', include: ['*.jar'])

      compile 'com.android.support:appcompat-v7:22.2.0'

}

 

Ndk Integration

The experimental plugin comes with NDK integration for creating native applications.  To use the NDK integration:

  • Use the SDK Manager inside Studio to download the NDK.

  • Set ndk.dir in local.properties or the ANDROID_NDK_HOME environment variable to the directory containing the NDK.

  • Add an android.ndk block to the model in build.gradle.

Known Limitations

  • There’s no support for NDK-only modules. The only supported project types are hybrid app projects and hybrid Library Projects.
  • Consumed Library project don’t impact compilation of jni code in the consuming project (ie the AAR so files are simply packaged in the APK)
  • No support for creating and depending on static libraries
  • No support for using a NDK modules like cpu_features
  • No support for integrating external build systems.

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.

By default, it will look in src/main/jni for C/C++ file.  Configure android.sources to change the source directory.

Various build options can be set within the android.ndk { } block.  For example,

Samples

Additional samples can be found at https://github.com/googlesamples/android-ndk.
对于不能正常访问GitHub的,可以点击这里下载最近保存的版本。

发布者

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注