I want to build an apk and inside it I need to use release aar inside it.
The aar must be release build since I need to shrink and obfuscate it.
But I would like to print the log for network log to see if my obfuscation will not bother the request payload.
I tried to use System.out.println, but I could not see any log from aar.
Any suggestions?
You can use gradle build config field to enable/disable log print.
Default value for Gradle buildConfigField boolean used across flavors
First create a log wrapper function with a boolean parameter, true means enable log print. And then you can create an init funtcion for your aar, in which you can set log enable parameter.
Meanwhile define a build config field in your app.gradle:
debug {
buildConfigField "boolean", "ENABLE_LOG", "true"
}
release {
buildConfigField "boolean", "ENABLE_LOG", "false"
}
Then just call aar.init(BuildConfig.ENABLE_LOG) on Application.oncreate()
You should be able to turn it on in the manifest/build.gradle. Enable LogCat on Release Build in Android Studio
There have been a few changes to it over the years so you may have to look at more than the accepted answer.
You can also use this library https://github.com/tony19/logback-android
It can create log files on the device, that you can open and inspect.
Related
I know we can edit build types in Android Studio:
I know we can edit each build type setting in gradle:
android {
buildTypes {
release {
minifyEnabled true
}
}
I know we can detect build types in code. How do I detect if I am in release or debug mode?
But where actually are the build types defined? Let say I want to commit it to git. What should I do to keep build types of the project consistent?
Where actually are the build types defined?
Basically, BuildConfig is the auto-generated class that resides under path :
app/build/generated/source/buildConfig/yourBuildType/yourPackageName/BuildConfig.java.
This class holds variables provided by buildTypes {} block from app level build.gradle file. So, on every clean & rebuild of project, Gradle auto generates BuildConfig class that can be used in further Android development environment.
I.e. BuildConfig.DEBUG is the default variable that we can use in our application code to determine it's buildType.
We can provide our own fields through buildType from build.gradle file like following:
android {
. . .
buildTypes {
debug {
buildConfigField "String", "SOME_VARIABLE", '"This string value is from build config class"'
}
}
. . .
}
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";
I am developing an Android application that interacts with server via REST APIs. Obviously I need to use different URL for development and release builds. Commenting and un-commenting code is very tedious and error pron.
Which is the best way to handle this situation? Using different build types in gradle file is one which could automate the process, but I am not sure if this is the right way to go.
There is also a possibility of increase in number of build types viz. test, internal-release etc.
If you are using Android Studio, use buildConfigField to add custom fields to your BuildConfig class.
buildTypes {
debug {
buildConfigField "String", "SERVER_URL", '"http://test.this-is-so-fake.com"'
}
release {
buildConfigField "String", "SERVER_URL", '"http://prod.this-is-so-fake.com"'
}
mezzanine.initWith(buildTypes.release)
mezzanine {
buildConfigField "String", "SERVER_URL", '"http://stage.this-is-so-fake.com"'
}
}
Here, I have three build types: the standard debug and release, plus a custom mezzanine one. Each defines a SERVER_URL field on BuildConfig.
Then, in Java code, you just refer to BuildConfig.SERVER_URL. That field will have a value based on what build type you used to build that particular edition of the app.
It can be managed by using ProductFlavours in app build.gradle. ProductFlavours will manage different URL ie. development and release.
Please have a look it on medium.
It involves detailed explanation.
I had a similar issue and I solved it using
if (BuildConfig.DEBUG) { }
You will need to import
import com.commandsoftware.androidbookingapp.BuildConfig;
I had a similar problem with writing to logcat. I wanted to write all the messages if the app was signed with the debug key, otherwise write almost none of them. I solved the problem with this line of code:
boolean showAllMessages = ((getApplicationInfo().flags & ApplicationInfo.FLAG_DEBUGGABLE) != 0);
then using that boolean in my log writer. You should be able to do something similar when you initialize the URIs.
I am using Eclipse. I can't say with certainty that this will work in other IDE environments. This answer implies that it might be an Eclipse-only feature
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.
I have parts of my app that I don't want to run if we're running Android unit tests, so I want to surround them with something like
if (!BuildConfig.TESTING) {
// Code here that I don't want to run during tests.
}
Is it possible to populate this BuildConfig flag depending on whether the connectedAndroidTest gradle task is used? Is this a sane way of approaching this problem?
This might be a little late, but oh well. Yes you can set BuildConfig fields through your app's gradle file, these will be initialized at build time. For example, I could save a debug flag through gradle like this:
buildTypes {
release {
buildConfigField "boolean", "debuggable", "false"
}
debug {
buildConfigField "boolean", "debuggable", "true"
}
}
And the through code I could access the value like so:
if (!BuildConfig.debuggable) {
Log.i(TAG, "Application is not Debuggable");
}