Develop Reference

Why android device id change when i am debugging?

We have and old App Works perfect in all devices for all this years, except in a New Samsung Note8.
The problem is that Android Studio change the DeviceId of this Smartphone without any reason, Seems to be imposible, but it's true.
Every time that we debug our APP, the Deviceid Change.
This is an important problem for us, because we use this ID for to control our licenses.
Any Idea?
PD: Still can´t belive it!

DeviceId changes if you change the signature of the application
I.e if you are making your 1st release and then you try make another release with the new key.jks then you will find the
DeviceId in 1st release is different then the DeviceId in second release
Conclusion :- always generate signed APK with the same key.jks

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
}

In app purchase testing in alpha mode it is possible?

It is compulsory for checking inappbilling to original publish mode if no than if i set apk in alphatest mode than after how many hours i can check my inappbilling with same code running from eclipse.
I have tried with publish apk in original mode and than check it is work but if i want any change than again i am waiting fo 5 to 6 hour for new apk with change.

I don't think that you can test in-app purchase without publishing the app. and also you can't check in-app billing running code from eclipse. it will give you an error code =3;
which means error_not_Market managed. To check it you have to download the app from app store and run.you may use the log cat to get the response. so don't forget to put necessary logs in your application.

Yes.
Implement the LicenseCheckerCallback and
if you are getting the error code 3, ie ERROR_NOT_MARKETMANGED, just for testing think that you have successed and call the function allow() from there. Ie if(errorCode==3){ allow(int reason)}and int the implementation of the function allow() write the code for success.
don't forget to remove this before publishing.

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.

Android: Make the app logs my logging statements "only"

I am planning on signing an apk and releasing it (through Export Eclipse tool). Then upload it to the market. I know that debuggable is set to false by default when signing it so that means that no logs will be captured. At the same time, if I set debuggable to true and release the apk then I will get all the logs.
What I am really interested in is the last debug statement that are added by me only. Currently, I am using the Log.i statement to add info logs. Is there a way to have my app logging only the Info logs (i.e. my logs only). Mybe if I disable the log and have system.out.print it would work?
The reason I am doing this is becuase I want to send the last 100 lines of log when a crash happens and I am only interested in my log statments.
Please help me out
Thanks

I believe what you need to do is take advantage of ACRA's built in filtering functionality:
In the Advanced Usage wiki you can see that you can set your logcat arguments in your config.
In your logging, tag your custom log messages with a specific tag and debug level, then in the logcat arguments, then set a parameter:
logcatArguments = { "-t", "100", "-v", "long", "ActivityManager:I", "MyApp:D", "*:S" }
add one in the form of
"YourCustomTag:<YOUR_DEBUG_LEVEL>"
and take out the ones you don't want to be logged (probably MyApp:D in this case.)

You will have to put a wrapper on top of Log where you can put functionality to control the log levels.

This type of functionality is already implemented by the ACRA Android library. The library detects crashes, and send the crash information to either a Google Docs spreadsheet, or your own destination. You can add additional information like the past 100 lines of your log using the method shown here.