Android 13: READ_LOGS permission changes

[xnumad]

Screenshot of dialog [1]
Choosing "Allow one-time access" for the READ_LOGS permission request apparently gives the Scoop service the permissions as long as it runs, meaning that at the latest after a reboot, it will lose the permission again.

Reference: https://issuetracker.google.com/u/0/issues/232206670#comment19

---

Issues:

1. (bug) Scoop doesn't reliably detect not having the permission:

Scoop status notification falsely reports "Monitoring app crashes" (scoop_running)
and "Permission status" setting states "READ_LOGS permission is granted"
but doesn't detect app crashes

Only after stopping the service via the notification and reopening the app, the Android dialog [1] appears, after which (granting permission) Scoop works.

2. (new functionality) With root permissions, there probably is a way to bypass this dialog.

---

[1] https://twitter.com/MishaalRahman/status/1559930174598270976

Not of priority to me, just want to report it.

[TacoTheDank]

Google's changes are so damn annoying lol. The changes in Android 13 are a lot more involved than in Android 12, but I'll get it done eventually.

[opusforlife2]

The tweet says it's possible through Shizuku, but is that the case for rooted users as well?

[RokeJulianLockhart]

#65 (comment)

In case it's not been aforementioned, the way to remediate after an OS, as a user, is to reapply the adb permission grant command, then force stop and reinitialise the application.

[bege10]

#65 (comment)

In case it's not been aforementioned, the way to remediate after an OS, as a user, is to reapply the adb permission grant command, then force stop and reinitialise the application.

This doesn't help here (Shiftphone 6mq, /e/OS (based on LineageOS for microG), Android 13). Although Scoop has root permission and I granted READ_LOG permission, after booting the device I need to stop the service, restart Scoop and give the requested one time permission.

[RokeJulianLockhart]

#65 (comment)

@bege10, that appears to be what I meant – reboot and restart the application – although I wasn't aware that AOSP supported application-added services (like SystemD or SysVInit does), ¹ if that's what you're referring to.

Footnotes

1. android.stackexchange.com/q/259345 ↩

[bege10]

#65 (comment)

@bege10, that appears to be what I meant – reboot and restart the application – although I wasn't aware that AOSP supported application-added services (like SystemD or SysVInit does), 1 if that's what you're referring to.

Footnotes

1. [`android.stackexchange.com/q/259345`](https://android.stackexchange.com/q/259345/311449) [↩](#user-content-fnref-1-e6902a2f34efaf5f40cb99819c640970)

It seems that I misunderstood your post #65 (comment). I thought the described procedure would solve the issue permanently but it doesn't.
I just referred to the process Scoop: crashDetectorService that I killed in a task manager.

As apps like Tasker and two log readers on my phone can read logs without problems this Scoop issue should be solvable at least on rooted devices.

[RokeJulianLockhart]

It seems that I misunderstood your post #65 (comment). I thought the described procedure would solve the issue permanently but it doesn't.

@bege10, that does indeed explain. It solely functions until the subsequent reboot for me, too.

As apps like Tasker and two log readers on my phone can read logs without problems this Scoop issue should be solvable at least on rooted devices.

Which log readers? If they're (F)OSS, that could be very useful.

[bege10]

Which log readers? If they're (F)OSS, that could be very useful.

Both have free versions but are not open source.