android-gradle
Konfigurieren Sie Ihren Build mit Gradle

Bemerkungen

Warum gibt es in einem Android Studio-Projekt zwei build.gradle-Dateien?

<PROJECT_ROOT>\app\build.gradle ist spezifisch für das App-Modul.

<PROJECT_ROOT>\build.gradle ist eine "Build-Datei der obersten Ebene", in der Sie Konfigurationsoptionen für alle Unterprojekte / Module hinzufügen können.

Wenn Sie ein anderes Modul in Ihrem Projekt verwenden, haben Sie als lokale Bibliothek eine andere Datei build.gradle: <PROJECT_ROOT>\module\build.gradle

Die Build-Datei der obersten Ebene

Die build.gradle-Datei der obersten Ebene, die sich im Stammverzeichnis des Projektes befindet, definiert Build-Konfigurationen, die für alle Module in Ihrem Projekt gelten. Standardmäßig verwendet die Build-Datei der obersten Ebene den buildscript {} block , um die Gradle-Repositorys und Abhängigkeiten zu definieren, die allen Modulen des Projekts gemeinsam sind. Im folgenden Codebeispiel werden die Standardeinstellungen und DSL-Elemente beschrieben, die Sie nach dem Erstellen eines neuen Projekts im Build.gradle der obersten Ebene finden.

buildscript {
    repositories {
        mavenCentral()
    }

    dependencies {
       classpath 'com.android.tools.build:gradle:2.2.0'
       classpath 'com.google.gms:google-services:3.0.0'
    }
}

ext {
    compileSdkVersion = 23
    buildToolsVersion = "23.0.1"
}

Die Build-Datei auf Modulebene

Mit der build.gradle-Datei auf Modulebene, die sich in jedem <project>/<module>/ -Verzeichnis befindet, können Sie Build-Einstellungen für das jeweilige Modul konfigurieren, in dem sich das Modul befindet. Durch das Konfigurieren dieser Build-Einstellungen können Sie benutzerdefinierte Paketierungsoptionen bereitstellen, z als zusätzliche build.gradle und Produktvarianten sowie zum Überschreiben der Einstellungen in der Manifestdatei main/ app oder der build.gradle Datei der obersten Ebene.

apply plugin: 'com.android.application'


android {
    compileSdkVersion rootProject.ext.compileSdkVersion
    buildToolsVersion rootProject.ext.buildToolsVersion
}

dependencies {
    //.....
}

Beispiel für die oberste Ebene

/**
 * The buildscript {} block is where you configure the repositories and
 * dependencies for Gradle itself--meaning, you should not include dependencies
 * for your modules here. For example, this block includes the Android plugin for
 * Gradle as a dependency because it provides the additional instructions Gradle
 * needs to build Android app modules.
 */

buildscript {

    /**
     * The repositories {} block configures the repositories Gradle uses to
     * search or download the dependencies. Gradle pre-configures support for remote
     * repositories such as JCenter, Maven Central, and Ivy. You can also use local
     * repositories or define your own remote repositories. The code below defines
     * JCenter as the repository Gradle should use to look for its dependencies.
     */

    repositories {
        jcenter()
    }

    /**
     * The dependencies {} block configures the dependencies Gradle needs to use
     * to build your project. The following line adds Android Plugin for Gradle
     * version 2.0.0 as a classpath dependency.
     */

    dependencies {
        classpath 'com.android.tools.build:gradle:2.0.0'
    }
}

/**
 * The allprojects {} block is where you configure the repositories and
 * dependencies used by all modules in your project, such as third-party plugins
 * or libraries. Dependencies that are not required by all the modules in the
 * project should be configured in module-level build.gradle files. For new
 * projects, Android Studio configures JCenter as the default repository, but it
 * does not configure any dependencies.
 */

allprojects {
   repositories {
       jcenter()
   }
}

Das Beispiel für die Moduldatei

/**
 * The first line in the build configuration applies the Android plugin for
 * Gradle to this build and makes the android {} block available to specify
 * Android-specific build options.
 */

apply plugin: 'com.android.application'

/**
 * The android {} block is where you configure all your Android-specific
 * build options.
 */

android {

  /**
   * compileSdkVersion specifies the Android API level Gradle should use to
   * compile your app. This means your app can use the API features included in
   * this API level and lower.
   *
   * buildToolsVersion specifies the version of the SDK build tools, command-line
   * utilities, and compiler that Gradle should use to build your app. You need to
   * download the build tools using the SDK Manager.
   */

  compileSdkVersion 23
  buildToolsVersion "23.0.3"

  /**
   * The defaultConfig {} block encapsulates default settings and entries for all
   * build variants, and can override some attributes in main/AndroidManifest.xml
   * dynamically from the build system. You can configure product flavors to override
   * these values for different versions of your app.
   */

  defaultConfig {

    /**
     * applicationId uniquely identifies the package for publishing.
     * However, your source code should still reference the package name
     * defined by the package attribute in the main/AndroidManifest.xml file.
     */

    applicationId 'com.example.myapp'

    // Defines the minimum API level required to run the app.
    minSdkVersion 14

    // Specifies the API level used to test the app.
    targetSdkVersion 23

    // Defines the version number of your app.
    versionCode 1

    // Defines a user-friendly version name for your app.
    versionName "1.0"
  }

  /**
   * The buildTypes {} block is where you can configure multiple build types.
   * By default, the build system defines two build types: debug and release. The
   * debug build type is not explicitly shown in the default build configuration,
   * but it includes debugging tools and is signed with the debug key. The release
   * build type applies Proguard settings and is not signed by default.
   */

  buildTypes {

    /**
     * By default, Android Studio configures the release build type to enable code
     * shrinking, using minifyEnabled, and specifies the Proguard settings file.
     */

    release {
        minifyEnabled true // Enables code shrinking for the release build type.
        proguardFiles getDefaultProguardFile('proguard-android.txt'), 'proguard-rules.pro'
    }
  }

  /**
   * The productFlavors {} block is where you can configure multiple product
   * flavors. This allows you to create different versions of your app that can
   * override defaultConfig {} with their own settings. Product flavors are
   * optional, and the build system does not create them by default. This example
   * creates a free and paid product flavor. Each product flavor then specifies
   * its own application ID, so that they can exist on the Google Play Store, or
   * an Android device, simultaneously.
   */

  productFlavors {
    free {
      applicationId 'com.example.myapp.free'
    }

    paid {
      applicationId 'com.example.myapp.paid'
    }
  }
}

/**
 * The dependencies {} block in the module-level build configuration file
 * only specifies dependencies required to build the module itself.
 */

dependencies {
    compile project(":lib")
    compile 'com.android.support:appcompat-v7:24.1.0'
    compile fileTree(dir: 'libs', include: ['*.jar'])
}

Verwenden Sie archivesBaseName, um den Apk-Namen zu ändern

Sie können den archivesBaseName , um den Namen von apk festzulegen.

Zum Beispiel:

  defaultConfig {
      ....
      project.ext.set("archivesBaseName", "MyName-" + defaultConfig.versionName);

  }

Sie erhalten diese Ausgabe.

MyName-X.X.X-release.apk