Task #2434
closed
Task #1989: Basic NFD control app for Android
Log output inside NFD control app
Added by Alex Afanasyev almost 10 years ago. Updated over 9 years ago.
Description
Design and implement component to display nfd and nrd log output (these will have special prefix, but I need to be refreshed on how log output can be filtered in this component).
This first require a skets of UI and specifics on how android logs can be filtered.
Files
| logger.png (195 KB) logger.png | Ivan Yeo, 02/28/2015 01:28 AM | ||
| log_pref.png (64 KB) log_pref.png | Ivan Yeo, 02/28/2015 01:28 AM |
Updated by Alex Afanasyev almost 10 years ago
- Related to Task #2433: Customization of NFD codebase to use native android logging added
Updated by Alex Afanasyev almost 10 years ago
- Project changed from ndn-embedded to NFD-android
- Category changed from Android to jni
Updated by Ivan Yeo almost 10 years ago
Oh, this part should be straight forward. If I remember correctly the log filter is Native. Let me look into this and update.
Alex Afanasyev wrote:
Design and implement component to display nfd and nrd log output (these will have special prefix, but I need to be refreshed on how log output can be filtered in this component).
This first require a skets of UI and specifics on how android logs can be filtered.
Updated by Ivan Yeo almost 10 years ago
- % Done changed from 0 to 80
Filtering is done by the application's package name. This can be achieved using the onboard logcat that comes on the Android. For instance, if the package name is: net.named_data.nfd, then the logcat command can be:
logcat net.named_data.nfd:V
This verbose output can then be piped to the UI. Example proof of concept implementation can be found at:
http://gerrit.named-data.net/#/c/1761/
If this is what you were looking for, then the final steps would be to clean the code up for maintainability.
Updated by Alex Afanasyev almost 10 years ago
Yes. This is what I wanted. UI-wise, this should be a separate activity with ability to select specific verbosity level and (may be) specify additional filters.
Updated by Alex Afanasyev almost 10 years ago
(Duplicate of the gerrit comment.) I haven't noticed originally that you were referring to logcat command line tool. Are you sure Android does not provide API to access log events without resorting to running process and redirecting output. I have reservations against running any command-line tool from inside the app.
Updated by Ivan Yeo almost 10 years ago
- Status changed from New to In Progress
Hi Alex,
1) Yep, no worries with the UI, that can be done.
2) This is a repeat post from Gerrit so that it is logged here as well:
In most of the commercial and open source projects that I've seen, this is a technique that is commonly used. There are a few open source apps on the app store that use this technique as well.
Tracing the source code of the Log class that is normally used for logging, it pointed me to a native code called println_native(), which then writes to the Linux Kernel's /dev/log. I looked around for other APIs on the system, but haven't found one yet.
The other system that is used for doing logging is the Java's logging mechanism. This is usually done for custom logging where there is a paradigm of a log producer and a log consumer. However, I've had developers running into issues when using this on earlier versions of the Android. I'm not too sure what the state is of now, but I'm pretty sure this is not what we are looking at as we're trying to pull logs from the app and the native code -- which is what logcat is able to provide us now with filter as well.
I'm curious as to what other solutions there is out there. Let's keep a look out for other possibilities, moving forward with this one. What do you think?
Updated by Alex Afanasyev almost 10 years ago
Can you give some references for use of logcat in applications?
Updated by Ivan Yeo almost 10 years ago
Hi Alex,
Here are some app store apps that uses logcat through Processes:
These are the apps that use the logcat in their applications:
https://github.com/nolanlawson/Catlog
https://github.com/thomashultgren/android-request-log
Other apps on the app store:
https://play.google.com/store/apps/details?id=org.jtb.alogcat
https://play.google.com/store/apps/details?id=jp.gr.java_conf.score.LogCat
Here's some documentations from the Android developer site for your convenience and kind perusal:
1) The Log Class: http://developer.android.com/reference/android/util/Log.html
2) The Intent and use of the Log Class: http://developer.android.com/tools/debugging/debugging-log.html
"Log is a logging class that you can utilize in your code to print out messages to the LogCat." This is the Log class that we commonly use for logging within apps and services.
Do let me know if I should provide you with further information or clarify some stuff.
Alex Afanasyev wrote:
Can you give some references for use of logcat in applications?
Updated by Alex Afanasyev almost 10 years ago
- Category changed from jni to gui
Ok. Let's use logcat. I consider it is not ideal, as there should be some more meaningful way to do the same job directly in Java, but everybody seem to be using logcat... Let's not waste more time on looking for other ways.
Updated by Ivan Yeo almost 10 years ago
Yep, agreed. Seems like it's how the framework is structured. Sure thing, I'll get cracking!
Alex Afanasyev wrote:
Ok. Let's use logcat. I consider it is not ideal, as there should be some more meaningful way to do the same job directly in Java, but everybody seem to be using logcat... Let's not waste more time on looking for other ways.
Updated by Alex Afanasyev almost 10 years ago
Duplicate of gerrit comment:
As a skeleton, http://gerrit.named-data.net/#/c/1761/4 is ok. However, to merge, the implementation needs to have a correct UI implementation, as I mentioned in note-5:
- separate activity
- when activity starts, logging is enabled, when user exists/, logging stops
- log level selection (with recording of previous state in some configs)
- (optional) name-based filtering (with recording of previous state).
Updated by Ivan Yeo almost 10 years ago
Roger that. I'll work on this right after I get the service running with the toggle button in the http://redmine.named-data.net/issues/2431
Thanks!
Alex Afanasyev wrote:
Duplicate of gerrit comment:
As a skeleton, http://gerrit.named-data.net/#/c/1761/4 is ok. However, to merge, the implementation needs to have a correct UI implementation, as I mentioned in note-5:
- separate activity
- when activity starts, logging is enabled, when user exists/, logging stops
- log level selection (with recording of previous state in some configs)
- (optional) name-based filtering (with recording of previous state).
Updated by Ivan Yeo almost 10 years ago
- % Done changed from 80 to 90
Cross post from: http://gerrit.named-data.net/#/c/1761/
Phase 1: Initial first pass implementation of the following features:
- separate activity
Log Activity created with a launch button on NFD Control App's main page.
- when activity starts, logging is enabled, when user exists/, logging stops
Log starts when the activity comes into focus. User log level preferences are saved when user exits. If no previous history of log level preferences are available, the default would be to display all logs with verbose output.
- log level selection (with recording of previous state in some configs)
Log level selection is achieved through a spinner (aka drop down list selection).
Phase 2: Think through and design UI of the following feature:
- (optional) name-based filtering (with recording of previous state)
In progress.
Updated by Ivan Yeo over 9 years ago
This is an update entry based on the discussion with Alex located at: http://gerrit.named-data.net/#/c/1761/
These are the items that have to be worked on next for this Task:
- TextView is unable to hold an unlimited amount of text. Hence, a mechanism to limit the available logs should be design and implemented. This will be posted in the next Gerrit patch.
- Update UI to make use of the Menu Options: 'Settings' menu item.
- Logging should mute/silence all other outputs except from NFDService and relevant tags that are associated with NFDService.
- Color scheme of the console and logging should be redesigned and vetted. The current implementation of blue just looks weird.
Updated by Ivan Yeo over 9 years ago
- File logger.png logger.png added
- File log_pref.png log_pref.png added
- Status changed from In Progress to Code review
- % Done changed from 90 to 100
Task is completed and under code review at: http://gerrit.named-data.net/#/c/1761/
The current implmentation allows the user to filter all NFD related tags individually at any of these available log levels:
- V: Verbose
- D: Debug
- I: Info
- W: Warning
- E: Error
- F: Fatal
- S: Silent
The log view is customized to prevent Out of Memory Error in event that the logger is used for a prolonged period of time.
A custom settings page is created for the user to individually set the log level for each tag.
Attached images present the log view and user preference setting activities.
Updated by Alex Afanasyev over 9 years ago
Quick question about log output formatting: how is it defined? Is it logcat's options? In particular, one may want to see times for operations. In which place this should be implemented?
Updated by Ivan Yeo over 9 years ago
The formatting is defined through options to logcat. They can be one of the following:
- brief
- process
- tag
- thread
- raw
- time
- threadtime
- long
One way we could do it is to use the 'time' option, which is what is seen in Android Studio and Eclipse. This is a common option even when debugging from the terminal as well.
We could either implement it as a user selected preference in the next task or hard code it as a default. Let me know which you'd prefer :)
Updated by Alex Afanasyev over 9 years ago
Just hard-code time for now and add a comment in the code how other things can be coded.
Updated by Ivan Yeo over 9 years ago
Roger that!
I've made the changes as requested in your comments and pushed them in patch 11: http://gerrit.named-data.net/#/c/1761/11
I'll also re-think the tags extraction as I now have a better idea of what you're getting at through your comments.
Thanks!
Updated by Ivan Yeo over 9 years ago
After looking into the code base of the PreferenceFragment and the automated way in which preferences are saved through the shared preference context, I think we should finalize how we'd want to dynamically add the tags (e.g. from a file) before we build the tags on the fly in the logger activity.
The shared context that PreferenceFragment uses makes it difficult to retrieve keys that are relevant only to the logging activity. It would be good if we say, have a file that lists all the tags we want to monitor, then dynamically load it as preferences for the user to choose the log level. Subsequently, with this file, we are able to retrieve the relevant keys from the shared preference easily.
One way I see about it is to setup a new issue that settles that. Let me know how you'd like to proceed.Thanks!
Updated by Alex Afanasyev over 9 years ago
The tag list is easily obtainable from nfd. The only small missing piece is jni wrapper for that.
The ideal log config model for me is the following:
- there is only one hard-coded element: default log level
- user can add component from the list (obtained through jni call)
- for the added component, he can setlog level
- user can remove component, effectively making default log level for that component
I understand that this could include non-nfd related components in the log if the default level is too verbose. But I think that is not a not a big deal and wouldnt affect manh people.
Updated by Ivan Yeo over 9 years ago
I think it's clearer to me what you're getting at right now. Looks like we'll have to make some changes to the UI to facilitate the adding of these "new" tags that have been elicited from the jni call.
One way I see about it is to close this task, merge #1761 (http://gerrit.named-data.net/#/c/1761/) and create a new task that works on creating the UI for the user to dynamically add these tags that are taken from the jni call. These selected tags will then appear in the current log level setting activity that we have, which allows for granular selection of individual log levels.
Let me know how you'd like to proceed from here :)
Updated by Alex Afanasyev over 9 years ago
- Blocks Task #2623: Extend log output settings added
Updated by Alex Afanasyev over 9 years ago
- Status changed from Code review to Closed
Updated by Alex Afanasyev over 9 years ago
- Status changed from Closed to Code review
I did a small refactoring (http://gerrit.named-data.net/#/c/1870), so reopening this issue until the code merged.
Updated by Alex Afanasyev over 9 years ago
- Status changed from Code review to Closed