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.
Related
Is there a way I can get the hierchary view/layout of other running android apps? If that's not possible, could I possibly unpack the app's .apk file and get the information there? For example, there's a setting in developer options that allows you to get the bounds of every elememt on the screen like so
EDIT
I have come to realize that this is not allowed and goes completely against the Android SDK. I apologize for this error and will look more closely in the future.
I have found out that Google blocks any of this because it would require me to inject my own code into other apps, which is not allowed due to malicious behavior in past apps.
I've seen plenty of ways of getting system logs in Android with logcat and the like, but not so much about app logs (except for the usual USB + adb solution).
My B2B Android app produces useful logging created with Log.i calls. Whilst in Studio these are very useful for debugging, it would also be useful to get these from customer's installs when things go wrong, i.e. from a release build out in the wild. Customers are generally not techies so getting logs via adb isn't really an option.
Is there a way within the app code itself to grab all the log contents?
Perhaps the SDK provides a way to do this?
I could then send that to my server or by email. I'm thinking it'll be useful for my customers to just hit a button so I can get an instantaneous snapshot of what is happening in the app.
Thanks in advance
UPDATE
There doesn't seem to be a way to do this, aside from writing to a file and sending that file. Which I guess is a good a solution as any.
Two other interesting ones that have come up are:
Firebase (from Mohammed's comment) - can log events:https://firebase.google.com/docs/analytics/android/events
Instabug
we can write write logs to file using java.util.logging.Logger API.
How to write logs in text file when using java.util.logging.Logger
Check out here for writting crash log to a file
My question is, when we use Log.d(), Log.v(). Are these visible on android screen as output or do they just remain in the background and Android Mobile just display what the emulator displays in Computer?
Logging is just something, that enables developers the possibility to check if his code is working like it's intended to be, the user won't see any of the log statements. But it's recommended to remove all logs before publishing your App:
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. You can
disable debugging by removing the android:debuggable attribute from
the tag in your manifest file, or by setting the
android:debuggable attribute to false in your manifest file. Also,
remove any log files or static test files that were created in your
project.
Source here.
No, this is purely a background thing, viewable with the LogCat view in Eclipse. The user will not see anything Log related, they will be oblivious to it while using the app.
So yes, it will display what your emulator displays. Of course if you need them to see something, you can show Toasts and Dialogs. However, make sure to take out Log statements in release versions of your app. People that have debugging enabled will be able to see your statements if they attach their phone to a computer and run LogCat.
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.)
Please note, unlike many other questions having the subject title "application has stopped unexpectedly", I am not asking for troubleshooting a particular problem.
Rather, I am asking for an outline of the best strategy for an Android/Eclipse/Java rookie to tackle this formidable task of digesting huge amounts of information in order to develop (and debug!) a simple Android application.
In my case, I took the sample skeleton app from the SDK, modified it slightly and what did I get the moment I try to run it?
The application
(process.com.example.android.skeletonapp)
has stopped unexpectedly. Please try
again.
OK, so I know that I have to look LogCat. It's full of timestamped lines staring at me... What do I do now? What do I need to look for?
Is there a way to single-step the program, to find the statement that makes the app crash? (I thought Java programs never crash, but apparently I was mistaken)
How do I place a breakpoint?
Can you recommend an Android debug tutorial online, other than this one?
I'm an Eclipse/Android beginner as well, but hopefully my simple debugging process can help...
You set breakpoints in Eclipse by right-clicking next to the line you want to break at and selecting "Toggle Breakpoint". From there you'll want to select "Debug" rather than the standard "Run", which will allow you to step through and so on. Use the filters provided by LogCat (referenced in your tutorial) so you can target the messages you want rather than wading through all the output. That will (hopefully) go a long way in helping you make sense of your errors.
As for other good tutorials, I was searching around for a few myself, but didn't manage to find any gems yet.
Filter your log to just Error and look for FATAL EXCEPTION
If you use the Logcat display inside the 'debug' perspective in Eclipse the lines are colour-coded. It's pretty easy to find what made your app crash because it's usually in red.
The Java (or Dalvik) virtual machine should never crash, but if your program throws an exception and does not catch it the VM will terminate your program, which is the 'crash' you are seeing.
Check whether your app has the needed permissions.I was also getting the same error and I checked the logcat debug log which showed this:
04-15 13:38:25.387: E/AndroidRuntime(694): java.lang.SecurityException: Permission Denial: starting Intent { act=android.intent.action.CALL dat=tel:555-555-5555 cmp=com.android.phone/.OutgoingCallBroadcaster } from ProcessRecord{44068640 694:rahulserver.test/10055} (pid=694, uid=10055) requires android.permission.CALL_PHONE
I then gave the needed permission in my android-manifest which worked for me.
From the Home screen, press the Menu key.
List item
Touch Settings.
Touch Applications.
Touch Manage Applications.
Touch All.
Select the application that is having issues.
Touch Clear data and Clear cache if they are available. This resets the app as if it was new, and may delete personal data stored in the app.