Search results

First I have stopwatch timers running almost daily without noticing things taking longer than they should. Second what I do before starting a stopwatch to ensure I can restart it if macrodroid resets is this: 1 I save the current system time to a variable. 2 I add to that variable the amount...

Specifically, what are you looking to do based on the system time?

Android occasionally kills processes and if the process is a service, it automatically restarts. That is what I meant by MacroDroid restarting (ie doing what it is supposed to do when the os stops it).

The trigger already exists and I use it macros to ensure interrupted actions such as stopwatch timers are resumed correctly.

The trigger macrodroid initialized would cover not only the first time macrodroid starts after a reboot but also if macrodroid restarts due to a software update or an android os forced macrodroid restart (which happens occasionally). I would be interested in that trigger to ensure that some...

The thread @FrameXX referenced identifies the plug in to use. However, in terms of your question about the button appearing after a period of time, I would suggest a loop that waits 15 seconds between attempts and if TouchTask sees the text break out of the loop and click on the button. I hope...

Remember macrodroid variables persist and generally do not require reinitializing. Therefore, you should only need this on phone boot.

I had not thought of using modes thank you for the suggestion. However, since the original question was related to ensuring the designated macro ran first before the others instead of the others not running at all, your solution would have to be modified so that the other macros to run at boot...

In theory this would work assuming your intended order is maintained and you correctly call the next link in the chain. But again, since macrodroid variables retain their values what exactly would you be initializing?

So in theory if you track wake lock state with a global variable, you can set a wake lock if it is currently false and cancel if it is currently true (potential constraint).

Thank you sir

I was trying to create a proof of concept macro to illustrate the use of loops to better control pauses (to the millisecond). However, when I tried to run the macro in 5.23,the repeat loops were skipped as though not even present. Here is the link to the POC macro I posted. The first loop...

While building in this functionality would be ideal, I can envision a way to do this using loops. However, while I was trying to build a test macro to illustrate this, I found that the repeat action (variable # of times) loop is no longer working in MD version 5.23. Here is the link to the POC...

One thing I would point out is that variables persist between reboots so in theory, you would only need to set them once and then update them as needed.

Snurre, If the phone restarts without you having a chance to disable all other macros, your suggestion would not work.

Back in January, I actually put together and shared a proof of concept macro to ensure a stopwatch would resume and trigger as expected after a macrodroid reset. You can find the thread here. Thread 'Test macro to ensure stopwatch trigger persistence'...

You might have to come at this differently. Instead of trying to force one macro to launch and complete before the others, all you need to do is make sure the macro of interest completes before the other macros start being processed. Instead I would have the initializing macro record as it's...

The stopwatch has a limitation that if macrodroid is reset the stopwatch does not restart or resume. This means that your macro would need to take that into account or it may fail to run as expected if macrodroid resets.

Of course to complicate matters, app in foreground or not is not a macrodroid trigger which means we need some other way to start the macro and then use of statements to test if your app remains in the foreground....

I think the problem is related to application open and closed. Android does not close applications when you leave them or always need to start applications when you next "open" therefore, I would suggest checking/triggering on if the app is in the foreground or not.