Provide built in logcat function

[moving-bits]

Inspired by a discussion in #8319 (comment):

Hmm. LogCat doesn't work anymore, thus installed MatLog, granted read access to logs, as it demanded (adb shell pm grant com.pluscubed.matlog android.permission.READ_LOGS), but I don't see anything from c:geo - anything else left to be done? Or is there a better way to get the trace?

Yes, actually using on-board tools to trace has become really difficult. I have to admit, that I did not find any solution up to now due to limited time.

---

Feature request: Provide a built-in function in c:geo to save its own logcat to a user-readable file, maybe even make it sendable via e-mail.

[MagpieFourtyTwo]

+1

BTW; Not really sure what made the difference (I didn't change a thing, at least not intentionally) but after a few hours, MatLog suddenly shows cgeo's messages as if it never happened otherwise (and BTW mimicked geocachermgo's logcat). Hence it's still (i. e. with Android 10) possible to create a trace on the fly (after using adb once, of course).

Nevertheless, I support the FR as a builtin logcat function (esp. with the mentioned extra features and w/o need of adb) would make (tester's) live a lot easier.

[moving-bits]

That's the reasoning behind this feature wish: Make LogCat results for c:geo available to non-IT people.

Because today, you have to

• use an Android device < JellyBean, or
• have to use a rooted device, or
• have to grant READ_LOGS rights via ADB (that's what you probably did), or
• have to use an IDE like AS, which grants the rights internally for you.

[Lineflyer]

Thats a nice idea. I would have made this proposal earlier if I only knew this possibility existed.

Some functional questions from my side:

1. Currently you have to activate debug log in Settings / System to collect information (other than exceptions). I guess this would still be needed in some cases? If so, we should put both options nearby in the setttings.
2. What about the timing? If I read your PR correctly, pressing the button will save the logfile, but what does it contain then. Does the user need to press the button before or after having the problem? Any possibility to record over a longer time?
3. Where did you place the logcat directory? I suggest to place it below /cgeo/ where also backup, etc. is located.

[moving-bits]

Thats a nice idea. I would have made this proposal earlier if I only knew this possibility existed.

I didn't know of it as well, just learned about while researching how to access LogCat using apps (and how limited this is today due to security restrictions).

1. Currently you have to activate debug log in Settings / System to collect information (other than exceptions).

This may happen, sometimes. But the most frequent use case IMHO is to catch the place (source line) where an exception happened to have an anchor for starting the search for the cause. You can still activate debug function in a second step, if needed (depending on the issue being investigated).

I guess this would still be needed in some cases? If so, we should put both options nearby in the setttings.

Which two options do you mean? One is activating "debug mode", the other?

2. What about the timing? If I read your PR correctly, pressing the button will save the logfile, but what does it contain then. Does the user need to press the button before or after having the problem? Any possibility to record over a longer time?

I'm exporting the log message which already exist (Android logs a lot of things automatically), so exporting should be done after something unusual/unwanted has happened within c:geo.

I'm still exploring the content and timeline part - how much is written to the log, when it gets recycled etc. Currently I'm exporting the full available log (in c:geo context), but filtered to lines/tags with "cgeo.geocachin" in there, meaning the message comes from the app itself, not from the system around.

3. Where did you place the logcat directory? I suggest to place it below /cgeo/ where also backup, etc. is located.

exactly, it's the new "logcat" dir beneath our cgeo dir. Thus our typical dir structure would be:

• cgeo
  • backup
  • gpx
  • logcat
  • maps

Naming for "logcat" can be changed, if needed, maybe to "logfiles" instead of "logcat" (which probably is too technical)
(Note: "maps" will be the new standard subfolder for offline map data, if you use the automatic onboarding for map files, #8180)

Another missing peace is how to reach logcat files using earlier Android versions: The program itself is available from the beginning, but for some reason calling it leads to a 255 result on older systems, instead of the expected 0 (= no error).

[MagpieFourtyTwo]

* have to grant `READ_LOGS` rights via ADB (that's what you probably did), or

Yep. In the very first minute after installing MatLog. It even gives a message that you have to do so (on non-rooted devices). But for any reason it took another few hours until it finally started to display logs of other apps, too (w/o adb it shows just it's own messages).

Nevertheless, too complicated for Non-ITs and not deterministic enough to explain to an impatient user, who is not even sure of his business ... ;)

As for the button: I would prefer two of them. One for toggling logging on and off (just one to flush a cyclic buffer would even be better, but I guess "always on" is most probably not an option, with regard to memory usage, performance and stability) and another for initiating the save&send dialogue (including the "do you really want to" and "remove personal data?" stuff).

[MagpieFourtyTwo]

I'm exporting the log message which already exist (Android logs a lot of things automatically)

So you're thinking of grabbing / grepping the stuff from Android's logfiles? As far as I understood what MatLog did (resp. was able to do), an app has no access to these by default anyway, thus it has to write it's own log to somewhere else to be able to show (or store) it ...

[MagpieFourtyTwo]

... at least w/o using adb to grant permission - what, as far as I understood the FR, should be avoided ... or am I wrong?

[Lineflyer]

Which two options do you mean? One is activating "debug mode", the other?

I was refering to Settings - System - "Fehlersuche". There are two options "Debug-Log aktivieren" and "Erzeuge Speicherabbild". I think we should add the "generate logcat" over there instead of the about dialog.

Edit:
The other things look good to me!

Maybe we should add the time to the file name additionally to the date to avoid overwrite of files in consecutive tries.

BTW: Adding date to filename was also requested for the gpx export in some feature request here...now, that you just wrote this method.... ;)

[moving-bits]

... at least w/o using adb to grant permission - what, as far as I understood the FR, should be avoided ... or am I wrong?

Each app is allowed to read its own logcat portion, without any special permissions - that's what I'm using here. Permission READ_LOGS is needed when app A tries to read logcat from app B. (AFAIK)

[moving-bits]

Which two options do you mean? One is activating "debug mode", the other?

I was refering to Settings - System - "Fehlersuche". There are two options "Debug-Log aktivieren" and "Erzeuge Speicherabbild". I think we should add the "generate logcat" over there instead of the about dialog.

Thanks for clarifying - didn't have the "generate memory image" in my mind.
Now added in recent update: I put the button "Generate logfile" between the two other buttons, as this is more closely related to "activate debug info" IMHO.

Maybe we should add the time to the file name additionally to the date to avoid overwrite of files in consecutive tries.

Added even without having seen this part of your comment ;-)
(by reusing an existing utility function for logfile generation)

BTW: Adding date to filename was also requested for the gpx export in some feature request here...now, that you just wrote this method.... ;)

Date is already added to GPX export filename, at least if you export a list of caches.

[MagpieFourtyTwo]

Each app is allowed to read its own logcat portion, without any special permissions

Even LogCat messages from previous instances? Cause these would be the relevant ones, in case you want to trace a crash (what I had in mind while thinking of the On/Off scenario):

1. tap 'Start LogCat' to start logging to special file (or just remember the start timestamp)
2. reproduce crash
3. re-enter c:geo, tap 'Stop LogCat' which either extracts LogCat messages from start timestamp up to now() or just takes the special file and starts the send dialogue ...

[moving-bits]

Even LogCat messages from previous instances? Cause these would be the relevant ones, in case you want to trace a crash (what I had in mind while thinking of the On/Off scenario):

At least with the Android 10 emulator this worked as expected. Android 4 seems to be a bit unreliable regarding logcat and logcat filtering, so I relieved the filtering on older Android versions.

1. tap 'Start LogCat' to start logging to special file (or just remember the start timestamp)
2. reproduce crash
3. re-enter c:geo, tap 'Stop LogCat' which either extracts LogCat messages from start timestamp up to now() or just takes the special file and starts the send dialogue ...

No need to start & stop logging manually. Logging is done automatically by Android. After a crash you simply re-enter c:geo, write the logcat file and optionally send it to c:geo support.

The only thing which would have to be done manually is to activate the special debug messages from c:geo. Then it's similar to the way you described. But that's a rare case, at least as long as you're hunting down crashes.