Re: READ_LOGS permission is not granted to 3rd party applications in Jelly Bean (api 16)

20703 views
Skip to first unread message

BoD

unread,
Jul 12, 2012, 8:37:32 AM7/12/12
to android-d...@googlegroups.com
I just encountered this problem on a Galaxy Nexus running Jelly Bean "JRN84D".
This is a serious issue because it makes extremely valuable libraries like ACRA inoperative.

A comment from someone from the Android team would be greatly appreciated :)

Thanks!

--
BoD


On Sunday, July 8, 2012 9:26:47 PM UTC+2, Ievgenii Nazaruk wrote:
Hi all,

I've been working on an application for developers that uses DropBoxManager. The DropBoxManager requires READ_LOGS permission to be granted in order to query information from it.

Today I've tested my application on newest (api 16) emulator before releasing it to Google Play. It turned out that Android now refuses to grant this permission to 3rd party applications. This is weird because I've looked through all Jelly Bean's documented changes and couldn't find anything that mentions READ_LOGS permission.

So basically my questions:
  • Did anyone see this change documented? 
  • Can someone confirm this behavior on Galaxy Nexus with Jelly Bean on it (the one released to attendees of Google I/O)?
And questions to someone from Android team:
  • Why this breaking change wasn't described in documentations like READ_EXTERNAL_STORAGE was?
  • What should developers and testers do in order to use those handy utility applications that require READ_LOGS to be useful? Is there any way to allow READ_LOGS to 3rd party applications without making custom build (i.e. something in "Developer Options" that I could've missed)?

Mark Murphy

unread,
Jul 12, 2012, 8:45:26 AM7/12/12
to android-d...@googlegroups.com
On Thu, Jul 12, 2012 at 8:37 AM, BoD <bodl...@gmail.com> wrote:
> This is a serious issue because it makes extremely valuable libraries like
> ACRA inoperative.

ACRA does not need READ_LOGS. Certain ACRA features might need READ_LOGS.

>> Did anyone see this change documented?

It does not appear to be documented.

>> Can someone confirm this behavior on Galaxy Nexus with Jelly Bean on it
>> (the one released to attendees of Google I/O)?

It appears in the new source code. The protectionLevel for READ_LOGS
is now "signature|system|development". The new pipe syntax for
protectionLevel is also undocumented (see
http://code.google.com/p/android/issues/detail?id=34785).

--
Mark Murphy (a Commons Guy)
http://commonsware.com | http://github.com/commonsguy
http://commonsware.com/blog | http://twitter.com/commonsguy

_The Busy Coder's Guide to Android Development_ Version 3.8 Available!

Francisco M. Marzoa Alonso

unread,
Jul 12, 2012, 9:19:43 AM7/12/12
to android-d...@googlegroups.com
I experimented same issue using Crittercism, that I rather liked to use
that permission for debugging crashes. After seeing that it was not
working, I simply desist and rely on other debugging information.

I was not sure if the fail was on Android side or Crittercism one, but
reading your message and other replies to it, it seems like it is on
Android side.

Regards,


On 08/07/12 21:26, Ievgenii Nazaruk wrote:
> Hi all,
>
> I've been working on an application for developers that uses
> DropBoxManager. The DropBoxManager requires READ_LOGS permission to be
> granted in order to query information from it.
>
> Today I've tested my application on newest (api 16) emulator before
> releasing it to Google Play. It turned out that Android now refuses to
> grant this permission to 3rd party applications. This is weird because I've
> looked through all Jelly Bean's documented changes and couldn't find
> anything that mentions READ_LOGS permission.
>
> So basically my questions:
>
> - Did anyone see this change documented?
> - Can someone confirm this behavior on Galaxy Nexus with Jelly Bean on
> it (the one released to attendees of Google I/O)?
>
> And questions to someone from Android team:
>
> - Why this breaking change wasn't described in documentations like
> READ_EXTERNAL_STORAGE<http://developer.android.com/reference/android/Manifest.permission.html#READ_EXTERNAL_STORAGE>was?
>
> - What should developers and testers do in order to use those handy

BoD

unread,
Jul 12, 2012, 10:19:14 AM7/12/12
to android-d...@googlegroups.com
On 07/12/2012 02:45 PM, Mark Murphy wrote:
> On Thu, Jul 12, 2012 at 8:37 AM, BoD <bodl...@gmail.com> wrote:
>> This is a serious issue because it makes extremely valuable libraries like
>> ACRA inoperative.
> ACRA does not need READ_LOGS. Certain ACRA features might need READ_LOGS.
I think we can all agree that one main feature of this library (and
others) is the ability to read/send the logs.

> It appears in the new source code. The protectionLevel for READ_LOGS
> is now "signature|system|development". The new pipe syntax for
> protectionLevel is also undocumented (see
> http://code.google.com/p/android/issues/detail?id=34785).

Thank you for this.
This is extremely unfortunate.
I opened this issue:
http://code.google.com/p/android/issues/detail?id=34792

--
BoD

b0b

unread,
Jul 12, 2012, 11:19:36 AM7/12/12
to android-d...@googlegroups.com
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!


Latimerius

unread,
Jul 12, 2012, 11:46:27 AM7/12/12
to android-d...@googlegroups.com
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.
> --
> You received this message because you are subscribed to the Google
> Groups "Android Developers" group.
> To post to this group, send email to android-d...@googlegroups.com
> To unsubscribe from this group, send email to
> android-develop...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-developers?hl=en

Dianne Hackborn

unread,
Jul 12, 2012, 12:59:28 PM7/12/12
to android-d...@googlegroups.com
Hi, sorry this didn't get documented.

The change is that third party applications can no longer get the read logs permission, however every app can read the logs containing only the lines *they* have written, without needing any permission.

Keep in mind that access to the logs has never been part of the SDK, and is still not part of the SDK.  If you are relying on it then, even after this change, you run the risk of breaking in the future.  (And that is partly why this got lost for documentation, it is not part of the SDK, so there isn't really a place to document it, in fact documenting it would kind-of make it a part of the SDK which we don't want. :p)

Also we really really hope that developers don't take this as license to further abuse the system logs and spew increasing amounts of stuff into it from their app.  Log noise has been a continual problem on Android (not just for third party apps, we always struggle to ship the open source platform without a lot of noise), and if things continue to get worse we will probably make further changes to it to better control it.

On Sun, Jul 8, 2012 at 12:26 PM, Ievgenii Nazaruk <ievgenii...@gmail.com> wrote:
Hi all,

I've been working on an application for developers that uses DropBoxManager. The DropBoxManager requires READ_LOGS permission to be granted in order to query information from it.

Today I've tested my application on newest (api 16) emulator before releasing it to Google Play. It turned out that Android now refuses to grant this permission to 3rd party applications. This is weird because I've looked through all Jelly Bean's documented changes and couldn't find anything that mentions READ_LOGS permission.

So basically my questions:
  • Did anyone see this change documented? 
  • Can someone confirm this behavior on Galaxy Nexus with Jelly Bean on it (the one released to attendees of Google I/O)?
And questions to someone from Android team:
  • What should developers and testers do in order to use those handy utility applications that require READ_LOGS to be useful? Is there any way to allow READ_LOGS to 3rd party applications without making custom build (i.e. something in "Developer Options" that I could've missed)?

    --
    You received this message because you are subscribed to the Google
    Groups "Android Developers" group.
    To post to this group, send email to android-d...@googlegroups.com
    To unsubscribe from this group, send email to
    android-develop...@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/android-developers?hl=en



    --
    Dianne Hackborn
    Android framework engineer
    hac...@android.com

    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.

    Kostya Vasilyev

    unread,
    Jul 12, 2012, 1:00:13 PM7/12/12
    to android-d...@googlegroups.com
    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 <l4t1m...@googlemail.com>

    Dianne Hackborn

    unread,
    Jul 12, 2012, 1:15:33 PM7/12/12
    to android-d...@googlegroups.com
    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.

    Mark Murphy

    unread,
    Jul 12, 2012, 1:24:52 PM7/12/12
    to android-d...@googlegroups.com
    On Thu, Jul 12, 2012 at 12:59 PM, Dianne Hackborn <hac...@android.com> wrote:
    > however every app can read the logs containing only the lines
    > *they* have written, without needing any permission.

    OK, I'll bite: how do you do this? Most of the read-the-logs code that
    I have seen uses logcat via Runtime#exec(), and I don't see a
    command-line switch on logcat to limit output to just your own
    process' lines.

    (BTW, count me as one of the fans of this decision, despite the very
    loud grumblings I expect you will receive from various quarters)

    Thanks!
    Android Training in NYC: http://marakana.com/training/android/

    BoD

    unread,
    Jul 12, 2012, 1:40:02 PM7/12/12
    to android-d...@googlegroups.com
    Let me just respectfully say that I don't understand the decision.
    The API is potentially very dangerous, yes, but that is why it requires
    a permission.

    --
    BoD

    On 07/12/2012 07:24 PM, Mark Murphy wrote:
    > On Thu, Jul 12, 2012 at 12:59 PM, Dianne Hackborn <hac...@android.com> wrote:
    >> however every app can read the logs containing only the lines
    >> *they* have written, without needing any permission.
    > OK, I'll bite: how do you do this? Most of the read-the-logs code that
    > I have seen uses logcat via Runtime#exec(), and I don't see a
    > command-line switch on logcat to limit output to just your own
    > process' lines.
    >
    > (BTW, count me as one of the fans of this decision, despite the very
    > loud grumblings I expect you will receive from various quarters)
    >
    > Thanks!
    >


    --
    BoD

    Ievgenii Nazaruk

    unread,
    Jul 12, 2012, 3:22:00 PM7/12/12
    to android-d...@googlegroups.com
    Personally, as a user I welcome this change. 

    My concern was that this wasn't mentioned in changes description. And what's more important there is no way to enable READ_LOGS during development/testing process. It's good there are (tentative?) plans to introduce a way to enable such permissions for developers in later releases. It would've been great to have both these changes at the same time. But we have what we have.

    By the way, thanks for the power + volume down + volume up trick. Didn't know it existed. This somewhat mitigates the issue in some cases. 

    /Ievgenii Nazaruk

    -- K


    2012/7/12 Latimerius <l4t1m...@googlemail.com>
    > To post to this group, send email to android-developers@googlegroups.com

    > To unsubscribe from this group, send email to

    > 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 android-developers@googlegroups.com

    To unsubscribe from this group, send email to

    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 android-developers@googlegroups.com

    To unsubscribe from this group, send email to

    For more options, visit this group at
    http://groups.google.com/group/android-developers?hl=en

    John Coryat

    unread,
    Jul 12, 2012, 4:01:12 PM7/12/12
    to android-d...@googlegroups.com, B...@jraf.org
    Let me just respectfully say that I don't understand the decision.
    The API is potentially very dangerous, yes, but that is why it requires
    a permission.

     
    Do users even look or comprehend what permissions are being used in any given app? The user wants the app, they agree, agree, agree and then get malware.

    -John Coryat 

    Kristopher Micinski

    unread,
    Jul 12, 2012, 4:07:23 PM7/12/12
    to android-d...@googlegroups.com, B...@jraf.org
    This is a problem with permissions, not specifically the read logs permission.

    The problem with the read logs permission is that it doesn't clearly
    map into something the user can think about.

    The user can see "reads logs" and may think, "oh, reading things the
    device does, like, battery, etc...?"

    But doesn't get that it basically can let you monitor when apps start,
    plus whatever stupid developers do to like leaking high security data
    to a public channel ...

    Not having an API for it probably does help, as it makes it to where
    some people who would use the information when they shouldn't be just
    dont' use it because of the bar to entry (parsing the logs manually),
    but does (clearly) make it a tad problematic for people who want to do
    legitimate things with it...

    kris

    niko001

    unread,
    Jul 12, 2012, 5:11:06 PM7/12/12
    to android-d...@googlegroups.com, B...@jraf.org
    I think that locking out developers from using APIs (and yes, I know that it wasn't part of the SDK) for security purposes is an entirely wrong approach. Sure, malicious things can be done with reading the logs, but in the same vein, a kitchen knife can be used to kill someone. Every API can be used for malicious purposes - I would guess that the camera can be used to silently take pictures without the user's knowledge, but that doesn't mean that developers should be locked out of the Camera API. Malcicous apps should be filtered at the source, when being uploaded the Google Play, through automatic checks. I know that this is already being done, but rather than closing off APIs, these checks should be intensified, if malicious apps are still getting through.

    There are lots of legitimate reasons for reading the system logs at runtime. I could live with a solution as described by Dianne (granting access on a per-app basis through the system settings UI), but this should have been implemented at the same time as the lockdown of the "old" permission. Just because some developers forget to remove logs containing sensitive information, everyone else shouldn't be punished for their mistake. 

    Nick

    Kostya Vasilyev

    unread,
    Jul 12, 2012, 5:37:54 PM7/12/12
    to android-d...@googlegroups.com

    2012/7/12 Dianne Hackborn <hac...@android.com>

    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

    b0b

    unread,
    Jul 12, 2012, 6:05:15 PM7/12/12
    to android-d...@googlegroups.com
    Yes reading logs other than you app's has legitimates uses: how many times have I asked a user to send me a log saved with aLogcat, to
    troubleshoot possible issues related to the platform itself (damn you MediaPlayer!)




    Peter Sinnott

    unread,
    Jul 12, 2012, 7:39:18 PM7/12/12
    to Android Developers
    On Jul 12, 6:15 pm, Dianne Hackborn <hack...@android.com> wrote:
    > 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.

    Is that new in JB? All I can manage to do is turn off the screen or
    reboot.

    Mark Murphy

    unread,
    Jul 12, 2012, 7:43:18 PM7/12/12
    to android-d...@googlegroups.com
    On Thu, Jul 12, 2012 at 7:39 PM, Peter Sinnott <psin...@gmail.com> wrote:
    > Is that new in JB? All I can manage to do is turn off the screen or
    > reboot.

    I was able to get it working in a Galaxy Nexus running ICS, but only
    after several tries.

    I filed an feature request to offer something else, perhaps through
    Settings, to get to the same behavior:

    http://code.google.com/p/android/issues/detail?id=34815

    Peter Sinnott

    unread,
    Jul 12, 2012, 8:02:40 PM7/12/12
    to Android Developers


    On Jul 13, 12:43 am, Mark Murphy <mmur...@commonsware.com> wrote:
    > On Thu, Jul 12, 2012 at 7:39 PM, Peter Sinnott <psinn...@gmail.com> wrote:
    > > Is that new in JB? All I can manage to do is turn off the screen or
    > > reboot.
    >
    > I was able to get it working in a Galaxy Nexus running ICS, but only
    > after several tries.
    >

    3 devices with ICS ( HTC Desire / HTC One X / Asus Transformer )
    and none of them seem to do it. Probably something obvious I'm doing
    wrong.


    Mark Murphy

    unread,
    Jul 12, 2012, 8:09:50 PM7/12/12
    to android-d...@googlegroups.com
    On Thu, Jul 12, 2012 at 8:02 PM, Peter Sinnott <psin...@gmail.com> wrote:
    > 3 devices with ICS ( HTC Desire / HTC One X / Asus Transformer )
    > and none of them seem to do it. Probably something obvious I'm doing
    > wrong.

    Either that, or it's not universal. I just gave it a few tries on a
    Samsung Galaxy Tab 2 7.0, also running ICS, and could not seem to get
    it to trigger. Which is why we need some other trigger mechanism that
    isn't a button-ish form of the game Twister. The concept (let the user
    send system logs to who they wish) is sound, but it has to be
    something reasonable for users to accomplish.

    Zsolt Vasvari

    unread,
    Jul 12, 2012, 8:39:57 PM7/12/12
    to android-d...@googlegroups.com
    What are we talking about this in this thread?  I just tried the CatLog app on my official build (JRO03C) build on my Galaxy Nexus and it shows the logcat as it always has.  

    Dianne Hackborn

    unread,
    Jul 12, 2012, 8:52:45 PM7/12/12
    to android-d...@googlegroups.com
    On Thu, Jul 12, 2012 at 10:24 AM, Mark Murphy <mmu...@commonsware.com> wrote:
    On Thu, Jul 12, 2012 at 12:59 PM, Dianne Hackborn <hac...@android.com> wrote:
    > however every app can read the logs containing only the lines
    > *they* have written, without needing any permission.
    OK, I'll bite: how do you do this? Most of the read-the-logs code that
    I have seen uses logcat via Runtime#exec(), and I don't see a
    command-line switch on logcat to limit output to just your own
    process' lines.

    There is no command line switch.  The kernel drive does this based on whether you have the permission to access the full logs.  If not, it only gives you the logs associated with your uid.

    Dianne Hackborn

    unread,
    Jul 12, 2012, 8:55:43 PM7/12/12
    to android-d...@googlegroups.com, B...@jraf.org
    On Thu, Jul 12, 2012 at 1:07 PM, Kristopher Micinski <krismi...@gmail.com> wrote:
    > Do users even look or comprehend what permissions are being used in any
    > given app? The user wants the app, they agree, agree, agree and then get
    > malware.

    This is a problem with permissions, not specifically the read logs permission.

    The problem with the read logs permission is that it doesn't clearly
    map into something the user can think about.

    The user can see "reads logs" and may think, "oh, reading things the
    device does, like, battery, etc...?"

    But doesn't get that it basically can let you monitor when apps start,
    plus whatever stupid developers do to like leaking high security data
    to a public channel ...

    Yeah, ultimately, this just is not an appropriate use for a permission.  It is not the kind of app functionality that 99% of users can even comprehend, let alone have a chance of deciding whether it is okay for the app they are installing.  We have over the years gone through a number of different wordings of the permission, but at the end of the day it is just not something that can be sensible displayed to the user.

    So, it is now a development permission (a new concept introduced in JB), which will never be shown to users, but developers can enable through their development tools.

    Dianne Hackborn

    unread,
    Jul 12, 2012, 8:59:08 PM7/12/12
    to android-d...@googlegroups.com, B...@jraf.org
    On Thu, Jul 12, 2012 at 2:11 PM, niko001 <ebs...@gmail.com> wrote:
    I think that locking out developers from using APIs (and yes, I know that it wasn't part of the SDK) for security purposes is an entirely wrong approach.

    I will respectfully disagree with such a blanket statement. :)  If you are just going to say that this is a wrong approach, then why don't we allow apps to do anything they want?  Well we don't, because placing restrictions on apps is very important for the quality of the overall user experience and app ecosystem.  When we first did Android, we thought that the read logs permission was something that was okay to have on the side of allowing apps to use.  Years of painful experience has shown this was wrong.
     
    There are lots of legitimate reasons for reading the system logs at runtime. I could live with a solution as described by Dianne (granting access on a per-app basis through the system settings UI), but this should have been implemented at the same time as the lockdown of the "old" permission. Just because some developers forget to remove logs containing sensitive information, everyone else shouldn't be punished for their mistake. 

    As I said, the issue is far more than just some apps forgetting to not print sensitive information.  It ultimately is a pretty intractable problem to give apps access to the stuff that ends up in the log without opening all kinds of paths for abuse.

    Chris Stratton

    unread,
    Jul 12, 2012, 9:43:02 PM7/12/12
    to Android Developers
    On Jul 12, 7:43 pm, Mark Murphy <mmur...@commonsware.com> wrote:

    > I was able to get it working in a Galaxy Nexus running ICS, but only
    > after several tries.

    I think the actual issue is that it has a very long latency - during
    which there is no indication that it is working. And then gmail pops
    up. It really needs some visual feedback when the process starts.



    Chris Stratton

    unread,
    Jul 12, 2012, 10:01:55 PM7/12/12
    to Android Developers
    On Jul 12, 8:55 pm, Dianne Hackborn <hack...@android.com> wrote:
    >
    > So, it is now a development permission (a new concept introduced in JB),
    > which will never be shown to users, but developers can enable through their
    > development tools.

    What is duration of effect of a pm grant or pm revoke command? ie,
    does it survive reboot? What about re-install of the app in question?

    Also,

    "pm grant, revoke: these commands either grant or revoke permissions
    to applications. Only optional permissions the application has
    declared can be granted or revoked."

    sort of implies that there is a way to declare a permission optional
    in the manifest? Or is that more on the drawing board than yet
    implemented?

    Pent

    unread,
    Jul 13, 2012, 3:49:18 AM7/13/12
    to Android Developers
    Phew, something I *don't* use is disappearing for a change :-)

    > 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

    It's just power and vol down on my Nexus S 4.0.4.

    Could you mention since which OS version this is available ? It's
    already pretty fiddly with being different buttons and taking ages to
    show a sign of life, would be preferable if I don't ask users to try
    it when it's never going to work.

    Thanks,

    Pent

    BoD

    unread,
    Jul 13, 2012, 3:46:58 AM7/13/12
    to android-d...@googlegroups.com
    It is supposed to only show its *own* logs.
    And I confirm this behavior with CatLog on my own JB device.
    If you have a different behavior well I guess it's a bug ;)

    --
    B.LUBEK
    --
    You received this message because you are subscribed to the Google
    Groups "Android Developers" group.
    To post to this group, send email to android-d...@googlegroups.com
    To unsubscribe from this group, send email to
    android-develop...@googlegroups.com
    For more options, visit this group at
    http://groups.google.com/group/android-developers?hl=en


    -- 
    BoD

    Ievgenii Nazaruk

    unread,
    Jul 13, 2012, 4:54:45 AM7/13/12
    to android-d...@googlegroups.com
    I've tested the "adb shell pm grant <pkg> android.permission.READ_LOGS" and can confirm that it enables READ_LOGS permission for my application. 

    Here how persistent this granted permission is:
    1) Granted permission survives reboot.
    2) Granted permission survives application update (i.e. "adb install -r").
    3) Granted permission does not survive if application was uninstalled and then installed again.

    This is basically what I'd expect from this functionality. So basically the developer/tester flow I was worried about is actually covered by Jelly Bean. Which is good news. 

    Kostya Vasilyev

    unread,
    Jul 13, 2012, 10:14:29 AM7/13/12
    to android-d...@googlegroups.com

    2012/7/13 Mark Murphy <mmu...@commonsware.com>

    On Thu, Jul 12, 2012 at 7:39 PM, Peter Sinnott <psin...@gmail.com> wrote:
    > Is that new in JB? All I can manage to do is turn off the screen or
    > reboot.

    I was able to get it working in a Galaxy Nexus running ICS, but only
    after several tries.

    Works for me on stock 4.0.4 as well, but the "user experience" is really weird:

    1. There is a significant delay while the data is being collected / packed with no feedback of any kind.

    2. The keys that make up the combo continue to perform their primary function: i.e. whlie doing this, I get the "power off / airplane mode" menu, and the ringer volume slides all the way up (or down).

    -- K

    Zsolt Vasvari

    unread,
    Jul 14, 2012, 2:07:02 AM7/14/12
    to android-d...@googlegroups.com, B...@jraf.org
    Funny, today I tried it again and it only showed its own logs.  Yesterday, it showed all logs which I verified by starting another app's Activity.

    There is probably a bug somewhere where the permission is still granted somehow.
    To post to this group, send email to android-developers@googlegroups.com

    To unsubscribe from this group, send email to

    For more options, visit this group at
    http://groups.google.com/group/android-developers?hl=en


    -- 
    BoD
    Message has been deleted

    nnk

    unread,
    Jul 12, 2012, 2:29:20 PM7/12/12
    to Android Developers

    There's no documented, approved way to read the log entries.

    Having said that, if you just exec() logcat, as you did before, you'll
    automatically get your own log entries. You don't need to do anything
    special. The log system knows which log entries belong to you, and
    which log entries belong to others, and will only give you your log
    entries.

    -- Nick

    On Jul 12, 10:24 am, Mark Murphy <mmur...@commonsware.com> wrote:
    > On Thu, Jul 12, 2012 at 12:59 PM, Dianne Hackborn <hack...@android.com> wrote:
    > > however every app can read the logs containing only the lines
    > > *they* have written, without needing any permission.
    >
    > OK, I'll bite: how do you do this? Most of the read-the-logs code that
    > I have seen uses logcat via Runtime#exec(), and I don't see a
    > command-line switch on logcat to limit output to just your own
    > process' lines.
    >
    > (BTW, count me as one of the fans of this decision, despite the very
    > loud grumblings I expect you will receive from various quarters)
    >
    > Thanks!
    >
    > --
    > Mark Murphy (a Commons Guy)http://commonsware.com|http://github.com/commonsguyhttp://commonsware.com/blog|http://twitter.com/commonsguy

    Ran

    unread,
    Jul 15, 2012, 2:54:18 AM7/15/12
    to android-d...@googlegroups.com
    It seems that on the JB emulator everything works as before.
    Is that by design?

    Thanks.

    Ievgenii Nazaruk

    unread,
    Jul 15, 2012, 5:02:58 AM7/15/12
    to android-d...@googlegroups.com
    On my instance of JB emulator it runs with new behavior.

    Make sure you've started correct emulator, as I noticed several times that ADT/SDK 20.0 could start something else (non-selected item) from the list.

    Ran Manor

    unread,
    Jul 15, 2012, 5:08:13 AM7/15/12
    to android-d...@googlegroups.com
    I was definitely running the JB emulator.

    So if you install aLogcat on the emulator, you can see only your own app logs? and nothing else?

    - Ran


    --
    You received this message because you are subscribed to the Google
    Groups "Android Developers" group.
    To post to this group, send email to android-d...@googlegroups.com

    To unsubscribe from this group, send email to

    b0b

    unread,
    Jul 15, 2012, 6:33:57 AM7/15/12
    to android-d...@googlegroups.com


    On Sunday, 15 July 2012 11:08:13 UTC+2, Ran wrote:
    I was definitely running the JB emulator.

    So if you install aLogcat on the emulator, you can see only your own app logs? and nothing else?


    using aLogcat in the JB emulator I could see all system logs.

    Ran Manor

    unread,
    Jul 15, 2012, 6:45:54 AM7/15/12
    to android-d...@googlegroups.com
    me too. Isn't that the old behavior?

    - Ran


    --

    b0b

    unread,
    Jul 15, 2012, 7:41:15 AM7/15/12
    to android-d...@googlegroups.com
    in JB, a useful debug app like aLogcat becomes useless as it i unable to retrive the full log.

    I've had the perfect example a few mins ago. A JB user contacting me for an issue with my app and requiring that he send
    me a full log to troubleshoot WTF MediaPlayer is doing. Impossible easily on JB as aLogcat is not working anymore.

    vt

    unread,
    Jul 18, 2012, 12:58:10 PM7/18/12
    to android-d...@googlegroups.com
    On Friday, July 13, 2012 1:54:45 AM UTC-7, Ievgenii Nazaruk wrote:

    I've tested the "adb shell pm grant <pkg> android.permission.READ_LOGS" and can confirm that it enables READ_LOGS permission for my application. 

    How did you dodge "Operation not allowed: java.lang.SecurityException: Neither user 2000 nor current process has android.permission.GRANT_REVOKE_PERMISSIONS"?

    --vt

    Ievgenii Nazaruk

    unread,
    Jul 18, 2012, 2:32:50 PM7/18/12
    to android-d...@googlegroups.com
    I guess that's because I tried it on emulator. I don't have a device with JB to verify that same procedure works for real devices. 

    Kostya Vasilyev

    unread,
    Jul 18, 2012, 2:49:54 PM7/18/12
    to android-d...@googlegroups.com
    Just ran a quick test on my Galaxy Nexus with stock OTA 4.1.1

    1) Added the permission to the manifest:

    <uses-permission android:name="android.permission.READ_LOGS"/>

    2) Pushed an update from Eclipse, this appeared in the adb logcat:

    07-18 22:43:20.265 W/PackageManager(  306): Not granting permission android.permission.READ_LOGS to package org.kman.AquaMail (protectionLevel=50 flags=0x8be46)

    3) Tried to grant the permission:

    ~$adb shell
    shell@android:/ $ pm grant org.kman.AquaMail android.permission.READ_LOGS      
    Operation not allowed: java.lang.SecurityException: Neither user 2000 nor current process has android.permission.GRANT_REVOKE_PERMISSIONS.

    4) Who is user 2000?

    shell@android:/ $ id
    uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),1028(sdcard_r),3001(net_bt_admin),3002(net_bt),3003(inet),3006(net_bw_stats)

    Aha, it's the uid used by "adb shell".

    -- K

    2012/7/18 Ievgenii Nazaruk <ievgenii...@gmail.com>
    --

    Ievgenii Nazaruk

    unread,
    Jul 18, 2012, 3:01:37 PM7/18/12
    to android-d...@googlegroups.com
    Thanks for trying this out. Now it looks like that there is no supported way to grant development permissions on production devices. 
    2012/7/18 Ievgenii Nazaruk <ievgenii...@gmail.com>
    To post to this group, send email to android-developers@googlegroups.com

    To unsubscribe from this group, send email to

    vt

    unread,
    Jul 18, 2012, 4:22:21 PM7/18/12
    to android-d...@googlegroups.com
    On Wednesday, July 18, 2012 12:01:37 PM UTC-7, Ievgenii Nazaruk wrote:

    Thanks for trying this out. Now it looks like that there is no supported way to grant development permissions on production devices. 
     
    So, question to Android folks, then - what does it take to be able to debug the app on a non-rooted production device? Or, even simpler, to read/record logs like aLogCat and aLogRec do.

    Yes, it is possible to debug an app with USB debugging connected - but for a short time, Eclipse plugin doesn't offer much of a buffer.

    But what about debugging an app that has to run for a long, long time - weeks and months? What about debugging an app running on an Android device with ADK accessory connected - it's not even possible to connect adb to it now, is it?

    Even if an app can write its own logs, it's not sufficient - especially in a case where hardware is involved, events in the system logs have direct relation to what is happening to the app - and they're not available.

    --vt

    Mark Murphy

    unread,
    Jul 18, 2012, 5:11:35 PM7/18/12
    to android-d...@googlegroups.com
    On Wed, Jul 18, 2012 at 4:22 PM, vt <vadim.t...@gmail.com> wrote:
    > Yes, it is possible to debug an app with USB debugging connected - but for a
    > short time, Eclipse plugin doesn't offer much of a buffer.

    You are welcome to capture LogCat data via adb logcat. Or, there
    should be some Java code for getting LogCat over adb (what DDMS uses,
    particularly for the standalone edition), though that will be
    undocumented/unsupported in all likelihood.

    > What about debugging an app running on an Android device
    > with ADK accessory connected - it's not even possible to connect adb to it
    > now, is it?

    Use a ROM that enables adb over WiFi, or hope they add that to
    standard builds someday (last I checked, it only worked with Google
    TV).

    --

    vt

    unread,
    Jul 18, 2012, 5:42:29 PM7/18/12
    to android-d...@googlegroups.com
    On Wednesday, July 18, 2012 2:11:35 PM UTC-7, Mark Murphy (a Commons Guy) wrote:

    > What about debugging an app running on an Android device
    > with ADK accessory connected - it's not even possible to connect adb to it
    > now, is it?

    Use a ROM that enables adb over WiFi, or hope they add that to
    standard builds someday (last I checked, it only worked with Google
    TV).

    See, here's the problem - I'm not a commercial developer. I just don't have time for this - I barely have enough time to get the Open Source project I'm working on where it needs to be. It's a hassle that can be easily avoided - something tells me that *one* application that captures log output, and which has to be specifically installed on a device, won't be a security problem, or at least will significantly alleviate it. And if Google wants to release it, I'm sure they have enough manpower to make it happen.

    Or, oh horror, we can get a mechanism to selectively grant permissions (which has been an outstanding issue for quite a while now, with no resolution in sight).

    Can *I* do it? I think I probably can, though it is a major hassle and loss of time, 'cause this is just not what I normally do.
    Can a newbie do it? Well, I guess that'll be a showstopper for quite a lot of them.

    This issue is an obstacle - as usual, there's a tradeoff between security and convenience. It's just it's too skewed away from convenience this time.

    Mark Murphy (a Commons Guy)
     
    --vt 

    Kostya Vasilyev

    unread,
    Jul 18, 2012, 6:19:30 PM7/18/12
    to android-d...@googlegroups.com
    But... looking back at the thread's history, I don't believe anyone from Google has said that development permissions are activated with "adb shell pm grant".

    Perhaps the command to grant specifically development permissions is something else?

    -- K

    2012/7/18 Ievgenii Nazaruk <ievgenii...@gmail.com>
    To post to this group, send email to android-d...@googlegroups.com

    To unsubscribe from this group, send email to

    Mark Murphy

    unread,
    Jul 19, 2012, 6:48:00 AM7/19/12
    to android-d...@googlegroups.com
    On Wed, Jul 18, 2012 at 3:17 AM, Karthik
    <kart...@rapidvaluesolutions.com> wrote:
    > We are currently working on an ERP based Device Administration App in
    > android, which need to monitor other application and decide which one to run
    > and which one not to, based on server side policy.

    This cannot be implemented as an SDK application. Please create your
    own custom ROM for this.

    --
    Mark Murphy (a Commons Guy)
    Android Training in DC: http://marakana.com/training/android/

    Mark Murphy

    unread,
    Jul 19, 2012, 8:02:06 AM7/19/12
    to android-d...@googlegroups.com
    On Tue, Jul 17, 2012 at 6:05 AM, matteo sisti sette
    <matteosi...@gmail.com> wrote:
    > So, now a very simple question.
    >
    > How do I, the user, the owner of my phone and a human being, see the logs
    > and e.g. email them to myself for inspection, without rooting the device
    > and/or connecting it to a computer and/or running complicated command-line
    > stuff? I mean how do I do this in Jelly Bean?

    POWER + VOLUME-UP + VOLUME-DOWN, simultaneously pressed, should slowly
    generate a report that you can mail to wherever you want.

    vt

    unread,
    Jul 19, 2012, 10:44:52 AM7/19/12
    to android-d...@googlegroups.com
    On Thursday, July 19, 2012 5:02:06 AM UTC-7, Mark Murphy (a Commons Guy) wrote:
    On Tue, Jul 17, 2012 at 6:05 AM, matteo sisti sette wrote:
    > So, now a very simple question.
    >
    > How do I, the user, the owner of my phone and a human being, see the logs
    > and e.g. email them to myself for inspection, without rooting the device
    > and/or connecting it to a computer and/or running complicated command-line
    > stuff? I mean how do I do this in Jelly Bean?

    POWER + VOLUME-UP + VOLUME-DOWN, simultaneously pressed, should slowly
    generate a report that you can mail to wherever you want.

    If a leaf falls to the ground in a forest and no one hears it, does it make a sound?

    In other words, if your ADK app controls, say, an expensive aquarium with fish and corals in it (which can easily run into five figures), and you get back home after a week's vacation to find that a few days ago your app ran amok and boiled everything and your fish is dead, how is my cool ADK contraption better than a terminally dim PIC hack?

    - How do I make the bug report span across an arbitrary length of time?
    - How do I trigger a bug report generation, say, on a regular basis, or from inside an application?

    Mark Murphy (a Commons Guy) 

    --vt 

    Kristopher Micinski

    unread,
    Jul 19, 2012, 10:54:35 AM7/19/12
    to android-d...@googlegroups.com
    This is basically why things like ACRA were invented...,

    There's nothing stopping you from dumping your app's logs to a file
    and then syncing that with your backend periodically..

    kris

    vt

    unread,
    Jul 19, 2012, 11:11:40 AM7/19/12
    to android-d...@googlegroups.com
    On Thursday, July 19, 2012 7:54:35 AM UTC-7, Kristopher Micinski wrote:
    On Thu, Jul 19, 2012 at 10:44 AM, vt wrote:
     
    > If a leaf falls to the ground in a forest and no one hears it, does it make
    > a sound?
    >
    > In other words, if your ADK app controls, say, an expensive aquarium with
    > fish and corals in it (which can easily run into five figures), and you get
    > back home after a week's vacation to find that a few days ago your app ran
    > amok and boiled everything and your fish is dead, how is my cool ADK
    > contraption better than a terminally dim PIC hack?
    >
    > - How do I make the bug report span across an arbitrary length of time?
    > - How do I trigger a bug report generation, say, on a regular basis, or from
    > inside an application?
    >

    This is basically why things like ACRA were invented...,

    There's nothing stopping you from dumping your app's logs to a file
    and then syncing that with your backend periodically..

    App log is not enough. Earlier in this thread I mentioned that often, and in cases where hardware is involved, almost always, system logs contain information directly related to what is happening to your app.

    As for ACRA, isn't it also going to be crippled by READ_LOGS no longer granted?

    It starts looking like a security theater to me.

    All right, one can do all this if one gets the custom ROM to get the logs over WiFi (by extension: one can build a custom ROM which disregards READ_LOGS completely). Hence, a malicious party will be able to read logs no matter what *on device in their physical possession*.

    So, why is it not possible for a user to do the same on the production build, *on device in their physical possession*?

    kris

    --vt

    Kristopher Micinski

    unread,
    Jul 19, 2012, 11:15:37 AM7/19/12
    to android-d...@googlegroups.com
    >
    > App log is not enough. Earlier in this thread I mentioned that often, and in
    > cases where hardware is involved, almost always, system logs contain
    > information directly related to what is happening to your app.
    >
    > As for ACRA, isn't it also going to be crippled by READ_LOGS no longer
    > granted?
    >

    I don't think so? I would highly highly highly doubt that.., someone
    can confirm..

    > It starts looking like a security theater to me.
    >
    > All right, one can do all this if one gets the custom ROM to get the logs
    > over WiFi (by extension: one can build a custom ROM which disregards
    > READ_LOGS completely). Hence, a malicious party will be able to read logs no
    > matter what *on device in their physical possession*.
    >

    That's right, and that's why I always tell people that it's useless to
    do things like "hide" their code from the user / other programs...,
    Once you assume that your app can be run on things that aren't just
    stock firmware, you have a more interesting situation..

    Kostya Vasilyev

    unread,
    Jul 19, 2012, 11:44:04 AM7/19/12
    to android-d...@googlegroups.com
    In one of the prior messages on this thread, Dianne Hackborn mentioned her plans to implement a UI screen in Settings to enable READ_LOGS (for apps that have it in their manifest).

    One could hope that this screen, whenever it appears, will have a documented launch action - so that apps like CatLog, aLogCat, etc can prompt the user and bring this screen up.

    This scheme already works for third party keyboards - out of the ones I use, both Swype and Swift Key 3 (highly recommended) have a setup wizard that

    1) explains that the just installed keyboard needs to be enabled
    2) brings up the system settings screen where this can be done

    Very simple and it works.

    -- K

    2012/7/19 vt <vadim.t...@gmail.com>

    --

    matteo sisti sette

    unread,
    Jul 19, 2012, 4:46:02 PM7/19/12
    to android-d...@googlegroups.com


    El dijous 19 de juliol de 2012 14:02:06 UTC+2, Mark Murphy (a Commons Guy) va escriure:

    POWER + VOLUME-UP + VOLUME-DOWN, simultaneously pressed, should slowly
    generate a report that you can mail to wherever you want.


    Great! I thought you were making fun of me and that would reboot or something (lol) but that works :) 

    Ran

    unread,
    Jul 20, 2012, 5:50:19 AM7/20/12
    to android-d...@googlegroups.com
    I just got the OTA for JellyBean on my Nexus S.
    READ_LOGS apps seem to work as before.. I can see all the logs in alogcat.

    is this a bug?

    On Sunday, July 8, 2012 10:26:47 PM UTC+3, Ievgenii Nazaruk wrote:
    Hi all,

    I've been working on an application for developers that uses DropBoxManager. The DropBoxManager requires READ_LOGS permission to be granted in order to query information from it.

    Today I've tested my application on newest (api 16) emulator before releasing it to Google Play. It turned out that Android now refuses to grant this permission to 3rd party applications. This is weird because I've looked through all Jelly Bean's documented changes and couldn't find anything that mentions READ_LOGS permission.

    So basically my questions:
    • Did anyone see this change documented? 
    • Can someone confirm this behavior on Galaxy Nexus with Jelly Bean on it (the one released to attendees of Google I/O)?
    And questions to someone from Android team:
    • Why this breaking change wasn't described in documentations like READ_EXTERNAL_STORAGE was?
    • What should developers and testers do in order to use those handy utility applications that require READ_LOGS to be useful? Is there any way to allow READ_LOGS to 3rd party applications without making custom build (i.e. something in "Developer Options" that I could've missed)?

    vt

    unread,
    Jul 20, 2012, 10:49:50 AM7/20/12