Make Shell Script action 100% reliable.

[sampleuserhere]

Title says.

Concern

I have about 90% successful rate with this particular action. The majority of the execution ran the same exact line and yet these line failed occasionally due to timeout.

Executing through MD helper didn't introduce much different results either. It still failed occasionally. It's so weird.

This is the line I mention above. It retrieves the current foreground activity.

dumpsys activity activities | grep "mResumedActivity" | cut -d "{" -f2 | cut -d " " -f3 | sed "s/\///g"

Why do I use this instead of {fg_app_package}? Because the said magic text takes account overlay as well.

Magictext text for foreground app consistently returns different results compared to dumpsys and other plugins after certain situation. A bug?

Current behaviour {fg_app_name} and {fg_app_package} return current occupying foreground app. However if an overlay recently has just popped up or been interacted with, it returns that last overlay app instead. Demo. Expected behaviour {fg_app_name} and {fg_app_package} return current...

www.macrodroidforum.com

It doesn't return app activity as well, which is the important part. I can't really settle with 5 seconds wait time then run the line once again either. I use this line to run different routines based on the activity I'm in when I perform an edge gesture.

Here's an example.

https://imgur.com/ySTBxZh

I swiped down to add an action in EditMacro activity, and while I was already in AddAction activity, swiping down added Set Variables instead. I do many other stuff as well which depends on the same mechanism.

I hope this could demonstrate why it's important for me to have this action this 100% reliable & quick.

TIA.

 

[Quidn]

Title says.

Concern

I have about 90% successful rate with this particular action. The majority of the execution ran the same exact line and yet these line failed occasionally due to timeout.

Executing through MD helper didn't introduce much different results either. It still failed occasionally. It's so weird.

This is the line I mention above. It retrieves the current foreground activity.

dumpsys activity activities | grep "mResumedActivity" | cut -d "{" -f2 | cut -d " " -f3 | sed "s/\///g"

Why do I use this instead of {fg_app_package}? Because the said magic text takes account overlay as well.

Magictext text for foreground app consistently returns different results compared to dumpsys and other plugins after certain situation. A bug?

Current behaviour {fg_app_name} and {fg_app_package} return current occupying foreground app. However if an overlay recently has just popped up or been interacted with, it returns that last overlay app instead. Demo. Expected behaviour {fg_app_name} and {fg_app_package} return current...

www.macrodroidforum.com

It doesn't return app activity as well, which is the important part. I can't really settle with 5 seconds wait time then run the line once again either. I use this line to run different routines based on the activity I'm in when I perform an edge gesture.

Here's an example.

https://imgur.com/ySTBxZh

I swiped down to add an action in EditMacro activity, and while I was already in AddAction activity, swiping down added Set Variables instead. I do many other stuff as well which depends on the same mechanism.

I hope this could demonstrate why it's important for me to have this action this 100% reliable & quick.

TIA.

I don't see what causes your problem exactly.

It seems that you have enough skill and experience, so I think you might tested already:

• Whether other applications(e.g., Tasker, ADB) results 100% reliably the same command in your device
• Whether MacroDroid shows unacceptably high failure rate no matter what command is

So you figured out that the failure point is MacroDroid, and requested to improve reliability, is this correct?

I do agree that some features and especially advanced features like this of MacroDroid are not "100% reliable". But I'm afraid I don't think what you said is specific enough nor straightforward to get easily.

If all assumptions above are true, or MacroDroid is the cause in any way, it definitely should be improved to lower the failure rate.

By the way, the term of "100%" looks very unfamiliar to me as an OCD who always trying to achieve "100%".

 

[Endercraft]

@sampleuserhere I tried the same command as yours (I changed it a bit as it didn't return any output) and all of my 1000 tests on both MacroDroid and helper were successful. Maybe it's a problem on your device, or the way you check if the result is successful.

 

[sampleuserhere]

I don't see what causes your problem exactly.

It seems that you have enough skill and experience, so I think you might tested already:

• Whether other applications(e.g., Tasker, ADB) results 100% reliably the same command in your device.
• Whether MacroDroid shows unacceptably high failure rate no matter what command is.

So you figured out that the failure point is MacroDroid, and requested to improve reliability, is this correct?

I do agree that some features and especially advanced features like this of MacroDroid are not "100% reliable". But I'm afraid I don't think what you said is specific enough nor straightforward to get easily.

If all assumptions above are true, or MacroDroid is the cause in any way, it definitely should be improved to lower the failure rate.

By the way, the term of "100%" looks very unfamiliar to me as an OCD who always trying to achieve "100%".

I also can't even tell what the problem might be. All I know is that the same line fails occasionally, the system log doesn't says much either beside shell script terminated due to timeout.

Tasker has been working great. I had this project initially done with Tasker. The case with Tasker is that it returned the result 100%, but if the queue were too busy, the execution got delayed.

I haven't done a long-term test yet with termux, the command does work though.

@sampleuserhere I tried the same command as yours (I changed it a bit as it didn't return any output) and all of my 1000 tests on both MacroDroid and helper were successful. Maybe it's a problem on your device, or the way you check if the result is successful.

The activity pattern might be different, the modification I used may throw off the result because of that.

I haven't tried looping the line yet, since my invocation time is pretty much random. Do you mind attaching the macro?

I have two ways at my disposal to check the macro. Reacting to the system log trigger and reading the system log directly. I attached the macro category below.

I can't say for sure if it's my device or not, Tasker hasn't failed me yet with the code. It got delayed if the queue is busy, so I decided to move this one to Macrodroid instead.

Anyway, I wonder if running them with an action block makes a difference?

 

[Endercraft]

 

[sampleuserhere]

View attachment 6657

Thanks, I also happened to have the same result as you did with the macro you shared. 100% success rate.

But I found something else instead .

I could consciously lower the rate by running an action block which contains shell script action. There wasn't any "Shell script terminated" log, so my other monitor didn't pick it up. However several out variable is indeed empty. The action block ran as a shortcut from an egde gesture app.

https://imgur.com/FP1EYOu

This seems like a different kind of issue though. The action was logged as successful without any terminated reason despite the result being empty. What happened to me is more of the action itself got terminated due to timeout and it was logged properly. The only similar trait is that both failed to generate the right output.

 

[Quidn]

I also can't even tell what the problem might be. All I know is that the same line fails occasionally, the system log doesn't says much either beside shell script terminated due to timeout.

Tasker has been working great. I had this project initially done with Tasker. The case with Tasker is that it returned the result 100%, but if the queue were too busy, the execution got delayed.

I haven't done a long-term test yet with termux, the command does work though.

What about this:

• Whether MacroDroid shows unacceptably high failure rate no matter what command is

Or at least whether there are certain pattern to drastically increase failure rate or not - I think this is a very important clue to figure out why and solve the problem.

---

However several out variable is indeed empty.

I didn't investigate yet but is it abnormal if output is empty?

I tried the same command as yours (I changed it a bit as it didn't return any output)

Me either to do grep mResumedActivity returns empty.

Anyway you said Tasker got 100% so let's assume that it shouldn't be empty.

• What about if do grep other keywords?
• What about if execute other commands with do grep and sed?

 

[sampleuserhere]

What about this:
Or at least whether there are certain pattern to drastically increase failure rate or not - I think this is a very important clue to figure out why and solve the problem.

I don't think the code is relevant. I have one macro that runs a simple echo line upon screen on and it still fails occasionally too. You can check it out in the category I shared before.

I didn't investigate yet but is it abnormal if output is empty?

It is, the same line returns something in the same environment and yet it won't later in random occurrences.

Anyway, I tried running completely different codes than what I have in action block and the macro shared by @Endercraft returned everything. I suspect that some of the actions return empty if they were running the same line. So I did another test.

https://imgur.com/ZJ7Tuqb

In the screen record, I tested the actions 3 times.

1. It conflicted and returned empty output.
2. Removed the later part, it conflicted and returned empty output.
3. Removed the some part of the grep, it didn't conflict and succeed in 100% rate.

The changes on grep made the difference. However I haven't confirmed if the same grep is what actually caused this.

While this gave me an idea why some of the script actions return empty. It still doesn't really tell much about my own concern. There wasn't any timeout during the test with @Endercraft's macro during the loop. There was a few, at the beginning but I couldn't reliably replicate them either.

I guess this more of like a bug? but it doesn't sound like one either since the code works wonder for the majority of the time.