Closed GoogleCodeExporter closed 9 years ago
[deleted comment]
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
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
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
[deleted comment]
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
Original comment by kevin.gaudin
on 4 Dec 2010 at 4:21
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
Original comment by kevin.gaudin
on 12 Dec 2010 at 4:07
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
Great news, thanks for adopting this feature!
Original comment by pa...@paour.com
on 21 Dec 2010 at 10:22
Original comment by kevin.gaudin
on 4 May 2011 at 11:55
This issue can now be closed :-)
Original comment by pa...@paour.com
on 7 Jul 2011 at 2:59
We need some documentation for how to switch this on.
Original comment by william....@gmail.com
on 16 Jul 2011 at 5:53
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
Original issue reported on code.google.com by
pa...@paour.com
on 22 Nov 2010 at 12:47