Develop Reference

avoid login when redeploying on Android Emulator

Trying to speed up my manual testing on Android Emulator by not having to login and navigate to a specific page every time I deploy a new apk to the emulator. Need to make sure that a careless developer on the team cannot accidentally deploy a release to play store that allows skipping login (e.g., don't just uncomment code to skip login).
Current approach:
Create product flavors "normal" and "skiplogin" (no attributes).
Where code grabs REST API credentials from SharedPreferences add this:
if (BuildConfig.DEBUG && BuildConfig.FLAVOR.equals("skiplogin")){
// use hard-coded username/token
}
pros - it works. greatly reduces time spent click testing
cons - "gradle clean build" takes twice as long when you have two flavors. Does not work on pages that depend on state that is fetched on previous activities/fragments, such as data fetched only at login.
Gotta be a simpler way, who knows it?

If what you want is that the code don't run on release why don't you instead use BuildConfig.DEBUG?
if (BuildConfig.DEBUG && BuildConfig.mockLogin) {
// use hard-coded username/token
}
and in your gradle define
buildConfigField('boolean' , 'mockLogin', 'true')
in the case that the code makes it to production it won't run cause BuildConfig.DEBUG it's false when you do a release build, and you can't upload a debug build to play store cause it won't allow it.

How to work Flurry with debug mode on Android.?

I am using Flurry analytics for tracking apps behaviours. A lot error is thrown while App is developed, I can find and fix that error on Android console however these errors are uploaded to Flurry Console and They are confusing me.
I used below codes to intercept these but This time Flurry doesn't work at all.
if( !BuildConfig.DEBUG ){
// configure Flurry
FlurryAgent.setLogEnabled( false );
FlurryAgent.init( this, MY_FLURRY_APIKEY );
formValidationHelper = new FormValidationHelper();
}

What your code is doing is preventing Flurry initialization in debug mode, which, I assume, is not what you want to do. If you want the SDK to work in debug mode, you should still call FlurryAgent.init(Context, String).
There are several ways to do this. The definite way is to create another Flurry API key for your debug development and use your main API key for release.
If you want to remove Flurry crash-reporting altogether, you can do that using FlurryAgent.setCaptureUncaughtExceptions(boolean). The default for this setting is true so Flurry will send crash information to the dashboard. You could, of course, leave it as default when releasing your app, but can turn it off during development.
Here's a snippet showing what I mean about using different API keys and disabling crash-report in debug mode:
if (BuildConfig.DEBUG) {
FlurryAgent.setLogEnabled(true);
FlurryAgent.setCaptureUncaughtExceptions(false);
FlurryAgent.init(this, FLURRY_DEBUG_KEY);
// Other debug setup
} else {
FlurryAgent.setLogEnabled(false);
FlurryAgent.init(this, FLURRY_RELEASE_KEY);
// Other release setup
}

Disable GoogleAnalytics from Android App when testing or developing

I'm using EasyTracker in my Android App and I need a way to disable Analytics tracking when the app is in "development" or "testing" mode (I have a flag in a constants file to discriminate).
What's the best way to do so?
Thanks!

I believe the correct way to do this with Version 4 of Analytics is with the Opt Out method
GoogleAnalytics.getInstance(this).setAppOptOut(true);
You could set that method to be set if you build in debug mode. ie.
GoogleAnalytics.getInstance(this).setAppOptOut(BuildConfig.DEBUG);
I am using something similiar to allow users to opt-out of analytics.
I found this information at he following link: https://developers.google.com/analytics/devguides/collection/android/v4/advanced
Edit: Just saw the date of the original question, but thought I would add this answer anyway as it was something I was looking for.

UPDATE: With release of Google Analytics v3 for Android,
The SDK provides a dryRun flag that when set, prevents any data from
being sent to Google Analytics. The dryRun flag should be set whenever
you are testing or debugging an implementation and do not want test
data to appear in your Google Analytics reports.
To set the dry run flag:
// When dry run is set, hits will not be dispatched, but will still be
logged as though they were dispatched.
GoogeAnalytics.getInstance(this).setDryRun(true);
+++ My old answer +++
Just comment the following line in your analytics.xml file while you are in development mode.
<string name="ga_trackingId">UA-****</string>
Google Analytics wouldn't be able to find any tracking id, so EasyTracker won't be able to do its job.
When you are building the app for release, uncomment the line and you're good to go.

If you are building a standalone app(not a library), this will be the easiest way to do it, let the build system figure out if it is a debug build or not.
if(BuildConfig.DEBUG){
GoogleAnalytics.getInstance(this).setDryRun(true);
}
I see on the web that this method does not work well for library projects as there is bug in the build tools which does not set the BuildConfig.DEBUG flag correctly for libraries. Not sure if this issue is fixed now.

You can use a class with a static boolean value let's say DEBUG like this :
public final class BuildMode {
public final static boolean DEBUG = true;
}
In code, just use :
if (BuildMode.DEBUG) ...
This is a solution working on all android SDK versions!

Newest version from firebase has this method that can be put inside App class:
FirebaseAnalytics.getInstance(this).setAnalyticsCollectionEnabled(!BuildConfig.DEBUG);

What I'm doing is disabling periodic dispatching, by setting a negative period, in analytics.xml:
<integer name="ga_dispatchPeriod">-60</integer>
or you can do it programmatically, using your flag:
if (testingMode) {
GAServiceManager.getInstance().setDispatchPeriod(-1);
} else {
GAServiceManager.getInstance().setDispatchPeriod(60);
}
That way hits are not sent unless you do it manually.
That should work if you are using only periodic dispatching (never calling .dispatch() manually). Hits not sent before 4 a.m. of the following day are somehow discarded, I guess, as they are not appearing in the reports anyway.
See in Google Analytics Developer Guide:
Note: Data must be dispatched and received by 4 a.m. of the following day,
in the local timezone of each profile. Any data received later
than that will not appear in reports.
More info: https://developers.google.com/analytics/devguides/collection/android/v2/dispatch

My technique is to change the android:versionName in Android Manifest until release time.
For example, 1.0.0.ALPHA until time to build a release APK, at which point you could change to 1.0.0. This way you can still see all of your crash reports later, but they will grouped in analytics.
This SO ticket talks about using the BuildConfig.DEBUG flag to conditionally configure analytics and Atul Goyal's answer references the dryRun flag in v3. Those two things could be a nice setup if you don't care about seeing crash reports during debug in the future, and assuming that the BuildConfig.DEBUG flag works correctly.

I have a different approach to this issue. Sometimes you still want to test that analytics is working correctly, but want to just filter test data out in production reports. My solution to that is to create a custom session-scoped dimension (i.e. AppBuild), in GA for the property which tracks if you are running a debug or production build of the app. In your code after you create the Tracker, put:
// replace 1 with the correct dimension number if you have other dimensions defined
tracker.set("&cd1", BuildConfig.DEBUG ? "debug" : "production");
Then create or modify your GA view to add a filter on AppBuild, excluding debug. This should filter out all debug data from your GA view. You can also add a new view to show debug data.

Ways to dynamically enable/disable debug features in an APK

I'm developing an APK. I'd like to be able to set and unset various options for debugging purposes. For example:
Enable a time profile trace
Enable some experimental feature
Enable very verbose output to logcat
...
Currently, we do this by creating a flag in our code for each feature and set/unsetting it. However:
is time consuming because of the need to rebuild, upload and relaunch the APK
runs the risk of people accidentally checking things in in a debug mode state
requires a rebuild of the APK -- we can't ask our customers to enable a debugging feature and report the results.
Is there a pattern that Android developers follow solve this kind of problem?
In the past, we've used environment variables for this purpose.

You may use the debugging permission SET_DEBUG_APP in your apk. Create a new class called
class MYLog {
i(String Tag, String msg) {
if(LOG_ENABLED){
Log.i(TAG, msg);
}
You may call the MyLog.i instead of Log.i(). You may get the LOG_ENABLED value from the server to enable/disable logging.

I'd consider doing it one of two ways, depending on how much of this feature you want to expose to your users:
Key the debug features off of SharedPreference values, and expose them in a preferences/debug menu in the UI.
Use the presence/contents of a file in external storage where you can email the file to & instruct an end user where to place it to enable the debug features.
Option 2 is not much different a notion than using environment variables.

Logging strategy

I'm about to finish my Android application. In the end I have found that I've been using bunch of logging statements, like:
Log.d(TAG, "Blah-blah");
The question is: for production release what should I do with them?
Just comment/stripe log statements
Do something else more sophisticated? Like as I used to do with Log4J properties or so
Please share your experience.

You can remove the logging statements in build time using an obfuscation tool. See here for details.

There is a new project, which enables log4j on android. Using lo4gj over slf4j is possible. It also provides an appender for LogCat. See project android-logging-log4j or log4j support in android

I have created a library for this specific purpose. It can be found here - LumberJack. You can install it using Jitpack and gradle (Please check README.md).
After installing, you'll have to change all Log calls to LumberJack calls (eg. LumberJack.d() instead of Log.d() etc.)
Tags are optional and by default set to "LumberJack". You can choose to set the default tag yourself.
You can change the filtering anytime using LumberJack.setLogLevel() method. To remove all the logs, you can just set the LogLevel to LogLevel.None.
LumberJack.setLogLevel(LogLevel.None);
So if you just want to remove all the logcat spamming logs, you will just have to set the log level filter.
Optionally you can choose to log into a text file instead of logcat with same filtering mechanism.

I do it like this, making the compiler remove all logging if DEBUG is false:
if (Constant.DEBUG) Log.d(TAG, "mein gott, state is roflcopter");

Depends. If you expect the application to crash often then include one of the crash reporting libraries for example but whatever you decide to do just don't release it with the Log.d() methods.

I've not experience on Android specifically but I'd just leave the logging staements in the code and turn off logging in the log4j properties file. You might even want to leave some logging turned on so that your app will generate useful logs in the event of a crash.
If you are worried about the log statement generation being too computational intensive (e.g. calling toString on a big collection) then you can use this pattern.
if (Log.isDebugEnabled()) {
Log.Debug(bigCollection.toString());
}

If you do not want to log something in Android release version, you can use automatically generated BuildConfig. See more about it here: https://developer.android.com/studio/build/gradle-tips.html. You can also read more information in this question: BuildConfig file in android - Purpose and Possibilities.
So in your code you simply write something like this:
if (BuildConfig.DEBUG) {
//your code just for development goes here
}