I am with my daughter in the hospital and she is asleep. I would like to leave the room for a few minutes but don't want to upset her if she wakes up (she can't see or move much)
The first thing I though about is leaving the phone in the room and have it play a message if she speaks. I thought about the 'OK Google' type hotwords but I don't think they are customizable.
Any ideas or suggestions?
The Voice Actions API should have what it is you're looking for. There's another post which will lead you in the right direction. Custom Voice Actions from my understanding allow developers to implement their own commands.
However if all you want to do is detect voices and then perform an action, i would go down the route of just detecting a voice. A similar post should have the information you need.
Related
I'm able to integrate Android widgets with Google Assistant. And want to have some voice command experience.
For example the CREATE_CALL intent, if user is trying to call Alice by saying call Alice with some app, and if there are 2 Alice in my app, is it possible for me to response with a widget showing 2 Alice, and asking user by voice, and user can choose which one to actually call, all by voice? Can it be done by SpeechRecognizer API?
Broadly speaking, App Actions do not have a voice conversation experience. There are some tricks you can pull that might head in that direction, but they are largely outside of the App Action Widget experience itself.
Can I respond with a widget showing that there are multiple matches?
Yes, you can send back a Control Widget that might allow them to choose which user they mean.
Can they speak which user?
Probably not in the way you're thinking. To use your example, they can re-invoke the CREATE_CALL BII using any of the phrases, but you can't prompt them with "Who did you mean, exactly?" and for them to just say the name.
Can I use the SpeechRecognizer API?
Not as part of a widget.
Widgets get embedded in the conversation with the Assistant.
In theory (and this is on my list to eventually test and figure out), you should be able to deep link to an Android Intent in cases such as this and open a view. While there, you could use SpeechRecognizer or just open the microphone to send audio somewhere. But this isn't done using the Widget itself.
In this scenario, SpeechRecognizer just does the Speech To Text (STT) or Automatic Speech Recognition (ASR) part of the processing. To actually match this up to phrases to determine an Intent, you would need a Natural Language Understanding (NLU) module such as Dialogflow. (But you may not need the SpeechRecognizer in that particular case, since Dialogflow can also take an audio stream to do the ASR part for you.)
I am trying to determine the appropriate communication method between the mobile device and wearable for an application. I have been using notifications, which are ok, but the output is not always formatted the way I want. Example: when I include an image (a simple check mark) with no text, the image does not sit right in the center of the wearable. It's just below for scrolling purposes. Also I cannot control things such as vibration variations for different notifications. Also for future enhancements, I might need multiple smaller images in a single alert.
I have been looking at syncing data items but don't know if it will work for my first scenario and was hoping I could get some advice from the community.
Example:
There are a list of items on the wearable (this will be configurable). Each will have a image/png associated with them. Some items may have the same image. When the item is pressed the image (plus some text potentially) needs to appear on the watch with a specific vibration, then disappear.
A running history will be kept on the mobile app, but is not necessary for the watch. My concern with using the data sync is that this is that this is not really syncing data between the two devices, unless there is a "current item" which is being synced.
Hoping for some guidance from the community.
The Data API is really for keeping persistent items in sync between phone and watch. I'm not clear enough about your app's architecture to be sure if this is your best choice, though your configurable "list of items" sounds like a classic Data API use case. If you're not syncing these items, how will the list appear on the watch?
The Message API is more for one-off event signaling: something has happened on one device that needs to trigger an action on the other, and then it's done. And some of your description does sound more like this scenario... but again, I'm not clear enough about what your app is really doing.
And it's always possible that the you'll use both APIs for different aspects of your app; perhaps sending the configurable list of items via the Data API, then triggering events using Message.
Hopefully that's enough clarity on the two APIs to move you forward. If not, some additional details on your particular use case(s) would probably be helpful.
Edit after clarification in comments:
Your use case is still not entirely clear, but here's what I'd say:
If you're only showing a notification (or equivalent) on the watch at the point that an item on the phone is clicked, use the Message API to send those events.
If your watch app will show what has been clicked - whether just the most recent, or more extensive history - use the Data API to both "send the event" (by updating the DataItem) and maintain that record.
I want to try to make an Android alarm app that is impossible to stop. In other words, it keeps going for a predetermined amount of time, even if the user presses the power button, tries to reduce the volume, or anything else.
It does not seem feasible to me, but since I have very little Android experience, I'd like to know if something like that is theoretically able to be done. Thanks.
This question has been addressed on SO here: Override Power button just like Home button
.
There are several answers in the link that will give you options and get you 90% of the way there, but no answer will cover all devices/scenarios. The accepted answer in the link puts it best:
The Android system, as far as is documented, defines (a physical button press) as a
broadcast action. Following the publish-subscribe pattern of message
propagation, this message will notify all concerned parties of this
action. Because this message is sent by the system, because the
message stack is managed by the system, and because the message is
also received by the system, your code simply (cannot be) injected in the
right place to block the reception of this message.
I'm looking to add voice commands to an Android App that will be running on a tablet as a kiosk. I don't want the user to have to push a button, because the user is doing something more important (e.g. driving a car, flying a plane, or performing brain surgery) and the command could be completed by a single button push.
I see tutorials describing how to add speech to text and have the user push a button and get the text, but nothing allowing the wake word "Okay, Google" to start the voice recognition (much less a custom wake word).
I looked at using the Google Voice Actions to start with "Okay, Google" and then send something to my app (register an intent), but that has to be trained to one specific user (at least for the tablet I tried it on). I'll have different users every day (maybe more than one a day) and no opportunity for training the device.
I've worked with CMUSphinx and found it to be too unreliable for spotting a wake word.
Is there a way to add "Okay, Google" as a way to start listening to text inside my app?
Got it working using PocketSphinx for offline wake work recognition and then I hand the microphone over to IBM's Watson's Speech to Text software that works over the internet and comes back with pretty reliable results.
Unfortunately what you are trying to achieve is not possible. If I understood correctly what your concept: a 3rd party app will awaken the devices and act based on a set of commands (from a security point of view this is very bad).
The closest you can do is follow the Voice Actions Api - https://developers.google.com/voice-actions/system/
The primary purpose of my app is to change a smart phone into a sort of smart pager (there is an associated web app, but that's not the purpose of the Android app). I use the Notification system built in to Android to handle alerting the user that they have received a page.
My problem is that the clients want:
The notification ringer to ring forever until acknowledged (easily accomplished with FLAG_INSISTENT)
An easy way to silence the ringer with 1 push of a button. It is really not always feasible due to the nature of their work to press the power button, slide to unlock, and drag down the notification bar. I need to replicate the behavior of a pager.
I need to find a way to satisfy the 2nd requirement. It looks like I can hook into keypresses if I've got an activity running, but of course, when a notification is received, the screen will probably be off. I am looking into this currently, but I was wondering if anyone had some guidance in the meantime.
Does anyone have ideas on how I could accomplish this goal? Are there alternative ways to listen for key presses, or some creative combination of flags that could get me there?
Techniques that would normally be frowned on for Market apps are completely on the table, since the phones are owned by my employer and will only be used by other employees. I just want to avoid using private or deprecated APIs to make switching phone models easier for the developer who eventually inherits this project.
Thank you to everyone for reading!
Does anyone have ideas on how I could accomplish this goal?
You'd have to hold a WakeLock, specifically a FULL_WAKE_LOCK, in order to respond to button presses. This means that battery life will be sucktastic, unless you put some time limit on that (e.g., hold the WakeLock for a minute or two, but otherwise assume the user's not near the device, so don't keep it awake).
You would also need to try to interrupt the keyguard with KeyguardManager. I have not done this so I do not know all of the details. Your "watch for the magic button" logic would have to be in the activity that appears on top of the keyguard.
Also, bear in mind that not all Android devices have physical buttons -- in fact, I would not be the least bit surprised if the whole physical button metaphor goes "poof" with Ice Cream Sandwich later this year. Hence, the button in question really should be an on-screen Button for future-proofing.