Status Update
Comments
ag...@gmail.com <ag...@gmail.com> #2
Note that supplementary group AID_LOG
(1007
)READ_LOGS
permission is granted with pm grant com.termux android.permission.READ_LOGS
to
~ $ uname -a
Linux localhost 5.10.102-android13-0-00549-g255b30f804ac-ab8238117 #1 SMP PREEMPT Tue Mar 1 10:31:42 UTC 2022 x86_64 Android
~ $ /system/bin/dumpsys package com.termux | grep READ_LOGS
android.permission.READ_LOGS
android.permission.READ_LOGS: granted=true
android.permission.READ_LOGS: granted=true
~ $ setpriv -d
uid: 10159
euid: 10159
gid: 10159
egid: 10159
Supplementary groups: 1007,3003,9997,20159,50159
no_new_privs: 0
Inheritable capabilities: [none]
Ambient capabilities: [none]
Capability bounding set: [none]
Securebits: [none]
Parent death signal: [none]
SELinux label: u:r:untrusted_app_27:s0:c159,c256,c512,c768
~ $ /system/bin/dumpsys package com.termux | grep READ_LOGS
android.permission.READ_LOGS
~ $ setpriv -d
uid: 10159
euid: 10159
gid: 10159
egid: 10159
Supplementary groups: 3003,9997,20159,50159
no_new_privs: 0
Inheritable capabilities: [none]
Ambient capabilities: [none]
Capability bounding set: [none]
Securebits: [none]
Parent death signal: [none]
SELinux label: u:r:untrusted_app_27:s0:c159,c256,c512,c768
kinda as per
logcat --help 2>&1 | grep -A3 -- "--uid"
--uid=<uids> Only display log messages from UIDs present in the comma separate list
<uids>. No name look-up is performed, so UIDs must be provided as
numeric values. This option is only useful for the 'root', 'log', and
'system' users since only those users can view logs from other users.
I assume there is some calling uid
check in logd
if this is intentional and not a bug since adb
shell
user 2000
can successfully read all system wide logs. There are no errors in logcat
either when apps try to read logs, other than entries like
I/logd: logdr: UID=10159 GID=10159 PID=6821 b tail=0 logMask=99 pid=0 start=0ns deadline=0ns
I/logd: logdr: UID=2000 GID=2000 PID=6838 b tail=0 logMask=99 pid=0 start=0ns deadline=0ns
The READ_LOG
permission still exists as a development
permission.
$ dumpsys package android | grep READ_LOGS
Permission [android.permission.READ_LOGS] (6866ab8):
perm=PermissionInfo{e0fb091 android.permission.READ_LOGS}
android.permission.READ_LOGS: prot=signature|privileged|development, INSTALLED
android.permission.READ_LOGS: granted=true
android.permission.READ_LOGS: granted=true
Reading logs is pretty useful for many apps/users and does require adb
or root
to grant the permission so shouldn't be some big security risk since intentional action by user after significant effort. Having to set up wireless adb on every boot to read logs would be really inconvenient.
sa...@google.com <sa...@google.com>
jo...@gmail.com <jo...@gmail.com> #3
I saw the update on the new beta and saw the pop-up asking for access to the logcat. Thanks for making it a visible permission! That's progress!
Unfortunately my app is an automation app which mostly runs in the background, making it unfeasible for the user to always have to click the "Allow one-time access" button. That could make logcat monitoring stop working if the user is not actively using the phone.
Would you please consider adding a "Allow access in background" button for use cases like automation apps, where users will trigger automations based on what's in the logcat?
It's super useful for use cases like doing different actions depending on which finger you use to unlock your phone for example (among an almost infinite amount of other use cases):
Thanks in advance.
ra...@google.com <ra...@google.com> #4
ra...@google.com <ra...@google.com> #5
ls...@gmail.com <ls...@gmail.com> #6
The information of which fingerprint unlock the phone can only be obtained via accessing logcat information.
ch...@gmail.com <ch...@gmail.com> #7
jo...@gmail.com <jo...@gmail.com> #8
Since allowing log access via ADB requires significant effort by the user (ADB by itself requires technical skills by the user), having an additional prompt to confirm the action every single time will render this feature in automation apps useless. Security risks are also probably minimal as it does require the user to specifically grant the automation app such access via ADB AND to know hot to set up ADB to begin with.
Maybe you can have the prompt have an option to "always allow" in addition to "allow just one" or "deny"
jo...@gmail.com <jo...@gmail.com> #9
Thanks for taking the time to look into this.
For an example of how this is implemented in my app, take a look at this short video:
Basically the app allows the user to monitor the clipboard with any keyword/expression the want and when that keyword/expression shows up in the logcat, it'll trigger any action they want.
I use it on my phone to instantly open the camera in video mode when I unlock my phone with a specific finger for example, because when I unlock my phone with a specific finger, a specific log shows up in logcat, which allows me to trigger an intent to open the camera app in video mode at that time.
As you can see above in the other replies, many users use this for various purposes in their specific day-to-day lives.
There are an almost infinite number of possibilities of automations with logcat that are not possible otherwise so if you could please add a "Always Allow" button as mentioned above, that would be really great.
Thanks again.
ag...@gmail.com <ag...@gmail.com> #10
There are "some" implementation details publicly available at
As already mentioned that there are infinite number of possibilities of automations with logcat, that are often device specific. One can react to system and third party apps or system services logging something in their specific stage. Most of the events are not available with android APIs and even though they are not official APIs, they are still useful since its really efficient and no alternative are often available. One can make even make a bit more complex projects like
Another advantage is that all these can be received in native code instead of requiring some java app to use some android API. This makes it easier to process logs in shell scripts like in termux.
Another advantage or "hack" (again not an official API) is communication/signal between two processes in same or even different app without requiring additional socket/server setup or requiring java code to listen to activity manager broadcasts. Something similar was added in 60f37bde
Issue with the permission dialog being handled by LogcatManagerService
is that its not considering that logcat
commands may be run often or more than once. Users can setup multiple Logcat Entry
event profiles with different filters and all running processes are also stopped and restarted whenever user updates tasker config with changes, which may happen every few seconds or minutes when writing and testing tasker code. So if user sets say 5 or 10 events, then that would require 5 or 10 acceptances to allow tasker to read logs which is obviously highly user unfriendly. On top of that, OOM kills would restart apps, which would happen often on low RAM devices, which would again require same number of acceptances every now and then and user may accidentally dismiss the dialog or grant or revoke access if hes in another flow and not expecting the dialog, making some events not work anymore, and requiring to start them all over again. This would also happen for startup scripts run every time an app like termux in started. There is also some delay between dialogs if multiple commands are run in sequence.
The preferred way would be to have an Allow all the time
option which persists across reboots shown in the dialog itself, specially considering it would have taken much effort to setup adb and grant permission in the first place, but if security is still too much of a concern, this can be handled like location permission is, where Allow all the time
option is not shown in the dialog when an app requests the location permission and user has to go to location permission activity in app info itself to set that value, although that can be granted with ACCESS_BACKGROUND_LOCATION
from adb too.
I/ActivityTaskManager: START u0 {flg=0x10008000 cmp=android/com.android.server.logcat.LogAccessDialogActivity (has extras)} from uid 1000
...
D/LogcatManagerService: Allow logd access for uid: 10158
...
D/LogcatManagerService: Decline logd access for uid: 10158
Moreover, there seems to be a bug where an Allow %s to access allow device logs?
message is being shown before the dialog is shown and is not dismissed if user clicks outside dialog or dialog times out. Check attached screenshot.
Thanks
eu...@google.com <eu...@google.com> #11
Disallowing background access is working-as-intended. We would discourage any type of automation testing relying on logcat
. Trying to communicate with logcat
without an interaction with the developer/users are not intended use case.
ag...@gmail.com <ag...@gmail.com> #12
Trying to communicate with logcat without an interaction with the developer/users are not intended use case.
But there will be an interaction. A user has to setup adb or root to grant the permission. All we are asking is that there is a persistent option for the user and permission is not asked again each time logcat command is run.
You can also add a allow till next reboot option in the logcat permission dialog for a uid. That should be acceptable too from a security and usability perspective. Then it is technically not a "background access" since user will have to accept prompt in foreground either one time or till reboot at least once per reboot. You can keep allowed UIDs map in memory and no filesystem storage will be required either, so lesser coding too. I thinks this is a reasonable request, don't you think? Or any reason why even this isn't?
This is not just about automation apps, a developer running following in an app shell will be asked each time when logcat
command is run, which is obviously annoying and not user friendly. Same case with AOSP DumpViewer
app
logcat -d | grep something
logcat -d | grep something-else
...
Trying to communicate with logcat
I only mentioned that as a hack or native alternative to intents, it was obviously not a recommendation for general use.
Thanks
jo...@gmail.com <jo...@gmail.com> #13
Hello. Thanks for the feedback, but this is not about "automation testing". This is about automation apps like Tasker:
Users use these automation apps to automate every day things in their lives, in this case, based on what appears in Logcat.
This change is also annoying for other use cases like #12 mentioned.
Please consider simply allowing the logcat to be read upon user permission. Thanks
fb...@gmail.com <fb...@gmail.com> #14
That's not the purpose of Tasker's Logcat event context. It is to allow the developer/user to be able to react to entries in the logs in order to take relevant action. This is extremely useful for debugging apps that only reveals a bug at specific moments. This could be during a meeting, or whilst asleep and would automatically trigger a routine, such as logging the event. This totally removes the need to stay attached to a PC.
It also has use cases of providing additional security, as we can log events such as when an app accessed camera, or microphone, or location, or vibrator or even threw an overlay on your screen.
Without rooting, this is the best method for keeping tabs on potentially suspicious apps and keeping tabs on the ones force installed we can't disable.
The added steps noted above take away the ability of more fluidic app debugging, detailed app logging and some otherwise impossible automation routines that aid and assist people with Accessibility and Special needs.
From an Android user with Autism.
wy...@gmail.com <wy...@gmail.com> #15
he...@gmail.com <he...@gmail.com> #16
Please reconsider. Accessing logcat has many uses, bug/crash reporting, shell terminal apps, automation apps, etc..
Privacy in not a concern since granting android.permission.READ_LOGS
requires root or ADB, and without the permission only log entries from the current app process are visible.
ti...@gmail.com <ti...@gmail.com> #17 Restricted
de...@gmail.com <de...@gmail.com> #18
[Deleted User] <[Deleted User]> #19
There is also the app called Scoop (
It works by parsing logcat logs, so it's hardly usable on Android 13 as well.
el...@gmail.com <el...@gmail.com> #20
Google's attempts to increase the security of Android at the expense of automation applications and requiring manual interaction with the screen for unlocks and additional prompts for pretty much everything is directly harmful to people with disabilities.
ki...@gmail.com <ki...@gmail.com> #21
ro...@gmail.com <ro...@gmail.com> #23
ma...@gmail.com <ma...@gmail.com> #24
ig...@gmail.com <ig...@gmail.com> #25
In my case I use it to catch logcat entries of googles clock app to set my self made day light alarm half an hour before the first alarm goes off.
so essentially my bedroom lights up slowly while time approaches the first alarm.
you are saying that stuff like this is not intended use.
then if it is not intended use, why don't you provide such functionality yourself?
the Google clock app has Google assistant integration. it only triggers AFTER an interaction with a alarm that went off tho. so clearly a missing use case here.
secondly:
Samsung does a lot of weird things with android.
I run a S22 Ultra right now and extended my s-pen beyond Samsungs intended capabilities with tasker..
again.. relying on logcat.
want to detect if the power button is held?
logcat.
want to detect if volume down is tapped three times?
logcat.
want to detect what finger was used to unlock the phone?
logcat.
stop implying there are official ways.
we all know such features take years (if they get implemented at all) to be added to android.
you took something away without considering power users.. again..
this is a common google pattern today, even though googles original way was primarily targeted towards power users.
please reconsider.
at least make it permanently available through developer options and / or adb.
ka...@gmail.com <ka...@gmail.com> #26
"Not an intended use case" is a strange response. It's one thing if we're requesting additional functionality. Deliberately making logcat access unusable is a massive step backwards, especially for devs and power users. Can it at least be a developer option?
I've chosen Android for the past 10 years because I'm a dev and a power user. I like being able to automate things on my phone. I consider it a differentiating factor versus Apple. However, responses like "not an intended use case" totally fly in the face of power users.
We are aware of the "risks" and "unintended use cases", now can we please just acknowledge this once in a prompt and never see it again?
ni...@nickbetcher.com <ni...@nickbetcher.com> #27
We would discourage any type of automation testing relying on logcat.
Why? No, I know — Google gets a lot of bad PR about poor privacy, but that's the name of the game when you have a flexible and extensible system.
For performance reasons? Yes, just about anyone who has the skill set to grant the READ_LOGS permission understands that's a risk. The rest are of no consequence because they'll find a way to get themselves into trouble no matter what you do. I've witnessed it countless times.
Trying to communicate with logcat without an interaction with the developer/users are not intended use case.
What use case exactly is intended? Let's review the facts as we know them:
- Your one-time dialog is annoying to those of us who took the time to get that permission and requires the display be on and keyguard unlocked to approve it;
- It doesn't stop the average user from any sort of privacy loss. Just like sideloading APKs, users will do anything to make something work.
- Your one-time dialog is per boot, requiring it to be approved every boot, rendering many security-at-boot/security-after-decrypt automation use cases completely 'use'-less.
- Your intended use cases are not disclosed, documented, described, elaborated upon, or entirely logical based on your user base and their needs. (Subjective)
- Your one-time dialog doesn't always prompt for permission and ultimately denies the calling app the permission in those circumstances. THIS FURTHER DESTROYS ALL OF YOUR INTENTIONS.
- We have had all other alternative means of accomplishing these automation tests taken from us (described in other issues on here), or not implemented at all.
- Power users, one of your largest user bases (subjective, but in my experience, it's true), have no other means to which to fight these changes other than to vote with our money.
Disallowing background access is working-as-intended.
As intended by whom? When these architects and system designers decided to make these intentions, did they, in advance, consider use cases similar to those listed in this Issue? Unless they did, it's logical to conclude that the change should be immediately reverted since defending a change after it is made is significantly easier than justifying it in advance in-lieu of strong counter-arguments.
I understand you cannot satisfy everyone, but by making these types of decisions, you're sending a clear message to those of us who have stuck with you this whole time that the reasons we use Android (and recommend them to others) are not important enough in order to remain a unique, flexible, and exceptionally powerful platform. Logically, if I wanted a cookie-cutter platform, I would just switch to iOS.
If this were an isolated incident from Google affecting automation, I wouldn't be writing this long-winded, desperate plea. Google continues to demonstrate a lack of forethought to both its power-user user base and its developers when it makes these decisions that completely mangle automation. There are many, maybe even hundreds of these types of decisions on here and there is rarely, if ever, a good reason that clearly pays off to all parties in the end, especially the average user. (I say this based on extensive observation.)
Furthermore, I have had to make the personal decision to halt all further upgrades to Android, including 13, because of your decision. Upgrading to Android 13 would significantly compromise the security of my data on my devices since persistent, unubated READ_LOGS is required for my security hardening automation. It cannot be accomplished through any other means without compromising the security of the device even further.
Maybe I seem a bit doom-and-gloom, but can you afford to assume myself and those in this and every other issue like it are categorically wrong about the implied-direction Android is heading with these types of changes?
Sincerely,
Nick Betcher
Software Developer and System Administrator with over 25 years of real-world experience.
ci...@gmail.com <ci...@gmail.com> #28
At least add an option "until restart" to the pop-up.
jo...@gmail.com <jo...@gmail.com> #29
ch...@gmail.com <ch...@gmail.com> #30
I use Tasker for automation on my Android 13 device. This change to Logcat permissions has broken some of the functions I had set up.
For example, I had set up a "rule" in Tasker to detect when ADB WiFi is enabled and read the Logcat to find out which port Android assigned. Since enabling ADB WiFi using the Quick Setting tile or in developer options will assign a random port for ADB WiFi, and there doesn't seem to be any API or system setting that stores this information, I depend on the Logcat entry to know what port the ADB WiFi session was started on.
I occasionally use the program "scrcpy" to mirror my screen on a PC so I can stream mobile games on platforms like Twitch, and this automation rule, combined with functions on my PC, allows me to press a single button on my Android device and have Tasker collect the information I need from Logcat and send it to my PC to automatically start the screen mirroring session.
I support adding/restoring a means to grant permission to automation apps like Tasker so that they can reliably access and read all Logcat entries without restriction.
I don't mind some security checks, such as how ADB checks permission from the user before authorizing a remote computer to connect (and it gives a checkbox to remember that decision). This way, when a user grants the READ_LOGS permission, a dialog on the device will ask to confirm that the user understands the risk and wants to allow unrestricted access to Logcat via the specified app. This should NOT be a recurring dialog that needs to be confirmed each and every time the app requests to read logs. The permission should be persistent (with a "one time" access being OPTIONAL) and only should need to be re-granted in special circumstances, such as when the app package is updated.
(Alternatively, an API could be added as a middle-man to allow Automation Apps to be notified of specific Logcat entries matching a filter. As well as an API to query the details that we're using Logcat to find, such as what port an ADB WiFi session was started on, or which finger was used last to unlock the device.)
sh...@gmail.com <sh...@gmail.com> #31
You should reconsider.
This issue has reached levels of a absurdity at which it has become difficult to stay calm and keep my composure. Enforcing such a setback on all users is a ridiculous and even detrimental when considering the security risks involved in the currently available alternative methods.
me...@jooniloh.com <me...@jooniloh.com> #32
More and more Android feels like an operating system developed by people who don't daily drive it as their primary mobile OS, and certainly not any power users.
jo...@gmail.com <jo...@gmail.com> #33
li...@gmail.com <li...@gmail.com> #34
se...@mechacynic.com <se...@mechacynic.com> #35
ba...@gmail.com <ba...@gmail.com> #36
sh...@gmail.com <sh...@gmail.com> #37
li...@gmail.com <li...@gmail.com> #38
li...@gmail.com <li...@gmail.com> #39
li...@gmail.com <li...@gmail.com> #40
jb...@oddelement.com <jb...@oddelement.com> #41
I cannot wait for a more open alternative to Android. Google: you've lost it. I'm only still here because other options are even shittier than Android... but someone will solve that problem, and I can't wait for that day.
pa...@gmail.com <pa...@gmail.com> #42
wa...@gmail.com <wa...@gmail.com> #43
an...@gmail.com <an...@gmail.com> #44
as...@gmail.com <as...@gmail.com> #45
ko...@gmail.com <ko...@gmail.com> #46
dc...@gmail.com <dc...@gmail.com> #47
Well, now Android is turning into a pair of safety scissors too. But these safety scissors are left-handed and held together with duct tape. If I am not going to have any control over my device anyway, I may as well switch to iOS. At least then my phone will work properly.
Description
Yes
TPB1.220310.029
Yes
Google Pixel 2 (Android 11) and Pixel 5 (Android 13)
This is a regression from Android 12 because previously all logs would be visible
Framework
Logs from all apps should be visible.
The permission was always of type here . This has now changed with no warning and was not mentioned in the changelog.
signature|privileged|development
, which allowed it to be granted via ADB as shownOnly logs from the running app were visible instead of all system logs.