As of Jelly Bean, ordinary SDK applications cannot hold the
READ_LOGS permission. Only applications that are signed with
the firmware signing key or are system apps (e.g., pre-installed
apps) will be able to hold this permission at the present time.
This is a security measure, partly to prevent apps from reading data leaked into LogCat by other apps, and partly to prevent apps from using LogCat data to infer what is going on with the device and harming the user. These techniques — along with others that I will not mention here — are being used to do such things as attempt to block uninstallation of apps. I have personally filed security issues regarding this sort of behavior.
The primary cost to developers is that often times the error information
we seek from devices in the field is logged to LogCat by the OS or
by device-specific apps. Right now, our primary workaround for
that sort of information is the obscure POWER + VOLUME UP + VOLUME DOWN
key combination, which triggers an
ACTION_SEND that can be picked
up by email clients and contains a copy of a
dumpstate report, plus
a screenshot. However, this is very clunky to initiate (it took me
several tries on a Galaxy Nexus). I have filed
a feature request
to try to make this easier for users.
For your own logging information, you should consider switching from
LogCat to something else that logs to your internal storage, which
you then arrange to send in your ACRA reports and the like. In addition
java.util.logging built into Android, you can integrate any
number of third-party libraries.
For more information about this issue, including Dianne Hackborn’s comments, please see this android-developers thread.
Want an expert opinion on your Android app architecture decisions? Perhaps Mark Murphy can help!Tweet