2012/7/12 Dianne Hackborn <[email protected]> > 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. >
Understood, but you just made legitimate use impossible. > > 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. > You saying that doesn't make it any less useful or necessary in some cases (and those cases are "when you need it, you really really need it"). > > 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. > Ah, the usual "almost done, but not quite, and really, wait for the next version where it'll really work, and pray that your users will have it on their devices". Is there something wrong with how Android's release schedule is largely tied to Google I/O and the Christmas buying season? This feature works on my 4.0.4, which was released in November - where's the docs? I see the developer site received a fancy redesign, surely someone could find the time to write this up? > > 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. > I fail to see the use case for this. Reading the system logs is useful for remotely diagnosing weirdness out on the user's devices, when one specifically needs the system logs and not just the app logs. Do you expect end users to install the development tools and adb in order to grant this permission, should the need arise? > 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. > Pffft. Well, I think you should. It took your team about six months to get the Galaxy Nexus to where it 1. doesn't reboot on its own and 2. is able to accept incoming calls and SMS. Still, a few times a day I see it freeze for a few seconds and kill the foreground app, dumping me to Launcher. This happens in Gmail and the browser - both of which are pre-installed apps, developed at Google. I don't recall an HTC Hero with 1.6, or a Motorola Milestone with 2.1 doing anything like this. Everything after that has been a gradual decline in stability, from one release to the next. Speaking as a user, and as a developer both, each new release makes me think "guess what they broke this time", and this applies to development tools and Market as well - the whole Android experience. Is this progress? -- K -- 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
