Android Studio Gradle Erste Schritte

Question

Da einige vielleicht das Android Studio Gradle I/O gesehen haben, erwähnt Xavier Ducrohet in seiner schnellen Rede, wie man das Android-Gerät-Build-System verwendet. Mein Problem ist, dass es der Dokumentation und der Präsentation an Informationen für einen schnellen Start mangelt. oder zumindest für mich. In meinem folgenden Code habe ich versucht, die Verwendung des Gradle Android-Plugin-System zu lösen und ich bin sicher, dass ich einige Schritte falsch und einige richtig habe. (ich habe nicht oft ant oder maven verwendet)

Vielleicht werde ich Schritt für Schritt mit dem, was ich bisher gemacht habe, durchgehen.

android { 
    compileSdkVersion 17 
    buildToolsVersion "17.0.0" 

    defaultConfig { 
     minSdkVersion 7 
     targetSdkVersion 16 

     signingStoreLocation = "debug.keystore" 
     signingStorePassword = "***************" 
     signingKeyAlias = "***************" 
     signingKeyPassword = "**************" 
    } 

Zuerst im die Standardeinstellung für das Debug-Build-Konfiguration (oder jedes Build, den Standard settings..that verwendet bedeutet, dass kein buildtypes oder Aromen?)

sourceSets:

sourceSets { 

     main { 
      manifest.srcFile 'AndroidManifest.xml' 
      java.srcDirs = ['com.project.maingradle', 'com.otherproject.changedsourcefilesforthisproject'] 
      res.srcDirs = ['res', 'resfromotherprojectusingpartsofsamecode'] 
      assets.srcDirs = ['assets'] 
     } 
    } 

In In diesem Schritt habe ich die sourceSets definiert. Hier habe ich meine erste Frage. Wenn ich den gleichen Code habe ich für zwei Projekte verwenden wollen, ist es möglich/oder sollte es jedoch nicht mehr sourcesets getan werden wie ->

sourceSets { 

     main {...} 
     srcsetforanotherproject {...} 
    } 

... je nach den zugrunde liegenden src Ordner? Oder sollte die Definition für sourceSets wie in meiner ersten sourceSets-Deklaration durchgeführt werden, indem man einen Satz von verschiedenen, beispielsweise res-Ordnern, wie Xavier Ducrohet erwähnt, definiert? (Es ist auch nicht klar, ob ich dies nur für res-Ordner auf diese Weise tun kann oder auch für die java src-Code-Ordner wie java.srcDirs = ['com.project.maingradle', 'com.otherproject.changesourcefilesforthisproject'].

signingConfigs:

signingConfigs { 
     debugRelease { 
      storeFile file("debug.keystore") 
     } 

     release { 
      storeFile file("release.keystore") 
     } 

     testflight { 
      storeFile file("testflight.keystore") 
     } 
    } 

In diesem Schritt i die verschiedenen Schlüssel definiert haben für verschiedene Versionen verwenden, sollten in Ordnung sein ...

buildTypes.

buildTypes { 

     debugRelease.initWith(buildTypes.release) 
     testflight.initWith(buildTypes.release) 

     sourceSets.debugRelease.setRoot("src/release") 
     sourceSets.debugRelease.setRoot("src/release") 
     sourceSets.debugRelease.setRoot("src/release") 

     debugRelease { 
      packageNameSuffix ".debugRelease" 
      versionNameSuffix "-DEBUG" 
      debuggable true 
      signingConfig signingConfigs.debug 
     } 

     testflight { 
      packageNameSuffix ".testflight" 
      versionNameSuffix "-TESTFLIGHT" 
      signingConfig signingConfigs.testflight 
     } 

     release { 
      packageNameSuffix ".release" 
      versionNameSuffix "-RELEASE" 
      runProguard true 
      proguardFile getDefaultProguardFile('proguard-android.txt') 
      signingConfig signingConfigs.release 
     } 
    } 

Dieser Schritt wurde klarer als jeder andere Schritt für das Android-Plugin erklärt. Abgesehen davon, dass ich nicht weiß, ob es eine vordefinierte Version oder Debug-Einstellung gibt, die im Hintergrund arbeitet ... muss ich es trotzdem klären ... zumindest denke ich das, wegen der Verwendung von Namensfixes, Progard oder Deklarieren eines Schlüssel zu diesem Build (signingConfig).

Aromen:

flavorGroups "abi", "version" 

    productFlavors { 

     arm { 
      flavorGroup "abi" 
     } 

     standardproject1 { 
      flavorGroup "version" 
      minSdkVersion 7 
      targetSdkVersion 14 
      packageName "com.project.maingradle.normal" 
      sourceSet sourceSets.main 
     } 

     standardproject2 { 
      flavorGroup "version" 
      minSdkVersion 6 
      targetSdkVersion 14 
      packageName "com.otherproject.normal" 
      sourceSet sourceSets.main 
     } 

     testflightproject1 { 
      flavorGroup "version" 
      minSdkVersion 7 
      targetSdkVersion 14 
      packageName "com.project.maingradle.testflight" 
      sourceSet sourceSets.main 
     } 

     testflightproject2 { 
      flavorGroup "version" 
      minSdkVersion 6 
      targetSdkVersion 14 
      packageName "com.otherproject.testflight" 
      sourceSet sourceSets.main 
     } 
    } 
} 

Ich persönlich denke, dass Aromen der interessanteste Teil sind. Xavier Ducrohet sagte, dass du keinen Schlüssel in einem Buildtyp definieren solltest (stattdessen in Flavors deklariert), wenn du verschiedene Schlüssel für verschiedene Flavorbuilds verwenden willst? Ich weiß nicht, ob ich das richtig verstanden habe.

Anyway ..., was ich hier versuchte, ist die Definition verschiedener Geschmacksrichtungen, die mit verschiedenen Einstellungen wie sdk Versionierung für verschiedene Systeme, einem exklusiven Paketnamen und einem abhängigen Quellsatz, wie Sie im Beispiel sehen, erstellt werden soll. Worüber ich mich nicht sicher bin, ist, wie die Buildtypen von Aromen abhängen ... multiplizieren sie einfach jeden Geschmack mit jedem Buildtyp? Und ... ist es in Ordnung, ein sourceSet zu setzen (wenn es möglich ist, mehr sourceSets zu setzen), so in einem Flavor?

Answer 1

Wie die Buildtypen von Aromen abhängen ... multiplizieren sie einfach jeden Geschmack mit jedem Buildtyp?

Ja, Gradle generiert jede Kombination von Build-Typen und Produktaromen. Gemäß der Gradle Plugin User Guide wird jede Build-Typ- und Produktaromakombination als Build-Variante bezeichnet.

Ist es in Ordnung, ein sourceSet zu setzen (wenn es möglich ist, mehr sourceSets zu setzen), so in einem Flavor?

Sicher! Produkt-Flavours (und Build-Varianten) enthalten automatisch auch ihre eigenen Sourcesets von src/myFlavorName, wie unter der Sourcesets and Dependencies documentation.