As some may have watched the Android Studio Gradle progress, Xavier Ducrohet mentioned in his quick speech how to use the android Gradle build system. My problem is that the documentation and the presentation lack information on quick start. or at least for me. In my next code, I tried to solve the problem of using Gradle system of Android plugins and I am sure that I have some steps and the wrong ones. (I did not use ant or maven much)
Perhaps I will continue it step by step with what I have done so far.
android { compileSdkVersion 17 buildToolsVersion "17.0.0" defaultConfig { minSdkVersion 7 targetSdkVersion 16 signingStoreLocation = "debug.keystore" signingStorePassword = "***************" signingKeyAlias = "***************" signingKeyPassword = "**************" }
First, im sets the default options for the debug assembly (or every assembly that uses the default settings .. does that mean no assembly types or tastes?)
sourceSets:
sourceSets { main { manifest.srcFile 'AndroidManifest.xml' java.srcDirs = ['com.project.maingradle', 'com.otherproject.changedsourcefilesforthisproject'] res.srcDirs = ['res', 'resfromotherprojectusingpartsofsamecode'] assets.srcDirs = ['assets'] } }
At this point I defined sourceSets. This is where I have my first question. If I have the same code that I want to use for two projects, is it possible or do I need to define more sources like →
sourceSets { main {...} srcsetforanotherproject {...} }
... depending on src base folders? Or should a definition be made for sourceSets, as in my first setsSets declaration, by defining a set of different res-folders, for example, as Xavier Ducroet mentioned? (It is also unclear if I can only do this for res files this way, as well as for java src code folders like java.srcDirs = ['com.project.maingradle', 'com.otherproject.changedsourcefilesforthisproject'].
signingConfigs:
signingConfigs { debugRelease { storeFile file("debug.keystore") } release { storeFile file("release.keystore") } testflight { storeFile file("testflight.keystore") } }
In this step, I defined the different keys used for different releases. should be fine ...
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 } }
This step has been more clearly explained than any other step for the Gradle Android plugin. Except that I don’t know if there is a preinstalled version of debugging or debugging running in the background ... I still need to clarify it ... at least I think so, due to using namesuffixes, proguard or declaration The key to this assembly (signedConfig).
Fragrances:
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 } } }
Personally, I think that aromas are the most interesting part. Xavier Ducroet said you should not define a key in buildtype (instead declared in aromas) if you want to use different keys for different aroma collections? I do not know if I understood this correctly.
In any case ... what I'm trying to do here is to identify the different tastes that need to be created with different settings, such as: sdk version control for different systems, an exclusive package name and setting up a dependent set of sources, as you can see in the example. that I'm not sure how builders depend on tastes ... do they just multiply every taste with every type of assembly? And ... is it normal to set sourceSet (if you can install more source sets), like in a flavor?