This question was asked several years ago, but hopefully things have changed...
Could someone point me to any details about which versions of Android support what subset of SSML in its Text-To-Speech engine?
I did some experiments using Flutter-TTS, which is just a layer that passes the text to be spoken to the underlying platform TTS service.
Some unknown subset of SSML does work on a newer Android - for example, this SSML
<speak>before<break time="5s"/>after</speak>
does indeed produce a five-second pause between the words on API 27 and API 29. It does not work on API 21, but at least it handles it gracefully by just ignoring all tags. I have not tested other API levels yet. I also tried prosody, phoneme, and lang tags - they seem to be not working.
As long as the speak() method of the TextToSpeech class only accepts Strings or CharSequence, (which are then passed on to the speech engine), and as long as Android doesn't introduce a new method like TextToSpeech.speakSSML() in some future version of Android (and enforce that all engines must support it)...
...then the way in which individual speech engines process these Strings will be unique to them and ultimately unpredictable because you don't know what engine (or version of it) the user may have installed and/or selected for use in their settings until runtime.
Sure, a certain engine may soon claim to fully support SSML, and it sounds like maybe the Google engine (if that's what you're testing with) is beginning to experiment with it. Even if they do fully end up supporting it, you would have to prompt the user to reconfigure/install that engine particular version of that particular engine in your app.
I suspect the reason you're seeing it supported is because you're testing with some google engine "network voices" which have some cross-over with google cloud tts.
I don't think Android API level should have anything to do with it, it's just going to be whether a user has "xyz engine ver 234123.21314" installed or not.
Google cloud text-to-speech does support it, though... and since you're already going cross platform using Flutter, that might be a better way to go... but of course, it requires active network.
Related
I'm working on a contact directory integration. I know that I had this feature on an older phone and want to integrate this feature for my own app. Technical is my question similar to Provide the caller id for incoming call from my own app just that I want to support modern devices with Android 11+. On my Android 12 device my content provider is initialized and can be queried from my own code. However the phone app does not invoke my content provider.
Since I am absolutely sure that this feature has worked in the past. I used the emulator with the result that the app works fine with the API versions 27 and 29, but not with 30. Do you know an API change or was that feature silently dropped for privacy?
I talked with the Google Support and they told me that this feature would only work with work profiles in the context of the cooperate contacts from Google Work Accounts. Is that a general restriction or just something related with Google Accounts?
I made some deeper research and found the class ContactDirectoryManager. I modified the code so far that I was able to execute the onPackageChanged() method which detected my content provider correctly as expected. What am I doing wrong?
If you want some sample code check this repo: simplecallerid
Bonus question: Does that only work on Stock Android? I found a feature request for Samsung devices on their frensh community page. It seems that this is not supported there.
A bit late but I too was using "android.content.ContactDirectory". I can confirm that the AOSP dialer does not seem to invoke "phone_lookup" which was the only part my app was supporting.
I can query ContactsContract.Directory.ENTERPRISE_CONTENT_URI and see my app being registered and even make requests to it. But AOSP dialer no longer queries it.
Perhaps performance was reason for it to stop querying other directories.
I suppose we can dig in to AOSP commit history to find the change but who has the time?
I am handing off an Android app to a non-technical client for long-term maintenance. Could anyone offer insight into how often the app might break due to OS updates such that they would have to bring in an external developer?
I'm guessing this would depend on the type of app, so let me offer a bit more info below:
Our app displays live bus information using the google maps SDK
We have few external dependencies - just joda-time, hockeyapp, and AppIntro
Thank you!
If you would solely depend on platform / SDK functionality, your app will not break unless Android / Google actually starts and removes deprecated functionality in newer SDK versions - which it has actually not done in the past a single time (well, except once, when they moved the old Apache HTTP library into an external dependency, but this really happened only one time so far). So, your app will continue to work, but will slightly degrade wrt integration and UI design over the upcoming SDK versions. See for example how "alien" Gingerbread or older apps look on modern Lollipop or Marshmallow devices - but also see how they continue to work.
If you depend on Google Maps, you depend on Google Play Services, and that is an entirely different area. Since Play Services are updated separately and constantly by Google, their API evolves differently and more often introduces breaking changes. These breaking changes are, however, long communicated before, like e.g. the abandonment of the old Maps v1 API that was IIRC around for more than two years after it was announced as deprecated.
HockeyApp is another candidate where you depend on external server functionality. If Microsoft decides to do whatever with this service (change APIs, abandon it altogether), you of course need to touch your implementation. But again, this should be communicated a long way before it will actually happen.
I am trying to play an audio file into a call in android phones like telemarketing calls, is it possible in android's current version. This question was asked
Need to play audio into a call
two years back, and the answer is NO. Can anyone confirm current version of android having this feature or not?
Android still (as of Jellybean MR1) doesn't provide an API for it. I doubt that it will do so in the future either, but you never know.
Some hardware platforms used in current Android phones do have support for this functionality, but as an app developer there's no way for you to take advantage of this.
TL;DR: The answer is still "No, it's not possible".
did not want to revive an old thread.
OMA DRM v1 & v2 support on Android
we are trying to implement a DRM solution for video content for both streaming and offline. And have searched both high and low, these where are the few which repeats itself every time.
http://www.irdeto.com/documents/HL_CW_OMA_DRM_Android_EN_H.pdf
http://www.discretix.com/Android_Security.html
http://www.haihaisoft.com/customize_android_media_player.aspx
http://www.authentec.com/a/Production/Home.aspx
we are targeting phones & tabs
so android 3.0 can be helpful, went through the sdk docs, still couldn't make out how to use them.
also read somewhere android 2.4 (for phones) will support the DRM framework, in the meantime the market we are targeting may not upgrade to android 2.4 so soon. this requires us to find some custom implementation.
have been hitting the wall on all sides. please give your invaluable insights.
if i have missed something very obvious, correct me as well.
Security through obscurity. It's the only way that DRM can work on a device owned by someone else. Obsfucate your code and require updates to the latest version, which changes every week.
It's like putting a lock on a box, then putting the key in the lock, and hoping that no one finds the lock and key. The solution is to change the location of the lock and key every few days, so that the vast majority of users can't be bothered to find it themselves or even to get the latest "crack".
Old thread -- but you may want to look at Adobe Access as well (http://www.adobe.com/support/documentation/en/adobeaccess/). Supports Android with both streaming and offline possible.
What I've read seems to indicate that the only way to do it is to use unofficial APIs that are being locked down in Cupcake (1.5). Is this true?
It looks like the answer is "not until cupcake".
From Android Developers Blog: Future-Proofing Your Apps:
Technique to Avoid, #1: Using Internal APIs
Even though we've always strongly
advised against doing so, some
developers have chosen to use
unsupported or internal APIs. For
instance, many developers are using
the internal brightness control and
bluetooth toggle APIs that were
present in 1.0 and 1.1. A bug -- which
is now fixed in Android 1.5 -- allowed
apps to use those APIs without
requesting permission. As a result,
apps that use those APIs will break on
1.5. There are other changes to unsupported APIs in 1.5 besides these,
so if you've used internal APIs in
your apps, you need to update your
apps to stop doing so. Even if they
don't break on Android 1.5, there's a
good chance they will on some later
version. (There's some good news,
though: because "flashlight" apps are
so popular, we've added the
"screenBrightness" field on the
WindowManager.LayoutParams class just
for that use case.)