Kill App not working

[vertigo]

You can try to open Phone app after closing the second one then close it

True, and not a bad idea. I think I prefer to have the notification cleared right away, instead of leaving it there while I'm using the dialer, since that might make me forget it'll be dealt with when closing the dialer and think it's not working. Plus, I'd have to set a trigger both for closing the second dialer and for putting it in the background, since I usually don't actually close it but just switch to something else. I do like the idea, but I'm thinking I'll probably stick with the original way.

At this point, I'm less concerned about how to do this and more concerned about seeing if @Martin can do something like add a wait function as previously described, so if setting up a flow where the action immediately following a launch app action needs that app to be launched, it can be set to wait to execute that step until the app is actually open.

[Desmanto]

@vertigo : Do you mean something like option : "Wait until app is fully launched", only then it will continue to next execution. I don't know the implementation under the hood, but currently you can do that using loop sleep.

Add condition App Task Running, the main dialer. False, go to sleep 500 ms (try various sleep time) and back to the same condition. True continue the flow. You might need additional sleep after the loop to adjust for some delay.

[vertigo]

Yes, but as I mentioned before, using a sleep loop isn't ideal. It'll always end up waiting longer than it needs to (if checking every 500ms, if the app opens right after a check, it'll be 400+ ms delay before it proceeds) and use more processing time (the shorter the check interval to minimize the first issue, the worse this problem will be). Granted, not a huge deal, but if a function could be built in to the action, it could theoretically be instantaneous without using processing time, so the best of both worlds. It would, in theory, simply act the same as setting an additional trigger for the flow for when the app is opened, only it would carry on from that point instead of having to bring the flow from the trigger back down to that point based on that trigger. Though I do have another idea I plan to make a feature request for that would at least help with that.

[Desmanto]

If you need the loop, then it is ideal to use it, rather than having inconsistent flow (much more not ideal). Your time wasted on opening the second dialer will be much longer then (since you have to execute it manually). You should take the opposite scenario in the consideration.

Latency 500 ms is good enough, you can try 200 ms or less to see which suit you. Even if Automagic implement this, I think it will be approximately the same check under the hood. It will use loop to check if the app already started or not before continuing. This use approximately the same CPU power. The difference is it happens under the hood and we don't see it in the flow (and of course it save some elements for the loop). But we have no control over the latency (maybe it implement default 500 ms and fixed, not customizeable).

I used to try make everything as simple as possible, trying to make it very efficient, sacrificing other things. But sometimes there are better tradeoff. Every android phone, even at idle, already constantly writing a bunch of log continuously. So If I need it and it is unavoidable, then I will just write the log continuously too. The same thought, if we need the delay or the loop, then use it. Do not just because we want to be efficient, we take different route that cost much more in the end, wasting more CPU cycle or have inconsistent result.

All of our flows are not final and always bound to improvement. For current state, if this is the best we can do, use it. In the future if we think about better solution, then revise the flow. It is our flow, and we can change it at anytime, no restriction. Except if this is for public solution, contest or some long term usage; then careful consideration should be planned in the beginning to avoid future problem.

[Hit]

So @vertigo, what exactly what do you want to clear?

• The Notification on status bar

Or

• The Notification badge (on Launcher)

?

[vertigo]

@Desmanto - I think you misunderstand. I won't have to launch it manually. I'm saying one set of triggers would activate the flow when tapping the notification or when launching the third-party dialer (in which case it will perform a check to see if there's a missed call notification) and they will launch the stock dialer. Then another trigger will activate the flow when the stock dialer is launched and will launch the third-party one. So it won't take longer, it will be faster. If using a loop, it's using XPU cycles to keep checking for the stock dialer to be open before continuing, and if it checks, then 50ms later the dialer opens, it won't be until the next check (150 or 350 or however many ms) before it continues and launched the third-party dialer. Using the launch of the stock dialer as a trigger to run the flow and launch the third-party dialer would result in it happening immediately and without tying up the processor with a loop. Instead, it'll be activated like any other trigger. That makes it more consistent than a loop, not less, and more efficient, so win-win. And if a wait option were built-in, it stands to reason it could be set up to act as a trigger, essentially reactivating the flow in the same way it would be by an app task trigger, only starting at that point, not at the beginning of the flow like a trigger does. In other words, using the wait option would be the same as adding an app task trigger with a "trigger == App Task..." condition at the start of the flow to go to the block after the one where the wait option was used.

@Hit - The notification, but it's not enough to just remove it. That's easy, but simply removing it with Automagic doesn't reset the missed call count. There's apparently a system counter that can *only* be reset by the stock dialer. If I just remove it, every time I get a missed call it shows the cumulative number of missed calls.

[Hit]

I still have another idea to solve the situation:

• Trigger Notification clicked => Launch the second dialer <x> times (if need)

• Trigger Open second app => Launch Phone app=> Immediately Launch Second app <x> times

2 or more times launches may solve the problem second app not opened.

And if lucky enough, the operation happen too fast that the Phone app won't appear in recent if Trigger is the first one.

I hope this will work.

[Desmanto]

@vertigo : I understand that you want to combine it into single flow. When the flow already triggered by notif missed call, launch your main dialer. Then because you don't want to put delay, the flow doesn't continue consistently to open second dialer. That means, after the inconsistency, you have to manually launch second dialer then.

If you use different flow (separate it to 2 flows) to trigger using App Task Started I mention before in post #18, then you don't have this problem any more (as you currently have done). You can still combine the flow if you want, using expression to split the trigger.

[vertigo]

I've been doing a bunch of testing with this and have learned a couple things which have changed the requirements. First, removing the notification with Automagic somehow resets the counter, so if I use trigger "App Task Started: third-party dialer" with a condition to check if the missed call notification is there and remove it, that's all that's needed. The problem is resetting the counter if I tap on the notification, since doing so removes it, so I can no longer have Automagic remove it. The notification belongs to Call Management (com.android.server.telecom), so I tried using that every possible way in "Launch App" and "Start Activity" but couldn't get it to work. I thought maybe the counter was stored in a system variable, so I used the settings logger to check, but it's not. I tried using the notification removal as a trigger to launch the stock dialer, then launch the third-party dialer, but it turns out the stock dialer only resets the count if it's opened to the call log screen, but it opens by default to the favorites screen and there's no option to change the default screen and I tried all the different class names and none of them opened it to the call log screen.

So the only way I can think of to make it work is to keep the stock dialer set as the default phone app, so clicking the missed calls notification launches it instead of the third-party dialer, and when it does it opens it to the call log screen automatically (indicating that it's clearly possible, so I feel like there must be a way to do it). The problem with that is then it's in the recent tasks, since I'm not launching it with the exclude_from_recents flag. That means that unless I can figure out how to get it to open to the call log screen, I need to figure out how to swipe it from recents (as I said before, I can swipe or hit the x button, but I noticed it takes a second or two for the x buttons to show). I prefer not to use the control UI action if possible, since it's less predictable, can cause a problem if I try to tap or swipe when it starts doing its thing, and isn't as seamless.

So any thoughts on how to launch the stock dialer on its call log screen? If not, I could use help figuring out how to swipe it out (Moto Z Play).

Edit: I used the overlay control to record the swipe gesture, but no matter what I try (very short to very long duration, very short to very long swipe length), it doesn't work. With a short duration, nothing appears to happen. With a long duration, the app is slowly slid to the side then released, so it's not swiped off screen and therefore not closed.

[Hit]

For faster UI, you can turn off animation.