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

101

Nachdem ich ein Eclipse-Projekt in Android Studio importiert habe, werden zwei build.gradleDateien angezeigt:

1 - <PROJECT_ROOT>\build.gradle
2 - <PROJECT_ROOT>\app\build.gradle

Die erste Version ist kürzer, die zweite Version enthält Definitionen für compileSdkVersionusw.

Was ist der Grund für zwei separate Dateien? Gibt es separate Build-Aufgaben?

— Sabuncu
quelle

Ähnliche Frage zu Unterschied zwischen build.gradle (Projekt) und build.gradle (Modul)

— Suragch

Antworten:

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

<PROJECT_ROOT>\build.gradleist eine "Build-Datei der obersten Ebene", in der Sie Konfigurationsoptionen hinzufügen können, die allen Unterprojekten / Modulen gemeinsam sind.

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

Zum Beispiel in der Top-Level - Datei können Sie diese gemeinsame Eigenschaften angeben:

buildscript {
    repositories {
        mavenCentral()
    }

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

ext {
    compileSdkVersion = 23
    buildToolsVersion = "23.0.1"
}

In deinem app\build.gradle

apply plugin: 'com.android.application'

repositories {
    mavenCentral()
}

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

— Gabriele Mariotti
quelle

+1 Danke, werde deine Antwort für einen Moment akzeptieren. Ist das build.gradleVorhandensein der Datei obligatorisch, um einen Build auszulösen? Ruft die Build-Datei der obersten Ebene auch Dateien der untersten Ebene auf? (Obwohl es keine Beweise dafür gibt.)

— Sabuncu

Die build.gradle-Dateien sind obligatorisch, wenn Sie ein Projekt mit gradle erstellen möchten. Android Studio benötigt kein Gradle, wird jedoch dringend empfohlen. Die Datei der obersten Ebene ruft keine Unterdateien auf. gradle arbeitet mit aufgaben, ist aber in einem kommentar schwer zu erklären.

— Gabriele Mariotti

Vielen Dank Gabriele, das wird mir den Einstieg erleichtern.

— Sabuncu

Besonders das rootProject.ext.compileSdkVersionKonstrukt ist sehr informativ.

— Sabuncu

Ist es wichtig, den Umweg mit ext {...} zu machen, oder sollten wir das Android-Plugin und die compileSdkVersion direkt auf die Build-Datei der obersten Ebene anwenden?

— PhilLab

Aus der offiziellen Dokumentation:

Android Studio-Projekte enthalten eine Gradle-Build-Datei für Projekte der obersten Ebene, mit der Sie die Konfigurationsoptionen hinzufügen können, die allen Anwendungsmodulen im Projekt gemeinsam sind. Jedes Anwendungsmodul verfügt außerdem über eine eigene build.gradleDatei für die für dieses Modul spezifischen Build-Einstellungen.

Geben Sie hier die Bildbeschreibung ein

Projekterstellungsdatei

<PROJECT_ROOT>\build.gradleoder die Projekterstellungsdatei gilt für das gesamte Projekt und wird daher für globale Projektkonfigurationen verwendet. Eine typische Projekterstellungsdatei enthält Folgendes:

Buildscript, das definiert:
- Repositories und
- Abhängigkeiten
Gradle Plugin Version

Standardmäßig werden die Projektebene Gradle Datei verwendet buildscript die Gradle definieren Repositories und Abhängigkeiten . Dadurch können verschiedene Projekte unterschiedliche Gradle-Versionen verwenden. Unterstützte Repositorys sind JCenter, Maven Central oder Ivy. In diesem Beispiel wird erklärt, dass das Build-Skript das JCenter-Repository und ein Klassenpfad-Abhängigkeitsartefakt verwendet, das das Android-Plugin für Gradle Version 1.0.1 enthält.

Modulerstellungsdatei

<PROJECT_ROOT>\app\build.gradleoder das Modul Build - Datei ist für ein bestimmtes Modul so wird es für bestimmte Modulebene configs verwendet werden. Eine Modulerstellungsdatei enthält Folgendes:

Android-Einstellungen

compileSdkVersion

buildToolsVersion

defaultConfig und productFlavors

Manifest-Eigenschaften wie applicationId, minSdkVersion, targetSdkVersion und Testinformationen

buildTypes

Build-Eigenschaften wie Debuggable, ProGuard-Aktivierung, Debug-Signatur, Versionsnamensuffix und Testinformationen

Abhängigkeiten

Sie können die offiziellen Dokumente hier lesen:

Projekte und Module erstellen Einstellungen

— SMR
quelle