Allow Automate to access all device logs

[Mauro]

Each time I reboot my phone I have to grand this permission, since I only have "Allow one-time access" option; is there a way to give a permanent permission?

[Henrik "The Developer" Lindqvist]

Since Android 13 Google purposely added that dialog to break apps using it, see:

https://issuetracker.google.com/issues/232206670

Use the Interact block to simulate a click on the button, or use ADB shell command block to execute the alternative command if there's one, e.g. form the Log await block, see:

https://llamalab.com/automate/doc/block/log_await.html

[Mauro]

I think it's the Get clipboard change block; I tried looking at the blocks you mentioned, but I'm not sure how to use them to solve the issue.

[Henrik "The Developer" Lindqvist]

The block didn't change, but as said Google made it so that dialog is always shown when an app tried to use the READ_LOGS permission.

[Mauro]

Sorry, I wasn't clear: I didn't mean the block changed, but that in my flow I think it's the block named "Get clipboard change" to cause the issue; I'm trying to solve it using the blocks you said, but at the moment I didn't understand how to do it.

[Henrik "The Developer" Lindqvist]

Indeed, the Clipboard get block with proceed=When changed do rely on the READ_LOGS permission on Android 10+, which will show the dialog on Android 13+.

[Mauro]

Any way to solve this in a flow with a loop starting with "Clipboard get"?

[Henrik "The Developer" Lindqvist]

As said, try using the Interact block to simulate a click on the button, e.g.:

1. Flow beginning

2. Fork

2.1. Delay: 0.5

2.2. Interact block: Action=Click, XPath= //*[@android:text='Allow one-time access']

3. Clipboard get; Proceed=When changed

[Mauro]

Thanks, I'll try that way; I didn some attempt with that block but I wasn't able to make it work.

[Mauro]

It works when I launch it from Automate, but it doesn't if I launch it from desktop, or if it's already running (like at system restart, of after a while after I launched it); I guess that's because the dialogue doesn't appeare, is there a way to solve this for a flow continuously runinng?

(Also, not sure why, when it does work it writes two copies of the copied item.)

[P. Andreas Schmidt, IVE]

I guess one part of the problem is indeed that the dialogue only appears when you open the flow (or block?) and so you'll need another solution, I think, no?

But apart from that, even if that wasn't the case, and the dialogue appeared every time the logs were read, since you don't loop back after the interact block, that just stops after the first time it hits the button for you, and then no more... So you'll have to connect the yes and no paths back to the delay, also. 

Since there's an alternative for the log wait block using adb commands, I guess there might be an alternative that way, too - but we'll have to wait for Henrik to tell us (or google it).

[Mauro]

Thanks; I tried googling it, to no avail, but I'll try again later on.

[Henrik "The Developer" Lindqvist]

So the dialog doesn't appear unless Automate is in the foreground?

Otherwise just loop back to the Fork so the it tries to click the button every time, if the dialog would appear.

Another alternative is to use ADB shell command to await the logged message, then copy the clipboard, e.g.:

1. Flow beginning
2. Fork

2.1. Clipboard get: Proceed=When changed /* just to get the system to log the message below */

3. ADB shell command: logcat -T1 -m1 ClipboardService:E -e "Denying clipboard access to com.llamalab.automate, application is not in focus nor is it a system service for user [0-9]+"

4. Clipboard get: Proceed=Immediately, Text content=clip

5. Log append: Message=clip

(loop back to #3)

See: https://llamalab.com/automate/doc/block/log_await.html

[Mauro]

Yes, that's the problem.

Is there a missing piece? You use a fork, but there is no second branch mentioned (as 2.2, as you did before); and should the loop be at 2.1, to wait another clipboard change?

[Mauro]

I tried doing:

1. Flow beginning

2. Clipboard get: Proceed=When changed

3. ADB shell command: logcat -T1 -m1 ClipboardService:E -e "Denying clipboard access to com.llamalab.automate, application is not in focus nor is it a system service for user [0-9]+"

4. Clipboard get: Proceed=Immediately, Text content=clip

5. File write:: clip

(Loop back to #2)

but I got an error in the ADB block: com.llamalab.automate.RequiredArgumentNullException: alias

[P. Andreas Schmidt, IVE]

Hi there Mauro. This is not going to work, you'll need the fork, and I think you misread/understood Henriks instructions. There's a 2.1 with the clipboard get, that's the one connected to the New path of the fork, #3 is connected to the go path. Without the fork, this will not work. Though I think that you might also need to loop the clipboard get block back on itself, or else it will just work the once. I think you meant that, too, no? But most likely not, since that message that ADB is waiting for, will not trigger the clipboard get block, so ... it should never advance.

Your adb error means you haven't configured it fully. Concretely it's saying you still need to (create first if you haven't in order to) pick a keychain alias. If you don't know how adb works, you'll have to read up on that first, there's plenty on the net and here on the forum, too, I think. Have you enabled developer settings? And have you adb on another device (PC, Mac...) and connected that to your phone first (since you've got A13, try Wifi adb)? Else you won't be going far. Then you can make a keychain, and connect ... 

Good luck

[Mauro]

Thanks, I totally misunderstood it, I'll try as you say. So I should loop the Clipboard get on 2.1 on itself, right?

I have ADB and developer enabled, I have no idea what's a keychan alias, but I'll google it; thanks again.

[Mauro]

I think I was able to do it, thanks; just some questions:

1) Wireless debugging has to be turned on? It keeps turning off by itself, so I was wondering if it's possibile for this to work with wireless  debugging   off.

2) Are VPN and wifi certificate both viable? I'm not sure which one I'm using, since it didn't find the certificate, then it failed pairing, so I tried them both.

3) How can I uninstall the key? It's enough to unpair the device under wireless  debugging  ?

[P. Andreas Schmidt, IVE]

1) No, you can also do it through USB, but wireless allows you to use it without currently being connected through USB - I think.

2) As far as I remember only wifi are viable. Install just one, and the use that. 

3) somewhere in the system settings, can't remember now, perhaps under (user) certificates or so... 

I don't have a wireless debugging option in my developers options, but I can activate it on my pc, to connect to my phone, and after that picking a wifi key, and putting in 127.0.0.1 and the port I used from my PC, without pairing or so, I can run adb through AM...hope this helps

[Mauro]

I'll try that way, thanks; right now I'm trying to remove the pairing, the "remove" option on my phone doesn't seem to work.

[Mauro]

I was able to remove it by removing the pairing with my PC, not sure if the other being impossible to remove was a graphical glitch or what happened.

[Henrik "The Developer" Lindqvist]

The Fork NEW path should just be the Clipboard get with Proceed=When changed, then end. It's just to make the system log the warning message.

On Thursday, July 6, 2023 at 3:21:49 PM UTC+2 Mauro wrote:

[Henrik "The Developer" Lindqvist]

No. The Fork should not loop.

[Mauro]

Thanks, I'll try that way; in that Flow is the adb block that waits for the next copied item?

I'm also trying to solve the issue with wifi debugging turning itself off amd having to rely on wifi, which could made the flow useless if I don't have access to a wifi.

[P. Andreas Schmidt, IVE]

You should have a look at this thread about a flow and ADB WiFi, I think you'll find a solution there to your problem.

I also could activate wireless ADB that way, and pair not as in the flow with the open ip of the phone but the localhost.

But you could use it eg to monitor the setting and automatically reactivate wireless ADB.

Good luck

--
You received this message because you are subscribed to a topic in the Google Groups "Automate" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/automate-user/PqG96mGKr9U/unsubscribe.
To unsubscribe from this group and all its topics, send an email to automate-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/ff82aa39-ff8d-46ec-9d79-12a9fc81cd66n%40googlegroups.com.

[Mauro]

Ok, thanks, I'll take a look; did you leave out the link to the thread you mention?

[P. Andreas Schmidt, IVE]

Sorry my bad here's the link:

/r/Android/comments/128eak8/you\_can\_start\_shizuku\_automatically\_on\_boot/

To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/2184b5e6-5079-4ef7-adb0-e2fc6ee4d53en%40googlegroups.com.

[P. Andreas Schmidt, IVE]

Or the full link:

https://www.reddit.com/r/Android/comments/128eak8/you_can_start_shizuku_automatically_on_boot/

[Mauro]

I was able to make the pairing, but I need something that works also without wifi; if there is no way to go around that I'll see if I can find some other solutions, thanks for all your help.

[Shari Shark]

You can try this flow.

https://llamalab.com/automate/community/flows/45752

I had just released it but you need to figure out the setup once. The setup is kinda complicated but works well once you get it going. 

You received this message because you are subscribed to the Google Groups "Automate" group.
To unsubscribe from this group and stop receiving emails from it, send an email to automate-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/11c693e0-3fbe-4f9f-a92f-1b03ffa5b751n%40googlegroups.com.

[Mauro]

Thanks, I'll try it, let's hope it works also without wifi connection. When I have Shizuku and that set up I just have to follow the instruction here for the clipboard script?

[Shari Shark]

You only need Wi-Fi once after rebooting to start Shizuku or when Shizuku stops, which is very rare. After that Wi-Fi is no longer necessary. 

This is a generic flow for running adb commands. You most likely have to change the adb commands to point to this flow instead.

There's a start block that's only meant to be called by other flows. It's block #1 "run command".

To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/539510dc-e9f1-4dc9-9fc4-497f76ca1489n%40googlegroups.com.

[Mauro]

Do you mean the adb block in the flow suggested by Henrik? If so, how should I change it?

[Shari Shark]

Use the flow start block and point it to this flow's "run command" block. 

To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/356ba9a3-6f24-4746-b0d6-b404a558ed4dn%40googlegroups.com.

[Mauro]

Sorry, I don't follow you; this is the flow suggested by Henrik:

1. Flow beginning
2. Fork

2.1. Clipboard get: Proceed=When changed /* just to get the system to log the message below */

3. ADB shell command: logcat -T1 -m1 ClipboardService:E -e "Denying clipboard access to com.llamalab.automate, application is not in focus nor is it a system service for user [0-9]+"

4. Clipboard get: Proceed=Immediately, Text content=clip

5. Log append: Message=clip

(loop back to #3)

Where should I point to Run command in your flow?

[Shari Shark]

Replace 3. ADB shell command: with the flow start block and point to the Shizuku's "run command" block. The command should remain the same. 

You can consider this Shizuku flow as a drop in replacement for adb shell. 

To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/f4f4a7b5-f04b-4131-83b9-c923861377cdn%40googlegroups.com.

[Mauro]

Ok, thanks, I'll try that way as soon as I can.

[Mauro]

I'm trying this, but I got an error:

07-20 09:46:59.748 F 12701@52: android.os.RemoteException: Remote stack trace:
at com.android.providers.settings.SettingsProvider.enforceWritePermission(SettingsProvider.java:2331)
at com.android.providers.settings.SettingsProvider.mutateGlobalSetting(SettingsProvider.java:1475)
at com.android.providers.settings.SettingsProvider.insertGlobalSetting(SettingsProvider.java:1429)
at com.android.providers.settings.SettingsProvider.call(SettingsProvider.java:457)
at android.content.ContentProvider.call(ContentProvider.java:2533)

Also, should I put also the IP in block #28?

[Mauro]

I'm trying to check this, but I'm not sure about a thing: to pair with with localhost and not the IP did you use the flow?

[Shari Shark]

Ah, you need the automate settings permission. You can install it from here https://play.google.com/store/apps/details?id=com.llamalab.automate.ext.settings

No need to put ip as it defaults to localhost. 

To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/cc24444c-88b8-4404-bc49-0b981f5f9a7dn%40googlegroups.com.

[Mauro]

Also, when inserting logcat -T1 -m1 ClipboardService:E -e "Denying clipboard access to com.llamalab.automate, application is not in focus nor is it a system service for user [0-9]+" as payload in Start Flow, I get an error "Expected EOF but found NAME" with "ClipboardService" highlighted; should I insert the payload with quotes?

(Sorry about all the messages, I'm trying to google this things but I never used adb and the like so it's quite challenging.)

[Shari Shark]

Oh ya, you might also need this permission.

You should be able to run this using the "command dialog" block or via adb on usb. This only needs to be done once. 

"pm grant com.llamalab.automate android.permission.WRITE_SECURE_SETTINGS"

[Mauro]

Your script now works, thanks; I can't insert the command  logcat -T1 -m1 ClipboardService:E -e "Denying clipboard access to com.llamalab.automate, application is not in focus nor is it a system service for user [0-9]+"  as payload, though.

[Shari Shark]

What's the error? I'm not familiar with logcat. Can you try a simple command first to see if it works?

Use the command dialog and type "whoami". If it works then you can look further into the logcat command.

To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/4977549e-9e5d-4cac-9199-3caa3e304ba1n%40googlegroups.com.

[Mauro]

The error is  "Expected EOF but found NAME" with "ClipboardService" highlighted, and I get it while saving it in Start flow; if I try whomai I get it's not a variable, now I tried using quotes around the command and escaping the quotes already in it, I'll try if this work or I'll thinkering around, thanks.

[Shari Shark]

Ah, it's sounds like a problem with the quotes. Yes, you got to tinker with escaping the quotes. 

And the command is whoami, not whomai. 

To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/48df1d1f-7de4-4320-b359-373059afab36n%40googlegroups.com.

[Mauro]

With that setup and Henrik's flow the clipboard flow just keeps going instead of waiting for a clipboard change, and yours keeps launching fibers (I had to delete it to stop it, and it had like 35 fibers going).

I'm not sure this is solvable at this point; I'll see if anything comes to mind, thanks for all your help.

[Shari Shark]

That's just odd. If you are using the "run command" block then it's just a single iteration. There's no loop so can't be this flow.

I assume you are looping the get clipboard block right? Break the loop and see if the flow continues to run fibers. 

To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/6223c967-00ea-41be-9cdb-3c3d1c857953n%40googlegroups.com.

[Mauro]

Yes, I'm looping as per Henrik's flow, so the Clipboard get to the Flow start (used in place of adb command to launch Shizuku); without that loop there is no infinite fibers in Shizuku. I'm not sure why the loop count keeps increasing, but as per the clipboard fiber since in the loop there is nothing waiting for a change I guess it's normal it just keeps running the loop continuously.

This is Shizuku's log with the loop:

07-20 11:20:38.545 I 13039@1: Flow beginning
07-20 11:20:38.776 I 13039@2: Shell command

[several times both of the previous lines]
07-20 11:20:42.009 U 13026@3: , , 137,
shizuku: logcat -T1 -m1 ClipboardService:E -e "Denying clipboard access to com.llamalab.automate, application is not in focus nor is it a system service for user [0-9]+"
07-20 11:20:42.009 I 13026@0: Stopped at end

[several times both of the previous lines]

[Shari Shark]

3. ADB shell command: logcat -T1 -m1 ClipboardService:E -e "Denying clipboard access to com.llamalab.automate, application is not in focus nor is it a system service for user [0-9]+"

4. Clipboard get: Proceed=Immediately, Text content=clip

5. Log append: Message=clip

(loop back to #3)

This is the cause of the infinite loop. Basically the shell command completes and you get the clipboard. Then it loops over and over again. You will need am exit condition to determine when you should break out of the loop.

To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/14e40db1-176d-43e9-8dda-484a056a94acn%40googlegroups.com.

[Mauro]

I was afraid that's the case; when there wasn't this problem with Android, I just had a When changed in Clipboard get, so the loop started only when I copied something, but with this flow it goes on indefinitely; not sure how I should change it, if it's enough / if it would work just setting both Clipboard get to "When changed", but since Android's problem I'm not sure. I'll try, thanks.

[Shari Shark]

I don't quite get what you are trying to do but I think you shouldn't just loop to #3. You probably need to add a condition somewhere.

1. Flow beginning

2. Fork

2.1 Clipboard get: Proceed=When changed /* just to get the system to log the message below */

3. ADB shell command: logcat -T1 -m1 ClipboardService:E -e "Denying clipboard access to com.llamalab.automate, application is not in focus nor is it a system service for user [0-9]+" are looking for

4. Clipboard get: Proceed=Immediately, Text content=clip

5a. Expression true? If get clipboard true, Log append: Message=clip then loop to #2.1

5b. Expression true? If get clipboard false, loop back to #3.

Not sure if this is what you are looking for. 

To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/9b2c096b-933f-4c53-9e6a-1afcf134860fn%40googlegroups.com.

[Mauro]

Sorry, since initially it was a question about the specific issue maybe I never said what I'm trying to do; maybe this helps, it's the previous flow:

The idea is, it waits for something to be copied, then if the foreground app is a specific one it copies the clipboard in a file; this allows me to have a clipboard history of a specific app.

[Shari Shark]

Yes then I think you need to check if the clipboard contents are copied. If it's copied, then go to the #2.1. Otherwise loop to try to copy the clipboard again. So the changes i suggested might work. 

To view this discussion on the web visit https://groups.google.com/d/msgid/automate-user/efb3e74d-b27e-4f61-b749-14f355c7c646n%40googlegroups.com.

[Mauro]

I'll try, but 5.a seems would stop as soon as it the clipboard changes again (since 2.1 doesn't go anywhere), while 5.b would keep looping; am I wrong?

Also, how should I check if clipboard contents are copied? I was thinking about checking if clip is set to something, if so I can log the content then set it to nulla again, not sure if you meant something else.

Then I'll have to understand how to fit the app check in all of this, I'm kinda hating Google right now.

[Mauro]

I read in the new update Clipboard get can work using ADB; could this solve this issue? I'm trying to use it, and at the moment I granted the READ_LOGS permission via ADB, to no effect.

[Henrik "The Developer" Lindqvist]

There's no need grant that permission if the "Privileged service" option is selected as "Clipboard" workaround, since the log is opened as ADB or root.

[Mauro]

Sorry, I thoght that option was an alternative to "Privileged service", I misunderstood; I'll try and update here for future reference, thanks.

[Mauro]

It works, thanks.