We usually put logs to check if some code block executes or not.
But we generally don't remove it before publishing the app.I don'y know about other but i have fond of that feature and using it fluently in my apps.Can any one tell me that what will be the effect on system memory of writing any of the Log.x() (where X=v,e,w,i,d) forms.
Do anyone help me clear some concepts?
Definitely there will be a lot of effect on Memory usage, APK file size and Performance.
Besides, You must remove all the Logs before publishing the app.
Of course, once you remove all the Logs and publish it, its pain to rewrite them.
Hence use Proguard which removes all the Logs from the ByteCode, but doesn't effect the source code.
Apart from removing Logs, Proguard helps in performance enhancement by Obfuscating you code, removing unused methods, variables etc.. All that depends on how you configure it.
Enabling ProGuard in Eclipse for Android
How to avoid reverse engineering of an APK file?
The logs get saved in memory.thereby consuming memory space.We should remove the debug logs before releasing ,Only error logs should be there.
YES Definately.
And To make Logs efficient always try to use a Boolean flag like:
boolean debug = true or false;
and wherever you use log.d("ClassName","message"); write it as
if(debug) log.d("ClassName","message");
and so you can manage the logging(Logs) with a single Boolean flag.
thanks.
It depends on how many logs you use. Surely it will affect the application.So before releasing app, use this.
android:debuggable="false"
Related
First - I am not trying to actually obfuscate my code, only optimize and shrink.
I have checked android developers site, I have looked through proguard documentation and I've googled for a few hours. But I still can't find a definitive answer - how do I actually test that my application keeps working after being "proguarded"?
There is a way to export it, install manually onto emulator, then run, see if it works, fix something (sometimes in proguard configurations, sometimes in code), re-export, re-install. That's a bit tedious.
Shrinked and optimized application is a totally different thing from the application I've tested. I can't be sure it will work properly with such changes until I actually test it. Not being able to actually test the application I'm going to publish means I'm publishing untested application. Which isn't something I'd want to.
And while I can stay away from the proguard, it does reduce my application's size significantly which isn't something I can ignore.
Edit: I understand now that to test application I just have to run acceptance tests on exported package. But there is still the question - how do I test my proguard configuration?
The same way you tested it before you processed it with ProGuard. You'll find that once you get your configuration right the end result will just need one final test to confirm things before deployment.
But I would obfuscate, which reduces size quite a bit and avoid optimizing which I have had introduce bugs a number of times over the years.
I am developing an android application where i am using a lot of Logs for printing values at console for debugging purpose. Now i am using Log.i() method in Android. Now actually what the problem , before i have to give to testing team, i have to remove all logs. When the number of classes in the project is small, i can remove it manually. But when the project contains 40 to 50 classes, it is humanly impossible to go to all classes and remove it manually. So is there any settings is availaible in eclipse so that i can remove or disable all logs by changing a single settings or configuration or else is there any jar file that helps for debugging much more easier than Log.i() method. Any suggestion or guidance is highly appreciable
Thanks inAdvance
the logs will be kept on the phone and any user/developer can check them out by installing apps like Catlog even without using adb! This is a problem as you stand to give unnecessary and at times, confidential data to users/other developers.
Simple way to solve this?
a. Use Proguard to automatically block all logs, more information in this stackoverflow thread
Here you can automatically block all logs at the bytecode level in Proguard
-assumenosideeffects class android.util.Log {
public static int v(...);
}
The above, for example would remove any verbose logging, more in this thread
b. I use a if(DEBUG) Log.i for all my logs, so that with one change of the boolean DEBUG i can switch on/off all logs
This answer referred from this link
Android hide logs in the application when upload to market
Why and when should I use the android Logging? Should it be used only for debugging purposes? It seems to me that if kept in a production application, it would slow it down considerably.
One key part of my question, is WHEN it should be used...in what cases should I need it? Are there any 'best practices' for using this?
This may be a very stupid or amateur question, but I've never understood the need or felt compelled to use it. I may be missing something.
http://developer.android.com/reference/android/util/Log.html
Also - I already know that logging for errors/verbose/info/etc are different, and some are discarded when not debugging. Please don't reiterate the information that's in the class overview without giving me an explanation why. Thanks!
I agree with you, I never really used it either. I much prefer debugging over log reading (and unit-testing over debugging), when trying to figure out what's happening and getting an error.
Some people argue it can be useful to log "additional details" when your application crashes and get an exception, but I usually reply to them that the exception itself should hold that additional details when necessary, and expose them in its getMessage. Thus, the default stack trace that's included in the LogCat is more than enough to see what's going on.
But anyway, it's always nice to have the possibility to log something, even though I haven't found it really useful so far, you never know when it might help :)
Regarding my comment, see Preparing for Release. (Showing logging should be removed before release, hence not being used in production).
Turn off logging and debugging
Make sure you deactivate logging and disable the debugging option before you build your
application for release. You can deactivate logging by removing calls to Log methods
in your source files.
I used logging the other day, I fired off another thread to do some work but I needed to check some data being produced in the thread, without logging or displaying Toast's, how could I get the values? I'm tried debugging/stepping through code in Eclipse before and just run into several problems.
With logging, I can log each value, view the logcat and know exactly what my code is doing.
You usually debug only when you know there is something wrong. (And when you know, you might write additional test cases.)
With logging (at the INFO level, for example), you can add some additional information to trace the data in the app. This allows you to find out that there is something wrong.
Thus, it adds a higher-level overview.
Additionally, it can be easily disabled, does not slow the app down significantly (if done right), and might thus offer another avenue of approach to see if everything works correctly, with few disadvantages and some advantages. (See also Logging vs. Debugging, especially the links in #smonff's answer.)
I've been using Log.whatever() calls to Log various bits of information as I've been developing my Android app. As I prepare to publish my app to the Android Marketplace, I'm trying to figure out what I need to remove.
According to the Android developer Dev Guide, before publishing, they suggest:
Deactivate any calls to Log methods in the source code.
How does one deactivate the Log methods? Obviously I could go through and erase them all (which is a bit of a pain) but is there some other way to deactivate Log calls that I'm unaware of?
Also, what danger is there to having Log calls in a published application? Can anyone install Eclipse, plugin in their phone and enable Debug mode and see all the same LogCat information that I see as I'm developing?
Also the Dev Guide suggests:
Remove the android:debuggable="true" attribute from the <application> element of the manifest.
I was unaware of this flag until now. What does it do exactly? I've been developing and debugging my app just fine up to this point and this flag is not set to true or false for in my Manifest.
Yes, anyone can install the Android SDK (with or without Eclipse) to view all log messages on your device.
I don't recommend completely removing your logging code, but instead wrap it, such as: if (DEBUG) Log.d(...) where DEBUG is some static boolean you define in a convenient place. I prefer to create a utility class so that all log calls across various classes can be enabled/disabled at once.
Simplest chnages for that would be to define one custom Class say MyLog, now replace all the calls of Log.d() to MyLog.d().
Now inside your class you can have one flag that can enable or disable logs.
hope this helps.
A good practice is to use something like if (DEBUG) Log.whatever, and then simply make DEBUG false.
There is no real danger except that you may expose some underlying implementaion which may expose glitches and hackable points in you app. The real problem is the performance penalty that you will get from logging too much.
As for android:debuggable="true", search for it in here
Finally, yes, Logcat logs are global and can be seen by anyone using the Android SDK.
Yes logs can be seen by anyone. Not only that, apps can collect logs programmatically: http://www.cuteandroid.com/five-android-logcat-related-open-source-apps-for-developers
So make sure you don't expose sensitive data as many apps collect logs - mine do in case of unhandled exceptions / crashes.
Yep, most certainly. Everyone can see them.
If you don't want that to happen, delete them from your code. It's quite normal though. I see a lot of apps using logs, and odds are that almost none of your users will be using that to check your logs.
I would recommend not wrapping your Log statements; depending on the size of your application that could take a while, will probably result in a fair bit of extra code and is just a hassle IMHO.
Instead I found configuring Proguard to automatically optimize your code and strip out Log statements when exporting an app release to be much easier. It will also obfuscate specified areas slowing down any reverse engineers that are trying to break your app.
If you do decide to go with Proguard you can put something like the following in your proguard-project.txt file to strip out log statements.
-assumenosideeffects class android.util.Log {
public static boolean isLoggable(java.lang.String, int);
public static int v(...);
public static int i(...);
public static int w(...);
public static int d(...);
public static int e(...);
}
I wonder if it is a "good coding" to use log.d very often in my app?
Should I include a checkbox to manually activate logging or is it okay to do it everytime the app starts? I know the normal user doesn't see it, but I guess as it is not stored in a file (or is it?) no write cycles would be wasted.
What would you say?
Thanks for helping...
Read this.
Or quote:
Before you consider your application ready for release:
1. Test your
application extensively on an actual device
2. Consider adding an End
User License Agreement in your application
3.Consider adding licensing
support
4. Specify an icon and label in the application's manifest
5. Turn
off logging and debugging and clean up data/files
I agree with the point you have mentioned. As a developer its good to have log for application.
My suggestion would to have some logic to remove log related lines on compilation i.e Tag.
what`s your view on this.