I implemented a background service Speech recognition in my application. It stops working after a few seconds (In Pixcel and Nexus devices) due to Oreo OS does not support the background services. This service is the main feature of the application. It should continue running in Android OS 8 too. Please provide me a solution for it.
This link will explain about the back ground services restriction in Oreo 8 android os: https://developer.android.com/about/versions/oreo/background.html#migration
You can check on this article : Keep those background Services working when targeting Android Oreo
"The JobIntentService works in the same way as a Service however it
enqueues the work into the JobScheduler on compatible Android targets.
This means you can easily convert your Services and IntentServices
into a JobIntentService and keep the same functionality."
And it will handle older Android versions compatibility automatically : Here
"When running on Android O or later, the work will be dispatched as a
job via JobScheduler.enqueue. When running on older versions of the
platform, it will use Context.startService."
Related
I have implemented Android Speech Recognition as a service on Android 4.1 & 4.2 recognition solution in my application.
Everything is fine until Android 4.2 OS version, but above the recognition doesn't work. I tested my solution on Kitkat and Lollipop.
The service starts run 2-3 times(i can see the log in the handler), then stops without any error. Here they mentioned about a similar problem, but no solution.
I refreshed Google Play Services to 7.5, but not that is the source of the problem.
Any suggestion is appreciated!
Update:
The suggested solution, to observe if the service runs, just a partial solution, i can restart listen the recognizer with startListening method, but it's not listening at all. I'm considering to use other recognition service, like sphinx. It is so embarrasing, when OS version changes and your app will be wrecked...
I'm aware about the fact, this API is not intended to be used for continuous recognition - as mentioned in documentation.
For a report on Android fragmentation, I am researching about forward compatibility of the Android framework/SDK.
It is widely stated, that the Android SDK is forward compatible, meaning, that applications developed with one framework will run on devices, that are running a later one, i.e. on Forward or Backward Compatibility in Android?. When a feature or API is deprecated it is mostly stated on developer.android.com, that the feature will continue to work on devices, i.e. Google Maps Android v1.
Now, I experienced myself a case of incompatibility with Text-to-speech, when running a 2.2 application on to 4.1. This case is portrait here Text to Speech not working in Android 4.2 Jelly Bean. (Shortly, you are not supposed to check for the availability of TTS before using it anymore, because the existence of TTS on a device is mandatory from 4.1 onwards. And in fact, this check will falsely return false on 4.1, so your code that was written for on 2.x is not working properly on 4.1 onwards.)
Are there any other examples when an App or one of its functionalities stop working on a later version (apart from Apps developed for 1.x)? What are the specific deprecated features/APIs that make troubles on newer devices?
I want to launch the stopwatch application that comes with android from my app but have no idea how to do this.
I do not want to create a stopwatch on my own since it needs to keep running when I close my app.
Up until Android 4.1 (or maybe 4.2) AOSP Android did not have a stop watch in it, and there is no official SDK support for launching that part of the app. Stopwatches are likely installed by the user or the OEM on the majority of devices.
I want to receive time tick in a widget, and tried the code in this link, and it works great on my kindle fire which runs a custom ROM of Android API level 15, but sometimes the time is wrong on my phone which runs Android 4.2 API level 17.
my confusion is the same as a comment below the article
This is completely unreliable. Android will terminate your process whenever it wants after the onUpdate() method returns, causing the BroadcastReceiver and Application to both vanish.
can anyone explain or testify the code?
I want to receive time tick in a widget
That is not possible in a reliable fashion.
and tried the code in this link
That code is completely unreliable, as I noted in a comment on the blog post.
it works great on my kindle fire which runs a custom ROM of Android API level 15
You have not run your app for long enough. It will fail on your Kindle Fire as well.
but sometimes the time is wrong on my phone which runs Android 4.2 API level 17
It is possible that Android 4.2 is more aggressive about terminating processes with no active components, which is why it is failing faster for you on your phone. However, it is guaranteed to fail, for the reason I outlined in my comment on the blog post and that you quoted in your question.
Android apps run as OS processes, as programs do in most modern operating systems. Android will terminate processes as needed to reclaim RAM to use for other processes. Android will eventually terminate the process for your app, at which time your registered receiver evaporates.
In the meantime, if onUpdate() gets called multiple times, you will register multiple receivers for the broadcast, each additional receiver adding that much more overhead.
We added voice prompts to our app using the Text to Speech API a couple years ago and it has been working well. Recently, we started receiving email from users that upgraded to Android 4.2 Jelly Bean saying that voice prompts are not working and that they are getting a message that the voice data is missing and they need to download it. When they click to download they are given the option of downloading languages other than English.
We implemented text to speech following this post on the Android Developer's Blog. We are invoking the TextToSpeech.Engine.ACTION_CHECK_TTS_DATA intent and if anything other than TextToSpeech.Engine.CHECK_VOICE_DATA_PASS is returned we invoke the TextToSpeech.Engine.ACTION_INSTALL_TTS_DATA intent.
We don't have access to a device running 4.2. I went into a local store today and downloaded the app on a Nexus 7 tablet with 4.2 installed and was able to reproduce the problem. However, when we create an AVD based on the Nexus 7 and run the emulator the voice prompts work fine and we are not able to reproduce the issue.
TTS checking with Android OS4.1 and OS 4.2 is, being polite, different.
OS 4.1 does not correctly handle the intent to install data*
TextToSpeech.Engine.ACTION_INSTALL_TTS_DATA
OS 4.2 does not correctly handle the intent to check for voice data*
TextToSpeech.Engine.ACTION_CHECK_TTS_DATA
* By this I mean that it doesn't return the correct status codes as per the old versions. For example, CHECK_TTS_DATA returns CHECK_VOICE_DATA_MISSING_DATA when it clearly does have voice data installed. It's possible that there is some other intent data that now needs to be passed, but I'm not sure where this is documented.
In my apps I have had to disable these checks for newer OS versions. I suspect Google may have done this because their terms to use Android now mandate TTS (but I can't verify this - I'm sure there's a site out there that describes exactly what must be implemented to be called 'Android')
Update
As I suspected, Android OS 4.1 now mandates Text-to-Speech be included in every Android device, thus the checks are now somewhat redundant. From this link: Android 4.1 Compatibility Definition
3.11 Text-to-Speech
Android 4.1 includes APIs that allow applications to make use of text-to-speech (TTS) services, and allows service providers to provide implementations of TTS services [Resources, 32]. Device implementations MUST meet these requirements related to the Android TTS framework:
Device implementations MUST support the Android TTS framework APIs and SHOULD include a TTS engine supporting the languages available on the device. Note that the upstream Android open source software includes a full-featured TTS engine implementation.
Device implementations MUST support installation of third-party TTS engines.
Device implementations MUST provide a user-accessible interface that allows users to select a TTS engine for use at the system level.