Ok, so you already know how to replicate the Samsung Galaxy S4′s wave-to-answer feature on any phone using Tasker. That’s all good an well, but when you find yourself at that pool party with those obnoxious S4 users, you need something to one-up them, not just match them. So, I had this idea for another call answer system, but one that’s based on voice control.

The idea is simply to use Voice Control as a way to answer calls without using your hands. Unlike wave-to-answer, it has the ability to by fully hands-free, and it also has the ability to do more than one thing, since you can use dynamic commands. You can also combine it with wave-to-answer to actually trigger it, rather than have it always be there.

Creating something like this in Tasker isn’t all that hard, but it’s definitely more complicated than the wave-to-answer feature, and you’ll need to be comfortable with variables to do it. The “problem” is that you can do anything you want here, so providing a step-by-step guide is sort of counter-productive. Instead, I’m going to provide you with a couple of examples, showing you various ways this can be implemented. If this is your first foray into Tasker, you shouldn’t start with this, but rather the basics.

Example 1: Fully hands free voice control system

First off a video to show you how this version of the system works:

The advantage of this is that it’s completely hands free, requiring no waving or other gesture to activate. The disadvantage is that it needs to be used in silent mode to avoid the ringtone and vibrations to interfere with the voice control recording, which means that you basically need to be nearby to hear it go off. It is however possible to configure it to for instance play an alarm sound for a few seconds before doing anything, but since this basically needs to go through the motions to get to the voice control aspect, that means you might end up waiting longer than necessary to pick up.

Anyways, here’s the profile description:

Profile: Voice Control Call Answer
Restore settings disabled

Contexts:
State: Phone Ringing
State: Not Proximity Sensor

Task:

  • Say [ Text:The phone is ringing, what should I do? ]
  • Get Voice [Timeout (Seconds):20 ]
  • If [ %VOICE ~ *answer* ]
    • If [ %VOICE ~ *speaker* ]
      • Take Call
      • Wait [Seconds:1]
      • Speakerphone [ Set:On ]
    • Else
      • Take Call
    • End If
  • Else
    • If [ %VOICE ~ *decline*/*hang up*/*shut up* ]
      • End Call
    • Else
      • Say [ Text:Sorry, I didn't get that ]
      • Goto [ Type:Action Number Number:2]
    • End If
  • End If

This example uses an inverted proximity sensor context to only make this run when the phone isn’t in a pocket or other such place, but other examples of ways to control when it’s active would be when you’re at the office, when the phone is flat on the tablet, when you’re in your car (Bluetooth connected context), and so on.

It starts off by asking what to do, which is essentially a replacement for the ringtone, since this won’t work well with a ringtone of vibrate activated (the sound would interfere with the voice control). It then waits 20 seconds for a reply using the Get Voice action.

After that, it checks the contents of %VOICE, which stores the voice input from Get Voice. If it contains the word “answer”, it does another check to see if it also contains the word “speaker” in any form (speaker, speakerphone, etc). If it does, it answers with speakerphone activated, if not, it simply answers.

If %VOICE doesn’t contain “answer”, on the other hand, it checks for a variety of other phrases that essentially mean “hang up”, such as “decline”, “hang up”, and “shut up”. You can specify multiple possible options using the / symbol when creating If conditions, and this is just a way of making it more dynamic in what it responds to. If it detects this, it simply hangs up.

Failing all of the above, it simply assumes that it didn’t hear you correctly, lets you know this, and returns to the Get Voice action to try again.

Example 2: Proximity sensor-based voice control trigger

This isn’t much different than the above, but it works very differently. By combining the above profile with aspects of the wave-to-answer profile from yesterday, you gain the ability to keep using vibrate and ringtone functionality like usual, and simply trigger the voice control option with your hand. It looks like this in practice:

The profile is nearly identical, and looks like this:

Profile: Proximity-activated Voice Control Call Answer
Restore settings disabled

Contexts:
State: Call [ Type:Incoming ]
State: Proximity Sensor
State: Orientation [ Is:Face Up ]

Task:

  • Silent Mode [ Mode:On ]
  • Say [ Text:What should I do?]
  • Get Voice
  • If [ %VOICE ~ *answer* ]
    • If [ %VOICE ~ *speaker* ]
      • Take Call
      • Wait [Seconds:1]
      • Speakerphone [ Set:On ]
    • Else
      • Take Call
    • End If
  • Else
    • If [ %VOICE ~ *decline*/*hang up*/*shut up* ]
      • End Call
    • Else
      • Say [ Text:Sorry, I didn't get that ]
      • Goto [ Type:Action Number Number:2]
    • End If
  • End If
  • Silent Mode [ Mode:Off ]

The main difference is the contexts, which now uses the logic from yesterday’s post to trigger this profile. Since the profile is now not triggered by the call itself, but rather the moment the proximity context is fulfilled, we also need to enable silent mode at the beginning of the task to mute the phone while it does the voice control aspects. Because disabling Restore Settings is necessary for this to work, we also need to manually re-enable silent mode at the end of the task- all we need is for it to be silent while the voice control actions are at work.

Update: This profile uses the Call state context, which actually refers to a call in progress, not just the phone ringing. This is because the context that detects the ringing is an Event context, meaning it will trigger right when the phone rings, rather than stay active while it’s ringing. Since we need to use the proximity sensor as the actual trigger for this, we can’t use that Event context, so we have to use the Call context. Because of this, the profile will re-trigger if anything is detected by the proximity sensor while the call is active. This shouldn’t be an issue for most people, but if it is, there are several ways of fixing it. Here’s one example that I’ve tested to work:

Create a new profile, choose the Event category, and pick Phone Idle as the context. That means the task attached to it will run once when you hang up. Add a task, go to the Tasker category of actions, and pick Profile Status. Find the wave-to-answer profile in the list, and set it to turn it on. Next, go into the task for this profile. At the very bottom, add a new action, find the Profile Status action again, specify the same profile name, but now set it to turn it off.

What this does is that the task now disables its own profile when it’s done doing everything else. The profile is however re-enabled the moment you hang up your call, meaning it’s ready for next time.

Other customizations

Like I said, these are just two examples. You can do things slightly differently, or you can use completely different methods to arrive at the same basic functionality. You can split things out into different profiles to achieve different functionality, integrate it with existing creations, and so on and so forth.

You can also customize the actions that run based on %VOICE in completely different ways. You might not need the ability to reply without speakerphone at all, which means it would be silly to have it there. You might however want an option to hang up, but reply to the person with an SMS, either using voice-to-text or other methods.

I should also note that because the phone is still ringing until the voice control feature finishes, it’s advisable to not have Say actions go on forever, as that would risk the person hanging up or being sent to voice mail. In fact, simply dropping the Say action at the beginning might be a better solution for some when combining this with proximity activation.

This is simply one of those creations where the basic idea is what I’m trying to get across, rather than providing a specific way of doing it. I showed you two examples, but there’s an infinite number of ways to do this. Either way though, it is sure to ruin the day of someone with a new S4- unless of course they’re aware that the device they’re buying is not special, in which case they can of course implement this on an S4 as well.