Using Build Flavors - Structuring source folders and build.gradle correctly
It seems you need to reload your project after adding new flavors in build.gradle. After that, you will see 4 build Variants in the Build Variants view (you access it from the left edge of the window).
Regarding the additional source directories, it seems you need to create them by hand : src/flavor1/java and src/flavor2/java. You will see that changing the flavor in the "Build Variants" view will change the currently active source directories (directory is blue when it is an active source directory)
Finally, "gradle will create new sourceSets for your new flavors" means that gradle will create the objects android.sourceSets.flavor1 and android.sourceSets.flavor2 and you can use them in your build.gradle script. But those objects are created dynamically, that's why you don't see them in the build.gradle (I suggest you reading this : http://www.gradle.org/docs/current/userguide/tutorial_using_tasks.html Especially the 6.6: it explain the creation of dynamic task. A gradle script is a groovy script, so I suggest you to get familiar with groovy too)
"Product Flavors" on Android
I've been asked sometimes on how to work with different hosts, icons, or even package names, deppending on different versions of the same app.
There are lot of reasons to do this and one easy way to go: Product Flavors.
You can define on your build.gradle script these kind of things I've described before.
Product flavors Part of this article is written thinking on product flavors, so, what are they? Regarding to Android documentation:
A product flavor defines a customized version of the application build by the project. A single project can have different flavors which change the generated application.
How can you define them? You must write on your build.gradle which flavors you want to define:
productFlavors {
...
devel {
...
}
prod {
...
}
}
Now, we will have two different flavors of our app. You can check it on Android Studio too inside the Build Variants tab
Build variants
Multiple package names
What if you want to have installed on your phone one app with development state and one for production state. As you might know, you can only install one app with the same package name (if you try to install some new APK with the same as one that's installed on your phone, it will try to update it).
The only thing you have to do is to define it on each of your product flavors:
android {
productFlavors {
devel {
applicationId "zuul.com.android.devel"
}
prod {
applicationId "zuul.com.android"
}
}
}
Send requests to multiple hosts depending on the flavor As before, you must include some params on your product flavor config field.
android {
productFlavors {
devel {
applicationId "zuul.com.android.devel"
buildConfigField 'String', 'HOST', '"http://192.168.1.34:3000"'
}
prod {
applicationId "zuul.com.android"
buildConfigField 'String', 'HOST', '"http://api.zuul.com"'
}
}
}
As an example, we will try to show you how you can integrate this with Retrofit to send request to the appropiate server without handling which server you're pointing and based on the flavor. In this case this is an excerpt of the Zuul android app:
public class RetrofitModule {
public ZuulService getRestAdapter() {
RestAdapter restAdapter = new RestAdapter.Builder()
.setEndpoint(BuildConfig.HOST)
.setLogLevel(RestAdapter.LogLevel.FULL)
.build();
return restAdapter.create(ZuulService.class);
}
}
As you can see you just have to use the BuildConfigclass to access the variable you've just defined.
Any variable available through your code The HOST variable is not the only one you can expose in your code. You can do it with whatever you want:
prod {
applicationId "zuul.com.android"
buildConfigField 'String', 'HOST', '"http://api.zuul.com"'
buildConfigField 'String', 'FLAVOR', '"prod"'
buildConfigField "boolean", "REPORT_CRASHES", "true"
}
You can access them as follows:
BuildConfig.HOST
BuildConfig.FLAVOR
BuildConfig.REPORT_CRASHES
Different icons per flavor If you want to have different icons per flavor, so you can visually detect which one you're opening (you could do it by the name too... But it could not fit the space!), you just have to define new directory structures for each of the flavors.
In the example I've just used there are two flavors: devel and prod. Then, we could define an two new directory structures so we can define the resources we want:
structure
This works with other types of resources like strings.xml, integers.xml, arrays.xml, etc.
Configure Signing Settings
To manually configure the signing configurations for your release build type using Gradle build configurations:
1.Create a keystore. A keystore is a binary file that contains a set of private keys. You must keep your keystore in a safe and secure place. 2.Create a private key. A private key represents the entity to be identified with the app, such as a person or a company. 3.Add the signing configuration to the module-level build.gradle file:
android {
...
defaultConfig {...}
signingConfigs {
release {
storeFile file("myreleasekey.keystore")
storePassword "password"
keyAlias "MyReleaseKey"
keyPassword "password"
}
}
buildTypes {
release {
...
signingConfig signingConfigs.release
}
}
}
Generate a signed APK:
To generate a signed APK, select Build > Generate Signed APK from the main menu. The package in app/build/apk/app-release.apk is now signed with your release key.
ref: https://developer.android.com/studio/build/build-variants.html#signing,http://blog.brainattica.com/how-to-work-with-flavours-on-android/
If you got in the Studio preferences, under the Gradle section, you can enable auto-import for your project (we'll enable this by default later). This will let Studio re-import your build.gradle whenever you edit it.
Creating flavors doesn't mean you're going to use custom code for them so we don't create the folders. You do need to create them yourself.
If you look at my IO talk you'll see how we mix in together values from the flavors and build type to create the variant.
For the Java source:
src/main/java
src/flavor1/java
src/debug/java
are all 3 used to create a single output. This means they can't define the same class.
If you want to have a different version of the same class in the two flavor you'll need to create it in both flavors.
src/flavor1/java/com/foo/A.java
src/flavor2/java/com/foo/A.java
And then your code in src/main/java can do
import com.foo.A
depending on the flavor selected, the right version of com.foo.A is used.
This also means both version of A must have the same API (at least when it comes to the API used by classes in src/main/java/...
Edit to match revised question
Additionally, it's important to put the same A class only in source folders that are mutually exclusive. In this case src/flavor1/java and src/flavor2/java are never selected together, but main and flavor1 are.
If you want to provide a different version of an activity in different flavor do not put it in src/main/java.
Do note that if you had 3 flavors and only wanted a custom one for flavor1, while flavor2 and flavor3 shared the same activity you could create a common source folders for those two other activities. You have total flexibility in creating new source folders and configuring the source set to use them.
On to your other points:
It's normal that the 2nd flavor source folder is not blue. You need to switch to the 2nd flavor to enable it, and then you'll be able to create packages and classes inside. Until then, Studio doesn't consider it to be a source folder. We'll hopefully improve this in the future to make the IDE aware of those unactive source folders.
I think it's also normal that you can't create resource files in the res folder. The menu system hasn't been updated to deal with all these extra resource folders. This will come later.