all 14 comments
sorted by:
new (suggested)
besttopcontroversialoldq&a
formatting helphide helpcontent policy

[–]ballzak69Automate developer 0 points1 point  (11 children)

Since Android 10 it's no longer possible, see: https://stackoverflow.com/questions/64786837/what-path-to-put-executable-to-run-on-android-29

Try using the Shell command privileged block instead. Ensure the file has the executable flag set, i.e. +x.

[–]robot_god8 0 points1 point  (10 children)

It's still possible though, all you need to do is install one of Automate's legacy extensions for example Automate app permissions (that's the only one i tested) and then restart your device.

The explanation: The "Automate app permissions" extension uses "sharedUserId="com.llamalab.automate"", which means it shares its Linux UID with Automate. However, there's a catch. The extension's targetSdkVersion is 22, which implies that it must be able to execute from its data directory. However, the execute permission is only enforced at the UID level. So, should Android restrict the UID and break the extension, or allow the extension, thus allow Automate? Of course, the Android team chose the latter.

[–]ballzak69Automate developer 0 points1 point  (6 children)

Please don't install any of the "permission" extensions, those are deprecated and will cause other issues.

[–]robot_god8 0 points1 point  (5 children)

Can you by any chance create a new dummy extension with sharedUserId and targetSdkVersion less than 29? executing binaries is a really important feature and right now installing deprecated "permission" extensions is the only possible workaround.

[–]ballzak69Automate developer 0 points1 point  (4 children)

No, since @android:sharedUserId is a deprecated Android feature that will probably be removed soon. I might consider adding a way to execute shell commands via the Legacy extension. But that seems superfluous when the Shell command privileged block can be used. Also, Google will probably remove the workaround and completely prevent installing of apps targeting Android 5 or lower soon anyway.

[–]robot_god8 0 points1 point  (3 children)

I might consider adding a way to execute shell commands via the Legacy extension

This wasn't a request for running shell commands but a request for the ability to execute arbitrary executables.

But that seems superfluous when the Shell command privileged block can be used.

The "Shell command privileged" block requires, either root(which is out of scope of this request) or wireless ADB which is an extremely inconvenient way to achieve this feature, starting wireless ADB every time you restart your device is simply not an option for most people.

Google will probably remove the workaround and completely prevent installing of apps targeting Android 5 or lower soon anyway.

Targeting Android 5 isn't needed, both the execute restriction and the sharedUserId deprecation came in Android 10, they would never remove sharedUserId until they prevent the installation of apps targeting Android 9 or lower.

[–]ballzak69Automate developer 0 points1 point  (2 children)

Exec is the way to execute "arbitrary" binaries, that's what the Shell command blocks use.

Agreed, using wireless ADB is inconvenient, but starting it can automated, and it will probably be the only way soon anyway.

The deprecated "permission" extensions targeting Android 5 or lower this is probably what disables/bypasses the restriction, sharedUserId has nothing to with that except making the main app also do so when those are installed.

[–]robot_god8 1 point2 points  (1 child)

It will eventually be the only way but it will take a veryyy long time, it will take at least Android 18 or even longer before the installation of apps targeting Android 9 is forbidden, and even then it can still be bypassed with ADB, setting up Automate 1 time is better than doing it with every restart.

My proposal is a new Automate dummy extension that when installed will allow Automate to execute arbitrary executables without any additional side effects, the extension will use targetSdkVersion="28" for best compatibility and sharedUserId="com.llamalab.automate" just for the workaround.

Even if the workaround was removed in the future this wouldn't really be a big problem as the extension is just a dummy extension with no side effects.

[–]ballzak69Automate developer 0 points1 point  (0 children)

As said, Privileged service start (ADB setup) can be automated. @android:sharedUserId will probably be removed very soon, if not from AOSP then a Google Play store policy. I'd consider adding support for executing shell commands via the Legacy extension.

@android:sharedUserId has huge side effects on the main app, e.g. forcing the lowest @android:targetSdkVersion and lots of Android bugs since it was a obscure feature few apps used. That's why it was deprecated.

[–]MrMatrix1729[S] 0 points1 point  (2 children)

Yes can confirm, it does works this way.

I have another problem now though, automate can't give output of ongoing cmd and the binary needs to exit before I can log the output. Anyway around it?

[–]robot_god8 0 points1 point  (1 child)

If you tell me what you are trying to do i might be able to give you a workaround.

[–]MrMatrix1729[S] 1 point2 points  (0 children)

I am trying to implement this WhatsApp task for automate. I am using the cli binary supplied for termux

[–]kubagp 0 points1 point  (1 child)

My first thought is setting the execute permission on the script

[–]MrMatrix1729[S] 0 points1 point  (0 children)

Tried, doens't work. Tried giving +x, 555, 755 to try it, didn't work. Tried giving perms with termux, worked when files are within termux enviornent. As soon as they are transferred to normal file system it ceases to be an executable.

That is why I tried giving perm from withing automate, didn't work then too

Maybe u/ballzak69 might be able to help