Android Question Best method for recovering logs in a production environment

[Alessandro71]

How do you recover logs from your app running in release mode, on the end-user device of a remote user?

Actually I use a custom made module that mirrors all Log() calls to a text file in DirInternal, and the app has a "send logs" option that sends this file via email.
When I need to investigate an issue, I must ask the user to use that option to send me the logs.
While funcional, this method requires replacing all the standard Log() calls with my Logger.WriteLog().
The recent switch from services to receivers has also made more difficult to keep using this method, because the receiver may be called when the app is not actually running and the Logger module has not been yet initialized.

Is there any other proven method for logging in a production environment?

 

[JohnC]

"The recent switch from services to receivers has also made more difficult to keep using this method, because the receiver may be called when the app is not actually running and the Logger module has not been yet initialized."

So code in a module may not run when called from a reciever under certain circumstances?

 

[Alessandro71]

"The recent switch from services to receivers has also made more difficult to keep using this method, because the receiver may be called when the app is not actually running and the Logger module has not been yet initialized."

So code in a module may not run when called from a reciever under certain circumstances?

I wasn't clear enough:
My Logger module is initialized (opening the text log file and other stuffs) in the Starter service.
It looks like the Starter service is not actually started if the app is started by a receiver

 

[JohnC]

Is it possible to also directly initialize/use the logger module from the receiver?

 

[DonManfred]

It looks like the Starter service is not actually started if the app is started by a receiver

No. the starter service will not start when your app starts from a receiver.

 

[Alessandro71]

Is it possible to also directly initialize/use the logger module from the receiver?

that's what actually do, but it's a step back from the "single point of entry" purpose of the Starter service.
but the starting question was "How does people collect logs in a production environment? Am I missing a simple/standard method everybody else is using?"

 

[JohnC]

I totally understand that you would like a unified method to log info.

So, why does the logger need to be first "initialized"?

If it's a class, why can't you simply convert the logger routine to be just a routine in a module, so you can call it from anywhere without it first needing to be initialized - this would result in just one unified way of using it.

 

[Alessandro71]

I totally understand that you would like a unified method to log info.

So, why does the logger need to be first "initialized"?

If it's a class, why can't you simply convert the logger routine to be just a routine in a module, so you can call it from anywhere without it first needing to be initialized - this would result in just one unified way of using it.

It is already a module and not a class.
The Initialize sub opens the text file for writing

 

[JohnC]

If you are not continuously writing (like every 100ms or faster) to the log file, then you won't be taking much of a performace hit to modify the code to both open and close the file from within the routine each time a new event is added to the log file.

This way, the routine will be self-contained and won't depend on any code outside of it to perform its function, so it can then be called from anywhere and at any time.

 

[JohnC]

"...option that sends this file via email."

Also, if you are using the network library with your own SMTP account to make it easy/seemless for the user to send the log files to you (instead of using an intent that invokes the user's default email client to do the emailing of the log files and requires them to hit the "send" button in their email app), then make sure that your SMTP credentials are encrypted in the app because if it's clear text, then it's real easy for someone to steal them, intercept your other emails and then use your email server as a spam bot which will get your domain blacklisted.

 

[Alessandro71]

If you are not continuously writing (like every 100ms or faster) to the log file, then you won't be taking much of a performace hit to modify the code to both open and close the file from within the routine each time a new event is added to the log file.

This way, the routine will be self-contained and won't depend on any code outside of it to perform its function, so it can then be called from anywhere and at any time.

opening and closing the file at each Log() seemed overkill to me and never really considered until now

 

[Alessandro71]

"...option that sends this file via email."

Also, if you are using the network library with your own SMTP account to make it easy/seemless for the user to send the log files to you (instead of using an intent that invokes the user's default email client to do the emailing of the log files and requires them to hit the "send" button in their email app), then make sure that your SMTP credentials are encrypted in the app because if it's clear text, then it's real easy for someone to steal them, intercept your other emails and then use your email server as a spam bot which will get your domain blacklisted.

actually I prefer the intent way for 2 reasons:
1) no need for SMTP/FTP/whatever hosting account
2) for really large logs (they can be), user can select other sharing options, like Google Drive