The CommonsBlog


READ_LOGS Regression

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 to the 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.