I have several options - both in code and in the manifest file - that I would like to easily toggle on and off based on whether it's a debug build or release build.
What's the best way to handle things like this in an Android application?
You could use properties files, e.g. one for prod and one for dev. Then you could create an Ant script with two targets, a prod build and a dev build, where the appropriate properties file is copied prior to the APK being built. Make sure that the properties files are copied using the same name, then you can access the deployed one, irrespective of the environment you built for.
In addition to what Tyler mentioned, if you are looking at including optional code in case it is a Debug and not having that code if its a release, then you could look at using the BuildConfig file that is generated by the ADT.
As per the docs: " Added a feature that allows you to run some code only in debug mode. Builds now generate a class called BuildConfig containing a DEBUG constant that is automatically set according to your build type. You can check the (BuildConfig.DEBUG) constant in your code to run debug-only functions such as outputting debug logs."
You will find this file in the Project/gen folder, the same place where the R.java is generated.
Now with Android Studio and Gradle it is easy to do this using the auto generated flag BuildConfig.DEBUG. Like:
if (BuildConfig.DEBUG) {
// Debug code
} else {
// Resease code
}
Related
Android studio project
Win10 machine(if it's matter).
Specific project at specific local location.
I need to force https interception on local builds. Making and commiting fix for networksecurityconfig.xml even for dev build is not possible due to non-technical reasons.
making local modification, keep it in stash and never commit is possible but is there other way?
Is it possible to include other versions of specific files (networksecurityconfig.xml) in local builds via global gradle properties) without ANY modifications to project's source code (global gradle config modification is ok, even custom plugins for Android Studio are ok).
Android can automatically replace files based on the BuildVariant and/or Build Type.
E.g. you can use a different networksecurityconfig.xml in your debug builds vs your release builds.
Debug vs Release
In your Debug folder:
src/main/debug/res/xml/network_security_config.xml // debug config
And in your Release folder:
src/main/release/res/xml/network_security_config.xml // release config
This requires no additional setup.
Alternatively, you could create a new BuildType, if you would like to make it more explicit
Build Type
build.gradle
android {
buildTypes {
debug{...}
secure{..}
release{...}
}
}
And place the desired network_security_config.xml in the secure source set:
src/main/secure/res/xml/network_security_config.xml // secure configuration
More information here
In iOS do we have something like Gradle Build Flavors on Android.
Basically I want to integrate Applause SDK with my app but I dont want that code to be part of the release build. I only want to use applause sdk only to distribute the app internally and for bug reporting.
If there is nothing like flavors then what is the best way to do this.
You can make use of Schemes and Build configurations in Xcode. Here's the official documentation: https://developer.apple.com/library/ios/recipes/xcode_help-project_editor/Articles/BasingBuildConfigurationsonConfigurationFiles.html
After you create a build configuration, you should edit your scheme to use that build configuration. For that click on your scheme and select Edit Scheme.
In short, the process is:
Create a build configuration
Set some custom flags for that configuration. For this, go to your target, select Build Settings tab, and search for Preprocessor Macros. There you'll be able to add custom flags
Edit your scheme, or create a new scheme, to use your build configuration.
In your code, you'll have to ask if the flag is available using preprocessor macros:
#ifdef APP_STORE
//do something
#endif
There are several approaches you can take to build an iOS app in different flavors:
Different versions of a resource file
Use a custom build variable to switch between different versions of a resource file. This article discusses how to build an app with different icons.
For *.strings files and resources linked in *.storyboard files the suffixing approach suggested in the first item did not work for me. So I added a Run Script build phase early in the pipeline. Using a script you are free to do whatever you want before the usual build chain handles your files. This is great for dynamic file generation or advanced file selection logic. As a switch you can (again) use a custom build variable.
Modifiying code
Use a compiler flag as suggested here. These can be checked using the preprocessor.
Alternatively you can (again) check custom build variables. To make them accessible add them as a key in a plist file.
I am having two versions of my android project (release and debug). They both are sharing the same source files. I want the debug version to be intact when we checkin any changes for release build.
It is not working as we cant have 2 different manifest files for it and if we make change in manifest, it will affect both the projects and keep them out of sync.
Is there any way we can have different build configurations for same project?
Please advise.
Thanks
If you don't want to impact the debug app when changing the release source files you'll have to use different source files. Having different build files or configuration will not help.
Gradle apps use at least 3 source folders.
src/main/... is used by all variants
src/debug/... is used by the debug variant
src/release/... is used by the release variant
To do a change that only impact the release variant, just edit code in src/release/.... This can contain a manifest, res, java code, etc...
That said I'm not why you don't want to change the debug version when changing the release version. The whole point of the debug version is to be the same as the release, except debuggable. The different source folders above should only be used for minor things (like enabling/disabling log output for instance). Making both versions different in bigger ways is not recommended.
I have an ant build setup for my Android project, and I've been reading guides and tutorials all over stackoverflow and online, but cannot seem to understand how to make this work. Basically in my code I have a variable, "isDebugVersion" (which will print out logs, and a few other things). When I build with ant, I want that variable in my code to be set to "false". I'm looking around and I cannot find the custom_rules.xml examples even though it's listed in the build.xml file.
So the variable is in com.example.application.Globals, and it's listed as isDebugVersion. Can someone please give me an example for how to manipulate this variable using an ant build script?
You can a file named custom_rules.xml to the root folder of your project.
Inside define any property you want.
Note that what you are trying to achieve could be simpler using BuildConfig.DEBUG. This file is in the gen folder of your project, close to R.java. It is generated during the build and the constant DEBUG will be set to false during debug builds and to true in release.
So if you type ant release, you will get false. With eclipse or ant debug, you will get true.
You could also learn how to use RoboGuice, it has an interesting logging solution.
You can use this constant for all purposes like changing the google map api key from debug to release key. For an example, follow this thread.
My project does not enable proguard when creating it. Therefore I need to manually add proguard and enable it via project.properties.
Is there any way I can know whether my application has been obfuscated or not aside from reverse engineering?
If your application has been obfuscated you will see a new folder called proguard in you project folder.
It should contain four text files: dump, mapping, seeds and usage.
Note that your project will not be obfuscated unless you build it in release mode.
Just for records, if you want to check if your code was really obfuscated, you can generate the APK and analyse it in this webpage: http://www.javadecompilers.com/apktool
You can check using Android Studio as well by generating the APK and later going to Build -> Analyze APK... -> select your APK to analyze.
I hope this help.