Say works in Tasker, but not in apk, do I need extra permissions...

[CazMaz]

Hello everyone,

I have a task using Say, Get Voice and so forth in Tasker which works really well in Tasker, but when I export it to an APK, the TTS doesn't happen.

My settings in Tasker for the engine are set to default:default, which was the default setting when I first added the step.
The task uses the text received event to trigger.  I tested the task using flash messages and had full success, which led me to the following questions.

Do I need an extra permission added when exporting?
Do I need to Bind the service?
Do I need an intent?, Or do i need to write a setting allowing my apk to use accessibility on the phone?
Or do I need to take a vacation from TTS?

I'm thinking that whatever Tasker uses for the TTS activation (Which, again works well), is what I need to do.

Looking for some suggestions -- and love the Tasker program!

If my sig doesn't post:

Tasker 1.6u2m
ATT Samsung i927 S2
Rooted, SIM unocked
Android 2.3.5

[Pent]

Did you try it with a specific engine/voice ?

Pent

[CazMaz]

Hi Pent,

In my Android settings, the default TTS is PICO. I also have used Ivona in the past and selected that as the default, too.
The Tasker task works fine either way...

No, I just use the default engine setting as 'default:default'. I'm trying to be flexible so that the end user could have any TTS installed.

ReadSms (46)
Run Both Together, Stay Awake
A1: If [ %HOOK ~ on ] this is set by another task to see if the phone is ON the hook (NOT In Call)
A2: Keyguard [ Set:Off ]
A3: Flash [ Text:Incoming Text from %SMSRN
%SMSRB
%SMSRF Long:On ]
A4: Say [ Text:Text from %SMSRN

The Message is %SMSRB Engine:Voice:default:default Stream:3 Pitch:5 Speed:5 Continue Task Immediately:Off ]
A5: Perform Task [ Name:MSGResponse Stop:Off Priority:7 Parameter 1 (%par1): Parameter 2 (%par2): Return Value Variable: ]
A6: End If

The perform task goes on to use the Get Voice, and the script continues according to the voice response...
It works in Tasker, but not when I make the apk.
I will try default:en and see what happens.
CazMaz

[CazMaz]

Hi Pent,

As an update, I changed the voice engine default:default to a variable %Vengine.
That way i can change it once and it will be the same through out the task.

It is set to 'com.svox.pico:eng-USA'

CazMaz

[CazMaz]

Hi everyone,

I'm  trying different things, I'll post this for now, but expect to make a lot of changes.

Profile: Vext (48)
Event: Received Text [ Type:Any Sender:* Content:* ]
Enter: ReadSms (46)

Run Both Together, Stay Awake
A1: If [ %HOOK ~ on ]

A2: Keyguard [ Set:Off ]
A3: Flash [ Text:Incoming Text from %SMSRN
%SMSRB
%SMSRF Long:On ]
A4: Say [ Text:Text from %SMSRN

The Message is %SMSRB Engine:Voice:com.svox.pico:

eng-USA Stream:3 Pitch:5 Speed:5 Continue Task Immediately:Off ]

[CazMaz]

After digging a bit I found that these entries and some other things have to be in the manifest, or Android ignores the request for voice.

Using voice is an Accessibility Service type thing. So, first we need to ask permission, then setup the Broadcast Receiver intent.

I entered the permission in the portion of adding extra permissions, but it needs to follow the <service... format in the manifest file.

I know that on my phone, I have set Tasker up as a user of the Accessibility Service so the scripts work in Tasker. Somehow I need to do the same in my initialization script, just not sure how that will work out.


From the Android Developer site:
An accessibility is declared as any other service in an AndroidManifest.xml but it must also specify that it handles the "android.accessibilityservice.AccessibilityService" Intent. Failure to declare this intent will cause the system to ignore the accessibility service. Additionally an accessibility service must request the BIND_ACCESSIBILITY_SERVICE permission to ensure that only the system can bind to it. Failure to declare this intent will cause the system to ignore the accessibility service. Following is an example declaration:

 <service android:name=".MyAccessibilityService"
         android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE">
     <intent-filter>
         <action android:name="android.accessibilityservice.AccessibilityService" />
     </intent-filter>
     . . .
 </service>

Bummer...

Time for another TTS break!

CazMaz

[Pent]

Using voice is an Accessibility Service type thing.

Don't know what you mean by that, I wasn't aware of any link.

Wasn't clear to me whether you'd tested with a specific voice succesfully or not.

Pent

[Mark Zraik]

Hi Pent,

Yes I tried Pico in the settings set for USA com.svox..., Didn't work.

Moving on to another task that I will make into an app using Tasker and AppFactory.

I posted the requirements from the Android Developer site that stated in order to use TTS, there must be a <service> declaration with the permission request as well as the intent filter placed in the Android manifest. These are areas that are currently not accessible to edit before you make the app:(

Using 1.6u2m BTW :)

Thanks for your hard work Pent!

--
You received this message because you are subscribed to a topic in the Google Groups "Tasker" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tasker/2ae51c_9AcM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tasker+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/tasker.
For more options, visit https://groups.google.com/groups/opt_out.

--

Respectfully,
Mark Zraik
-----
Automate your Android and make it smarter!
ATT i927 Samsung SII
Rooted, Sim Unlocked
Android 2.3.5
Secure Settings, BusyBox, Super User
Tasker 1.6u2m

[Pent]

I posted the requirements from the Android Developer site that stated in order to use TTS, there must be a <service> declaration

Could you post a link please ?

Using 1.6u2m BTW :)

Ah. It's possible there are bugs with TTS that have been fixed for 4.0+ but not back-ported.

Last time I looked, about 8% of users (and falling) had 1.6+ so it's just not worth the effort anymore unless a fix
is simple.

Pent

[Mark Zraik]

Hi Pent,

Here's the link
http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

*********************

Declaration

An accessibility is declared as any other service in an AndroidManifest.xml but it must also specify that it handles the "android.accessibilityservice.AccessibilityService" Intent. Failure to declare this intent will cause the system to ignore the accessibility service. Additionally an accessibility service must request the BIND_ACCESSIBILITY_SERVICE permission to ensure that only the system can bind to it. Failure to declare this intent will cause the system to ignore the accessibility service. Following is an example declaration:

 <service android:name=".MyAccessibilityService"

         android:permission="android.permission.BIND_ACCESSIBILITY_SERVICE">
     <intent-filter>

         <action android:name="android.accessibilityservice.AccessibilityService" />

     </intent-filter>
     . . .
 

</service>
*******************

I'm moving on to another project, but will swing back around to this on eventually.

I get it as far as the updating goes!

Don't worry about it too much, you've got your hands full with 4.0+

CazMaz

--

You received this message because you are subscribed to a topic in the Google Groups "Tasker" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tasker/2ae51c_9AcM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tasker+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/tasker.
For more options, visit https://groups.google.com/groups/opt_out.

[Pent]

Here's the link
http://developer.android.com/reference/android/accessibilityservice/AccessibilityService.html

OK, but that has nothing to do with TTS that I can see.

Pent

[Mark Zraik]

Hi Pent,

No worries, I'll come back to this later, so, don't waste any more time on it.

I'll find the part that I read which led me to believe it does.

Thank you for the assistance,

CazMaz

--

You received this message because you are subscribed to a topic in the Google Groups "Tasker" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/tasker/2ae51c_9AcM/unsubscribe.
To unsubscribe from this group and all its topics, send an email to tasker+un...@googlegroups.com.
Visit this group at http://groups.google.com/group/tasker.
For more options, visit https://groups.google.com/groups/opt_out.

[CazMaz]

Hello everyone,

Update to this thread.!!!

I had some time to create some different tests and figured out the mystery!

I wrote the original task in Tasker and it worked perfectly, so when I exported this to an apk, it was really confusing as to why it wouldn't work with SAY/voice.
I created another simple 1 step task using SAY, exported it as an apk, and it worked!
Then I remembered....the %HOOK variable never get set in the beginning!

I ran into a similar problem with another project and the resolve was to create an initialization task that set variables in the apk.
If I didn't do this, the main var %HOOK was never set, so it would never match on or off, unless I had a phone event happen and the profile that listened for the phone events set it.
In the beginning of this trouble shoot, I went up to the Android developer site and looked into what it takes to use tts if you were using the Android SDK, and that's where it referred the manifest permission entry stuff, setting up receivers with intents and what not. Which would be the hoops I would have to jump through with the SDK.

However, Pent and those involved with the AppFactory, did it right so you don't have to worry about all that, you can use SAY without any problems.
%HOOK is a variable I use to determine if the voice should read the text message in full, or just announce that a message has arrived. Without it, the app would read a message while you were on the phone, which was something I didn't want, but after the call ended, I wanted the reading back again, hence %HOOK.

Conclusion:
As it was stated (and I forgot), the variables in the apk start out as null so they must be set at least once in the beginning if they are critical or need a default value.  If the task sets variables as the script runs, then there isn't a big problem if they start out as null, but if the entire script (As in my situation) depends on the variable having a specific set value at the beginning, and it's not set (null), it won't match at all (Watch out for grey matter, because I think I dropped me brain!). Null didn't match on or off so it never ran the scripting. It did exactly what I told it to do, nothing!

Sorry for the goose chase, but I hope others can learn from this, too.

CazMaz