I am studying how the android.speech package works and I noticed that most of the extras used with the intent RecognizerIntent.ACTION_WEB_SEARCH are ignored by the speech recognizer.
If I set a language using the RecognizerIntent.EXTRA_LANGUAGE extra, the specified language is ignored, but the default language of the device is always used.
If I set a text using the RecognizerIntent.EXTRA_PROMPT, this text is not displayed.
If I start the speech recognition activity using startActivityForResult method, then the speech recognizer calls onActivityResult, but the second argument (the resultCode) is always RESULT_CANCELED and the third argument (the data Intent) is always null. This behavior is probably due to the fact that the purpose of this type of intent is to perform a search on the web. For the same reason, if I set the maximum number of results using RecognizerIntent.EXTRA_MAX_RESULTS, the specified value is ignored.
I found this behavior, but the official documentation says that these options can also be used for the ACTION_WEB_SEARCH intent.
Why does the actual behavior of the voice recognition system differ from what is stated in official documentation?
I think you are using the wrong action. Instead of ACTION_WEB_SEARCH, use ACTION_RECOGNIZE_SPEECH.
If you do, onActivityResult will behave as you expect and your Activity will be in control of interpreting the recognition results.
By the way, when you set ACTION_WEB_SEARCH, you delegate handling of the results to Android. Based on what the user says, Android might start a web browser or it might start an email (if the user says "email"). Because of this it makes sense that your Activity does not receive any useful information, although I think it should still take into account RecognizerIntent.EXTRA_LANGUAGE.
Related
im now writing STT in android studio and i have a question for some code lines.
intent=new Intent(RecognizerIntent.ACTION_RECOGNIZE_SPEECH);
intent.putExtra(RecognizerIntent.EXTRA_CALLING_PACKAGE,getPackageName());
intent.putExtra(RecognizerIntent.EXTRA_LANGUAGE,"en-US");
The first line is set intent fot getting input of user's speech and the last one is for setting language that we going to use. but what about a second line?
Even though i read public documentation, cannot understand.
'The extra key used in an intent to the speech recognizer for voice search'
i understand that like this: after getting input of speech from the first line, use the input in the intent - and what kind of intent? - to the speech recognizer for voice search.
but still not sure..
can you give me an explanation?4
Thank you in advance
it's a flag that is used by voice search API to identify the called to this API (your application) so the voice search implements the callbacks and ... based on your package name...
I want to add support for several navigation applications in my app. I know how to start another activity as intent and pass parameters - but is there any way to check the naming of the parameters I should pass? For example: Navigon should start with routing calculation and instructions immediately after starting from within my application. So far, I'm not even sure Navigon supports parameter passing, but I don't even know how to figure that out.
Thanks in advance!
You should check the documentation for each app you're interested in supporting. They should have it laid out somewhere. If they don't, they might not support explicit intent extras.
For example, Navigon has their options laid out here(found by searching "android navigon intent"):
http://www.navigon.com/portal/common/faq/files/online_documents/NAVIGON_Android_public_Intent.pdf
As illustrated by a number of questions here, it's sometimes difficult to get intent filters configured correctly. If a filter is not working like expected (e.g., app shows "permission denied"), what are some tricks to figure out why?
Update: To clarify, I'm not just talking about built-in intents. It's been a struggle getting a custom OAuth callback URL to resolve to the correct activity, but I can't tell if the issue is due to my intent filter or something else.
Option 1: Catch-all IntentFilter, then debug IntentFilter.match()
I wanted to ask exactly the same question. I know of no readily available tools for debugging failing intent filters but this is the approach I'm thinking of:
Make the intent filter as permissive as possible (i.e. put wildcards everywhere you can) so that you can grab and examine the Intent from within your application
Submit the Intent object thus obtained to your real intent filter's match method. You should be able to tell at which stage matching failed by looking which NO_MATCH_* constant is returned.
Once you captured the Intent you can also run the matching in a debugger so better understand what is wrong.
Option 2: Use the App Links Assistant
(This option only works if you want to debug http/https links)
Make sure the App Links Assistant plugin is enabled (File > Settings > Plugins > check "App Links Assistant" in the list). Restart Studio if prompted
Open the assistant (Tools > App Links Assistant)
Click "Open URL Mapping Editor" button in the side bar
Create/Edit your IntentFilter in the dialog
Type a test url in the "Check URL Mapping" box.
This will not tell you why a filter does not work, but allows much faster trial-and-error testing. That's what allowed me to understand why my filter wouldn't work (turns out we can't put wildcards in the "port". I set scheme to http, host filter to *, left port number empty (tried * as well) and set a pathPattern, but it would only matcĥ port 80 (on arbitrary hosts)
First - check if called component is declared in the parent manifest for the calling component.
If the called component is yours and not in the same app, check if it is declared in its own manifest.
Other possible problem - if the called component is correct by itself (broken layouts, forbidden elements in a widget)
Some intent-filters are protected by the system. And as such would require you to have a permission before you can use it. The trick is to know what you want. Once you know what you want, then you can look up intent filters that are available.
The preferred option would be to learn the traverse the android source code and find what you're looking for in the manifest.
I wan to hide/show my caller id from my activity programmatically. I tried to find it in the android documentation but without the luck. Maybe you have any ideas?
I posted a question asking this on the Android Google group and got absolutely no answers at all. I've also seen a couple of other question on SO which also had no answers (or none that work).
I came to the conclusion that it simply isn't possible. My reasoning is this...
If I go to Settings -> Call -> Additional settings, I see an AlertDialog which has a HeaderTitle of 'Call settings' and I see a circular progress indicator and a message saying 'Reading settings...'.
It occurs to me that my phone is, at that point, accessing my phone/network provider. The resulting 'chooser' dialog gives me options for 'Network default', 'Hide number' and 'Show number' and when I make a selection (or even if I just 'Cancel' the dialog), I get another AlertDialog with circular progress indicator with the message 'Updating settings...'.
In short, it seems the Caller ID setting is not entirely 'local' to the phone settings and relies on interaction with the provider and, for whatever reason, as a result of this the Android APIs don't allow this to be manipulated programatically.
I'm not sure if this is something on the 'To Do' list for future versions of Android or if there are legal/security implications in allowing it to be done or some other reason. Whatever the case may be, I haven't found anybody so far who is able to explain why there isn't a method for TelephonyManager (for example) to simply switch this.
EDIT: No luck on getting the Additional Settings AlertDialog with the standard APIs either.
The reason I say that is that it is possible to pull up various parts of the device's 'Settings', e.g., in one of my apps I use android.provider.Settings.ACTION_WIRELESS_SETTINGS in the constructor of an Intent passed to startActivity(). This brings up the Settings page for enabling/disabling wi-fi, mobile internet and bluetooth.
android.provider.Settings has other similar ACTIONs for other Settings pages but there isn't even one for 'Call' never mind Call -> Additional Settings and nothing for the AlertDialog to allow you to choose to Hide/Show the outgoing Caller ID.
If this can be done then it would have to be an undocumented API unless I completely missed it (I spent a long time looking). I suspect examining the Android source-code may be the only way to find an answer and I haven't attempted that yet.
I have managed to get Additional call settings dialog. Explanation below:
Although it looks like it is part of the Settings, in fact it is part of the Native PhoneApp. If you take a look at the AndroidManifest.xml of the PhoneApp you will see that Activity GsmUmtsAdditionalCallOptions has defined IntentFilter for the android.intent.action.MAIN.
So, the code that I checked to work correctly on several phones:
Intent additionalCallSettingsIntent = new Intent("android.intent.action.MAIN");
ComponentName distantActivity = new ComponentName("com.android.phone", "com.android.phone.GsmUmtsAdditionalCallOptions");
additionalCallSettingsIntent.setComponent(distantActivity);
startActivity(additionalCallSettingsIntent);
If the #31# trick works for your needs for a single call then you could add a broadcast receiver that listens for the outgoing call notification and modifies the number to include #31# at the start before it gets dialled. Android allows the number to be changed on the way through like that.
Only works if your default is to enable caller ID and your network support #31# and you want to toggle it off using a widget, say.
The Caller ID is network specific not something that the phone controls. In fact in certain mobile network configurations the phone doesn't even 'know' its own phone number.
Some networks support sending an activate/deactivate caller ID network command. In GSM this is normally #31#. It can be permanent or on a per call basis.
Permanent requests the network to hide the caller ID for all calls.
Per call requests the network to hide the caller ID only for that call. The latter is achieved by prefixing the number being called by #31#, so for example calling #31#85432786426 would call 85432786426 hiding the caller.
Some networks support both, some only support one of them, and some do not enable it. Try your luck and try prefixing the dialed number with #31# and see if it works.
http://www.gsm-security.net/faq/gsm-caller-id-clip-clir.shtml
If you want a shortcut to the additional call settings, you can use App Cut and select GSM settings. It will place a shortcut on your home screen.
If I want to create custom address book (which overrides my phone's default address book), and if I want it to be used by all applications, what should be my intent-filter? Does Android allow me to do such a thing considering the fact that such a third-party app could potentially be malicious?!
And, if I want to have yet another address book application, I suppose the second app also has same intent-filter, isn't it? How does the framework decide which app to pick if I click on Contacts button when making a call? In other words, how does the framework resolve intents in case,there is a conflict between multiple intent-filters?
You can replace any application on Android platform, even Home. Android documentation explains everything there is to know about Intents and Intent Filters and there is a section called Intent Resolution that answers your question. Intent Resolution section for Intent class has some additional information.
As far as I can tell Android doesn't try to resolve a conflict. It ask the user which application to run and gives them the choice to mark this Activity as the default for this Intent. They give an example about mail app here.
While Mr. Smiljanić is basically correct, there is no Contacts application in Android for you to replace. There is Dialtacts, which is the application supporting the contacts, call log, and dialer. That application cannot be replaced, mostly because the dialer cannot be replaced.
So, while you may be able to override some intent filters and get control on some contacts-related requests, you will be unable to get the contacts portion of Dialtacts overridden, which will confuse users.