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.
Related
I have a user who I've diagnosed to have object-box-related issues. I can send him debug builds with the ObjectBox debug flags (debugFlags(), debugRelations(), etc...) turned on. However, I would like to redirect the object box logs to a callback where I can collect the data and save to a file. Is this possible in ObjectBox?
Logs are currently created from native (C++) code, so there is no way to redirect them. But I agree a custom logger is a good idea (e.g. to log to an error report file on production builds).
If you have time, please create a feature issue for it at https://github.com/objectbox/objectbox-java/issues.
What I am going to described has been tested with a 2.3 and a 4.4.2 devices, having exactly the same behaviour, so I isolated any potential issue coming from the change in access rights to LogCat.
I am using ACRA version 0.4.5
What I would like to do is very simple, make sure that I can send to the ACRA report at Cloudant the Logcat of the device filtered by my application name.
In order to perform this I followed the manual and some previous posts in SO (like this one: How to filter logcat output in ACRA?)
Ideally I should include in the configuration the following input:
logcatArguments = { "-t", "100", "MyApp:D", "*:S" }
However, this is not working properly and no error report arrives to the database, only 2 lines appear with an empty report. In order to ensure that there are logs I forced a LogCat output just before the forced calling, something like this:
Log.i(TAG + ":Sending Error or Suggestion", "My message ");
ACRA.getErrorReporter().handleException(null);
If I change (both devices) any of the following lines at the ACRA configuration:
logcatArguments = { "-t", "100", "MyApp:D"}
logcatArguments = { "-t", "100"}
I am getting the full report from LogCat without any filtering. I also tried including the -v long option (just in case).
Reviewing all answers in SO about this topic I found all of them outdated as I have not been able to explicitly find one related to this problem and the version 0.4.5.
Any idea what's happening?
======
CLARIFICATION
After some investigation the problem is not so simple.
Currently all documentation available provides example of how to filter in ACRA using TAGs and at the moment is not clear how to filter by Application as in Eclipse.
So if you are experiencing the same error as me probably will be due because (as the answer provided to this question suggests) you are not using exactly the same TAGs in all your Logs.
ACRA just provides those arguments directly to logcat. So you question is really, how do I filter logcat.
The logcat filters are everything after the params.
Filter are of the form <tag>:<log_level>.
If you specify a log_level of S then you are marking those messages as silent, ie don't show them.
So in the config in which you are getting no messages:
logcatArguments = { "-t", "100", "MyApp:D", "*:S" }
You are asking for all message logged with tag MyApp and to ignore all other messages. Since you are getting no log I would suggest that you have not actually used MyApp as a log tag within your app.
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.
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.
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
}