Voice assistance #10
Description
The app won't have a generalist speech recognition engine unless the wake word service is so complex that STT becomes trivial. Instead, the app will do it's best to request a voice keyboard.
The non-keyboard "voice input" dialog is possible, but it would obstruct the assistant's fields and widgets. I don't know if it's possible to request the system's preferred STT engine as a backend without net connections, mic permission, and preventing unwanted interruption.
To the greatest extent feasible, the assistant will prioritize "compliant" apps—those that don't interrupt until you specifically indicate you're done talking via gesture or keyword. It's acceptable for this behavior to be optional, but auto-commit should hopefully be off by default.
There should also be an option to block apps that aren't open source and trustworthy. There are good reasons to not trust proprietary voice recognizers, especially those with net connections. Emilla should not take part in activating them unless the user turns off the protection feature and is warned when doing so. That'd also be a good spot to shout out good FOSS recognizers.
It won't be the app's business whether the voice keyboard activates immediately, that's between the user and their voice input app's configuration.
The spoken command must not be auto-submitted. Many commands are dangerous, but that's of no matter because it's just generally disrespectful to decide the user is done with input on their behalf.
The only exception would be a configurable off-by-default control keywords such as "next" and "over." Such keywords would need to be vocally differentiable from just having the word in the command instruction, by confirmation prompt or otherwise.
Down the road, this framework can be used to make the assistant fully voice-operable in a similar way to the "voice access" accessibility service.