search

sank20 / acra

Automatically exported from code.google.com/p/acra
0 stars 0 forks source link

Option to also upload application log #13

Closed GoogleCodeExporter closed 8 years ago

GoogleCodeExporter commented 8 years ago 
Having the ability to get detailed error reports even on pre-FroYo platforms is 
great. Being able to get the last few lines of application log (as written by 
Log.verbose and friends) would be awesome.

I know acra already has the ability to upload key-value pairs but that requires 
adding acra-specific debug code whereas getting the log makes it easier for app 
developers to start using acra.

Original issue reported on code.google.com by pa...@paour.com on 22 Nov 2010 at 12:47

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
A place to start for easy log collection:

http://code.google.com/p/android-log-collector/source/browse/trunk/android-log-c
ollector/src/com/xtralogic/android/logcollector/SendLogActivity.java

I would rather not have to use logcollector separately, and it would be great 
to have all signals (exception and log) in once place (Gdocs)

Original comment by pa...@paour.com on 22 Nov 2010 at 3:17

GoogleCodeExporter commented 8 years ago 
I will have a look to the prerequisites for such a feature. My main concerns 
are that it could require to add a system permission to the application, there 
are privacy issues with sending these log data, and the size of the report 
could increase a lot.

One alternative to this could be to provide in ACRA a Log.* replacement which 
would both log to the system log and to a buffer which would be provided in a 
new GDoc column... or as a replacement of the key/value custom data...

I thinks this needs more discussion.

Original comment by kevin.gaudin on 22 Nov 2010 at 4:12

GoogleCodeExporter commented 8 years ago 
It's true that application will need a new permission on the manifest for 
reading the logs. We can run some tests and decide how long we want the crash 
log to be (probably last 10000 chars would be enough for a bug that is 
happening right now). This is really simple to do. I can work on it, if you 
want.

The Log.* thing you mention, sounds like a more manual approach. You never know 
where the bug is gonna be, right?. With system logs you will get automatically 
what exactly happened on the final user.

Let me know if i can help here

Ger

Original comment by ggom...@gmail.com on 1 Dec 2010 at 11:18

GoogleCodeExporter commented 8 years ago 
[deleted comment]
GoogleCodeExporter commented 8 years ago 
I'm thinking about it and it certainly will come in a future version of ACRA as 
an option for 2 reasons:
- not all devs want to be forced to add that specific READ_LOG permission to 
their application because it has some privacy implications (the user's gmail 
account is often easy to get in the logs, + any other app can log private data)
- the time needed to collect the logcat data could increase the whole data 
collection time which is already quite long (see Issue 19). This might not be a 
problem if the collection time of existing data can be reduced and if the 
length of the logcat extract is not too long.

Original comment by kevin.gaudin on 4 Dec 2010 at 4:16

GoogleCodeExporter commented 8 years ago

Original comment by kevin.gaudin on 4 Dec 2010 at 4:21

GoogleCodeExporter commented 8 years ago 
You should be able to write the log collection code in such a way that if the 
developer doesn't request the READ_LOG permission, then ACRA just doesn't 
collect the code. That way, devs who want the feature can use it, others don't 
have to change anything.

Regarding the privacy implications, showing the user what will be sent would be 
a nice way of putting minds at ease, for users who (legitimately) care about 
that. That would work only within the context of the notification version of 
ACRA, but you could display the info that will be sent (including the data ACRA 
already sends), with a checkbox to allow/disallow the log collection.

As a matter of fact, since you mention the email address, an option to allow 
ACRA to upload the user's email address would be great, so devs can get in 
touch with the user for more info.

Original comment by pa...@paour.com on 5 Dec 2010 at 9:53

GoogleCodeExporter commented 8 years ago

Original comment by kevin.gaudin on 12 Dec 2010 at 4:07

GoogleCodeExporter commented 8 years ago 
Started to implement this for next release (3.2.0)... and a DropBoxManager 
events collector too ;-). A 3.2.0 test release will be published quickly after 
declaring 3.1.0 as the new stable version. I would prefer having a new testing 
phase started for these new features because they might have quite an impact on 
privacy, performance and usability of ACRA.

Both (logcat+dropbox) data collection are currently working on my dev 
environment (and on the TRUNK) as soon as you enable the READ_LOGS permission. 
I'm now thinking about the best way to configure these collections:
  * let the app dev add tags to the dropbox collector + how many minutes back in history
  * let the app dev provide all possible logcat command line controls

Default values will be set to what 'I' would consider as reasonable values in 
terms of performance (collection time) and memory impact. Default dropbox tags 
include all the tags I have been able to find in android system sources.

The DropBoxManager collector is based on reflection API so even if the 
DropBoxManager has been introduced in android API level 8, ACRA will still be 
backward compatible up to API level 3. The reports won't contain any dropbox 
data on older devices.

Original comment by kevin.gaudin on 20 Dec 2010 at 11:47

GoogleCodeExporter commented 8 years ago 
Great news, thanks for adopting this feature!

Original comment by pa...@paour.com on 21 Dec 2010 at 10:22

GoogleCodeExporter commented 8 years ago

Original comment by kevin.gaudin on 4 May 2011 at 11:55

GoogleCodeExporter commented 8 years ago 
This issue can now be closed :-)

Original comment by pa...@paour.com on 7 Jul 2011 at 2:59

GoogleCodeExporter commented 8 years ago 
We need some documentation for how to switch this on.

Original comment by william....@gmail.com on 16 Jul 2011 at 5:53

GoogleCodeExporter commented 8 years ago 
http://code.google.com/p/acra/wiki/AdvancedUsage#Adding_logcat,_eventlog_or_radi
olog_extracts_to_reports is now up to date.

To sum it up:
- Activating LOGCAT is done by adding the READ_LOG permission to the manifest
- EVENTSLOG, RADIOLOG and DROPBOX collection are automatically included by 
default
- to remove them, you have to drop them from the .csv file before creating the 
GDoc spreadsheet and use ReportsCrashes.customReportContent with the new 
content of the csv
- Future releases of ACRA will not collect these 3 fields by default anymore. 
Devs who really need them will have to explicitly activate them. This is better 
for performance and memory management.

Original comment by kevin.gaudin on 25 Nov 2011 at 11:14