Voice Control development updates and plugins support
It’s been a while since last news, but I would like to make everyone aware that Voice Control development isn’t died, but, instead, it is going forward with new features and bug fixes.
The next update is expected to be released in the first half of March, with a great number of bug fixed, some awaited features like the bluetooth volume configuration, the support for Sygic navigator and more.
It will also come in 3 new languages thanks to contributors: Korean, Swedish and Hungarian! I will never end to thanks every beta tester and translator for their great support and help.
Now, as an Android developer, I would like to spend some words on a developer-oriented feature that I hope other developers (and users) may found useful: the Voice Control plugin system.
It will be released in the next update, and its primary objective is to allows other application to provide their own actions, in order to make them easily usable when launching Voice Control. This way, Voice Control can be used as a central “entry point” for application-wide vocal actions (something like the Google Search Bar :) ).
It can also be seen like a voice driven UI framework: developers don’t need to handle recognition engine manually, establish audio routes, listen for incoming calls to “halt” the recognition and so on, but they only need to say “when the user says this phrase, do this, when he says that other phrase with a contact name, do that with the contact name he said”, and so on.
All this because the Plugin API allows plugins to:
- declare a list of actions with phrases to activate them
- add variable parts inside action phrases, so that they will be translated into specific data-types (like contacts phones, dates, texts)
- declare and use additional plugin-specific data-types
- ask the user for a value that needs to be translated to a specific data-type
- ask the user to perform a vocal selection from a generic list of items
The API still miss some nice features, like “scoped” actions, a way to trigger an explicit confirmation request from an action, and other useful features used by actions already embedded inside Voice Control. However, the current API is already powerful enough to perform “one-shot” voice commands and some other complex commands (as it will be shown as soon as I provide a sample project with some examples).
The current API, also, tries to provide a protection against malicious applications that could try to use Voice Control plugin system as a “backdoor” to trigger plugin actions: with the next version, Voice Control will provide and hold two permissions with a “signature” protection level (in order to deny other application to hold them), one for plugin execution and one for plugin data access. Plugins could use this permissions to protect their own receivers and providers, in order to allow only Voice Control to access them.
Now, there is a problem on how permissions provided by applications are handled inside Android: they can’t be trusted, because another application, if installed before Voice Control, can provide the same permission, in order to hold them and get access to plugins receivers and providers.
However, plugins can protect themselves from this sort of permission-hijacking using a simple application signature check: Android allows only one application at time to provide a specific permission, so, plugins can check if the public signature of the application that is providing a Voice Control permissions match with the Voice Control public signature. This way, a plugin can be reasonably confident that who is calling it is Voice Control and not a malicious app.
Developers can find an utility method inside the plugin API in order to accomplish that with a single line of code. Isn’t that great?
The plugin system is already available inside the beta, and its documentation can be already checked, so if someone would like to give it a try, he just need to request a beta access filling the beta access request form.