Applications accessing the system logs has been a long-standing issue. There is various code in the system that tries to trim personal and other dangerous information out when it prints to the log, but this often misses things, and just makes the system using the logs much more complicated and risky.
The logs are also a target for malware, since it can look at what is being printed there to infer a lot about what is going on in the device. Plus, as I said, access to the logs has never been any part of the SDK, and this was very deliberate, because it is not a facility we want applications to use or feel like we can maintain for applications as the platform evolves. If you want the user to give you debugging information, you can have them generate a bug report with power + volume down + volume up which includes the logs and lots of other data, and automatically brings up their e-mail app to sent it all (plus a screenshot). We were just discussing that we should have an easier way to generate these as well, I am going to look at adding something to the settings app. I also have started introducing the concept of a "development" permission, which read logs is classified as. This allows the app to request the permission, but not get it at install. You can however grant it with an adb shell command once it is installed. At some point later I expect to have a UI in the system for doing this, but we are going to hold off on that to be careful about how we present this. As far as the percentage of devices running JB, if you want to make that argument then we should just stop doing any improvements now since a few days after release very few devices will have them. We consider this a significant improvement to the security of the platform, and going forward it is what we want to have. On Thu, Jul 12, 2012 at 10:00 AM, Kostya Vasilyev <[email protected]>wrote: > I have my own logging solution in my app, and even though it's very > useful... > > ... being able to see the system logs is invaluable and irreplaceable in > some situations. > > For example, I recently experienced LVL validation failures and asked the > users to use CatLog (one the of apps on Market that can read and email > logcat output). With the logcat output in hand, it was obvious that the > failure is on Google's side (again!) and I knew what to do about it. > > I understand that the Android team's concern, as was previously mentioned > on the list, is for applications that may print personal user's information > in the system log. > > Why, then, is the remedy such that it punishes apps that are not in > violation of the user's privacy with their logcat use? > > Is the actual install share of JB so high already that this change is > believed to be a meaningful solution? > > -- K > > > 2012/7/12 Latimerius <[email protected]> > >> The upcoming ACRA release will (probably) contain the ability to >> include a custom application-private log file in a report. So if you >> only care for reading the system log to read your own log messages, >> that should be taken care of. Of course, if you really want to read >> the actual stuff logged by the system and other apps, that's going to >> be tougher. >> >> On Thu, Jul 12, 2012 at 5:19 PM, b0b <[email protected]> wrote: >> > The thing is that it is better to not rely on READ_LOGS to (for example) >> > provide logs to ACRA. >> > The bonus is that your app will not need that permission which is kind >> of >> > scary. >> > >> > How can it be done ? >> > >> > - wrap all your logging calls into functions adding your log message + >> any >> > other metadata (like tag or timestamp) to a cache were you keep the >> last n >> > log lines. Can be done with a simple LinkedHashMap overriding >> > removeEldestEntry(). >> > - modify ACRA by adding a custom column that will contain the content >> of >> > the log cache. When the crash report is constructed, fill that column >> with >> > the cache data >> > - profit! >> > >> > >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Android Developers" group. >> > To post to this group, send email to >> [email protected] >> > To unsubscribe from this group, send email to >> > [email protected] >> > For more options, visit this group at >> > http://groups.google.com/group/android-developers?hl=en >> >> -- >> You received this message because you are subscribed to the Google >> Groups "Android Developers" group. >> To post to this group, send email to [email protected] >> To unsubscribe from this group, send email to >> [email protected] >> For more options, visit this group at >> http://groups.google.com/group/android-developers?hl=en >> > > -- > You received this message because you are subscribed to the Google > Groups "Android Developers" group. > To post to this group, send email to [email protected] > To unsubscribe from this group, send email to > [email protected] > For more options, visit this group at > http://groups.google.com/group/android-developers?hl=en > -- Dianne Hackborn Android framework engineer [email protected] Note: please don't send private questions to me, as I don't have time to provide private support, and so won't reply to such e-mails. All such questions should be posted on public forums, where I and others can see and answer them. -- You received this message because you are subscribed to the Google Groups "Android Developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-developers?hl=en
