Develop Reference

How to configure Azure AD B2C for different environments in Android

I am using Azure AD B2C and need a different configuration file for each environment. I expect to have multiple B2C Tenants for my app. One for each environment. That means I need to alter my calls to reference different files. Currently I am calling:
PublicClientApplication.createMultipleAccountPublicClientApplication
Where the second parameter is an:
int configFileResourceId
I have been using:
R.raw.auth_config_multiple_account
But now I need to fold in additional environments. I handle most/all of my environment changes in the build.gradle like this:
buildTypes {
release {
buildConfigField "String", "SERVER_URL", '"xxx.xxxx.com"'
}
debug {
buildConfigField "String", "SERVER_URL", '"yyyy.yyy.com"'
}
}
But how do I do this while referencing the file itself? I can use the R.raw.auth_config_multiple_account from anywhere, but cannot from the build.gradle. How are others doing this? It's also very convenient to reference it from anywhere.

• I would suggest you to reference the build.gradle file for any environment changes by calling the System.env(“variable name”) which works in gradle to get the path of any variable. Thus, this should get you the actual path of the folder which contains this file.
• So, to reference the build.gradle file in the variable, it needs to be exported to a location like as below shown as an example: -
home = System.getenv(‘HOME’) OR "${System.env.HOME}/something/plugins"
• Once it is exported and called as above, you can edit it for adding or modifying any of your environment changes in the build.gradle file.
Please find the below links for more information: -
how to use Environment Variables in Gradle build files?

Building two different android apps on the same codebase that only differ by const

I am building two android applications, which relay on the same codebase but differ by the server address which they grab their files from.
Till now i've created two line of my server's address constant, and builded the application once with the first const, and second with the second const.
Is there any way to make my app compile twice, once with the first constant, and second with the second one?
I am using Android studio with Gradle build.
Thank you!

You can use product flavors to teach Gradle to build two separate copies of your app, where your server address is defined in BuildConfig:
android {
// other stuff here
productFlavors {
flavorOne {
buildConfigField "String", "URL", '"https://..."'
}
flavorTwo {
buildConfigField "String", "URL", '"https://..."'
}
}
}
In your Java code, refer to BuildConfig.URL to get the URL to use.

Yeah, you can use Build Variants. You can move those strings into resources under the variants directory and the build will pull in the right one.
Here's the link to the full documentation for how to set them up: https://developer.android.com/studio/build/build-variants.html

Add build machine signature to gradle generated variable

I'd like to stamp some variable generated from gradle (in my case it's User Agent used later with HTTP requests) to later be able to distinguish which developer build the app (for example if some developer made a mistake and his app is DDoSing the server).
So for now I can distinguish release from debug with:
buildTypes {
debug {
buildConfigField "String", "USER_AGENT", "\"Android-debug\""
}
release {
buildConfigField "String", "USER_AGENT", "\"Android-release\""
}
}
But for the debug I'd like to add something to know who built the app instance, it may be git login, machine name, or something else.

A gradle build file is actually Groovy code, and you're free to put whatever you want in it. You just have to make sure that the code runs before it would be used in the DSL that describes the build. So if you want to grab something from the system, just write the Groovy code to do that. Groovy is a lot like Java, and you have the full JDK to work with at runtime, so it should be easy to get started.
If you want to access things about the build machine and environment, you might have to shell out to different commands in order to gather that data. Populate some variables with that data. Then use buildConfigField as you already are to drop those values into BuildConfig.java.
Bear in mind that you might want to provide some value in both debug and release so they both generate the same BuildConfig symbols. Otherwise your app might not compile in one config or the other.
BTW. You can tell the difference between debug and release with properties that are already added to BuildConfig, so you don't need to add anything more to tell the difference. Lines like these will always appear (look in the generated BuildConfig.java to see for yourself):
public static final boolean DEBUG = Boolean.parseBoolean("true");
public static final String BUILD_TYPE = "debug";

How to define static String values in Android that change for test configurations with Gradle?

Hey I am trying to statically define String values that change according to the configuration I am running. So if I run a test configuration, it uses the test API url, but if I run a regular build, it statically sets the real API URL.
I am using two strings files right now, one in the main folder and one in the androidTest folder in Android Studio. This works well for getting different Strings per configuration, but I'de like to do it statically rather than dealing with Resource fetches.
Is this possible?
I have seen this answer for ANT, but I am not sure how to do it with Gradle.

You can generate gradle constants like this:
build.gradle
android {
buildTypes {
debug {
buildConfigField "String", "FOO", "\"foo\""
}
release {
buildConfigField "String", "FOO", "\"bar\""
}
}
}
And access them in your code through BuildConfig.FOO
Note you may need to clean and/or restart your IDE for the to come in to effect.

Override resources with gradle depending on buildType

I want to override some strings in my res/strings.xml with gradle.
I know that since Android Gradle Plugin 0.7.+ theres the possibilty to have a variant specific source folder.
But my app has a lot of flavors and I don't want to add additionally variant specific folders.
UPDATE 2014-01-17
What I want in detail:
I have some variables in my Resources that are depending only by the buildType (e.g. "release").
First I thought my SOLUTION_1 (override data after resources were merged) is nice, because if I have to change these variables I just have to change them in the build.config (just one place).
But as Scott Barta wrote in the comment below there are some good reasons why this solution is NOT a good idea.
So i tried another solution SOLUTION_2 (just merge the right resources) based on this GitHub project of shakalaca. I think this way is more elegant and I still have the advantage just to change the variables in one place!
SOLUTION_1 (override data after resources were merged):
What I did in AS 0.4.2:
in build.gradle I try to override the string "Hello World" to "OVERRIDE" (based on my answer at this post):
android.applicationVariants.all{ variant ->
// override data in resource after merge task
variant.processResources.doLast {
overrideDataInResources(variant)
}
}
def overrideDataInResources(buildVariant){
copy {
// *** SET COPY PATHS ***
try {
from("${buildDir}/res/all/${buildVariant.dirName}") {
// println "... FROM: ${buildDir}/res/all/${buildVariant.dirName}"
include "values/values.xml"
}
} catch (e) {
println "... EXCEPTION: " + e
}
into("${buildDir}/res/all/${buildVariant.dirName}/values")
// println "... INTO: ${buildDir}/res/all/${buildVariant.dirName}/values"
// --- override string "hello_world"
filter {
String line ->
line.replaceAll("<string name=\"hello_world\">Hello world!</string>",
"<string name=\"hello_world\">OVERRIDE</string>");
}
// *** SET PATH TO NEW RES ***
buildVariant.processResources.resDir = file("${buildDir}/res/all/${buildVariant.dirName}/values/values/values.xml")
// println "... NEW RES PATH: " + "${buildDir}/res/all/${buildVariant.dirName}/values/values/values.xml"
}
}
The copy and filter task works fine, but I couldn't set the "new" values.xml as string resource.
SOLUTION_2 (just merge the right resources)
define a floavor for specific buildType (e.g. "releaseRes")
merge this resourses with the flavor you want to build:
android.applicationVariants.all{ variant ->
variant.mergeResources.doFirst{
checkResourceFolder(variant)
}
}
def checkResourceFolder(variant){
def name = variant.name;
if(name.contains("Release")){
android.sourceSets.release.res.srcDirs = ['src/releaseRes/res']
android.sourceSets.flavor1.res.srcDirs = ['src/flavor1/res']
}
}

You should strive to come up with a solution that doesn't involve writing any custom code in your build files, especially code that does tricky things with reassigning source sets on the fly. Custom Gradle code is a little funky to write, and it's difficult to debug and maintain. The new build system is extremely powerful and already has tons of flexibility, and it's likely that you can already do what you want; it's just a matter of learning how.
Especially if you're just learning the ins and outs of Android-Gradle projects (and it's so new that we all are), it's best to try hard to work with the functionality built into the system before thinking outside the box.
Some recommendations:
It's unlikely you need to vary resources based on build type. A build type in Android-Gradle is supposed to be something like debug or release, where the difference is in debuggability, compiler optimization, or signing; build types are supposed to be functionally equivalent to each other. If you look at the properties you can set on a build type through the Groovy DSL, you can see the intent: debuggable, jniDebugBuild, renderscriptDebugBuild, renderscriptOptimLevel, packageNameSuffix, versionNameSuffix, signingConfig, zipAlign, runProguard, proguardFile, proguardFiles.
If you still think you want to vary resources based on build type, there's already an easy way to do that with the current build system. You can have a build-type-specific resource directory, put your resources in there, and the resource merging in the build system will take care of things for you at build time. This is one of the powerful features in Android/Gradle. See Using Build Flavors - Structuring source folders and build.gradle correctly for information on how to make that work.
If you want to vary something based on build type and your needs are very quick and simple, you might want to do the switch in Java code instead of resources and instead of in the build system. There's the BuildConfig mechanism for that sort of thing -- it's a Java class that defines a DEBUG flag based on debug/release build status, and you can add your own custom Java code from different build types to do more meaningful things. BuildConfig was intended for allowing small functional differences between build types, for cases where a debug build might want to perform some wasteful operation to assist in development, like doing more extensive data validation or creating more detailed debug logging, and those wasteful things are best optimized out of release builds. Having said that, it might be an appropriate mechanism to do what you want.
Consider using flavors for what you're using build types for now. Conceptually a flavor is kind of like a build type in that it's another variant of your application that can be built; the build system will create a matrix of flavors vs. build types and can build all combinations. However, flavors address a different use case, where different flavors share most code but can have significant functional differences. A common example is a free vs. paid version of your application. Inasmuch as a different resource in different variants of your app represents different functionality, that might indicate a need for a different flavor. Flavors can have different resource directories that are merged at build time in the same way as build configs; see the question linked above for more info.

I don't believe you need to customize the build script at all to achieve what you want. According to my reading of http://tools.android.com/tech-docs/new-build-system/user-guide#TOC-Build-Variants; when the build runs, resources will be merged from the following folders, if they exist;
src/[flavour][buildType]/res
src/[buildType]/res
src/[flavour]/res
src/main/res
So I believe you can achieve what you want by simply add the resources in src/release/res.
Though you can tweak the folder names by specifying the relevant sourceSets.[type].res.srcDirs if you really want to change them.

If anyone stumble upon this
buildTypes {
debug{
buildConfigField "String", "Your_string_key", '"yourkeyvalue"'
buildConfigField "String", "SOCKET_URL", '"some text"'
buildConfigField "Boolean", "LOG", 'true'
}
release {
buildConfigField "String", "Your_string_key", '"release text"'
buildConfigField "String", "SOCKET_URL", '"release text"'
buildConfigField "Boolean", "LOG", 'false'
}
}
And to access those values using build variants:
if(!BuildConfig.LOG)
// do something with the boolean value
Or
view.setText(BuildConfig.yourkeyvalue);