I've a strange behavior with an android app when it runs on a S3 with android 4.3: every time app goes to background (pressing back button), when it's resumed, it calls the onCreate() method of Application class.
Reading the Android documentation, Application onCreate() should be called the first time app runs, when app is destroyed or if the device has low memory, but seems it's not my case (I added a log into onLowMemory())
So my question is: in which conditions Application onCreate() method is called? Does it depends on device and/or android versions?
I made an Android application which uses TextToSpeech and works fine. The only problem is that when i receive call, TextToSpeech stops.
I use some apps like mine and they continue speaking even during received call. How can I do that? Maybe using something like link async?
Thanks!
What happens is that when you receive a call, your app's activity is onPause.
So you should start a background service from your activity and handle textToSpeech from there(the service).
So that even if the activity is paused, textToSpeech continues doing its work.
Here: http://developer.android.com/reference/android/app/Service.html
And a useful tutorial on services: http://www.vogella.com/articles/AndroidServices/article.html
I'm using TextToSpeech on background service (unbind service)
I have an IntentService which is used to save [potentially large] files. I initially had a problem where the service would die mid-save if the app was killed. Starting the Service in foreground during a save solved this problem for the most part.
Here is the problem: If the app has been killed while a file is being saved, when I call stopForeground (when the save is complete), the service crashes, indicated in Logcat:
06-23 16:47:25.266: W/ActivityManager(523): Scheduling restart of crashed service...
I have verified that nothing after the call to stopForeground is executed.
It's very possible for me to move my code around a bit, so that this doesn't really cause any problems, but I don't like allowing the service to crash just because there are no consequences...
Because there is no problem at all when the app is still running, my only guess is that it has something to do with the context used to start the service no longer existing. I have tried using both the activity and application contexts, and have also tried running the service in a separate process from the rest of the app. All attempts had the same result.
Am I overlooking something? Thanks!
I've chosen to save the persistent application state in the OnPause() method to my database because OnPause() is guaranteed to be called before the application gets killed according to the documentation of the activity life cycle.
Now I am facing following behaviour using eclipse and avd emulator (api level 8):
1. I start my application via eclipse - Instance1
2. I start my application via eclipse again - Instance2
Now Instance1 is being terminated without calling OnPause()!
Could somebody please explain me why OnPause() is not being called? I thought it is guaranteed to be called always. If this is not the case, maybe because of the way eclipse terminates Instance1 process, then I would like to know if I could change this. Thanks a lot.
When you start the application via eclipse, it will effectively rip the rug out from any instance of the same app already running on the device or an emulator. This will never happen in practice, only when running from eclipse.
So you can plan on onPause() always being called.
what you mean you start application via eclipse - instance 1 and 2?
when click on run button, emulator (in your case or a real device) runs your application. please don't run it in other AVD (if i get correctly based on your instance 1 and 2). If you have put log code in your onCreate() and onPause() methods, For example Log.i(TAG, "I'm in onCreate()!");, you should see it in logcat. therefore, when you launch your app you will see onCreate message and when you click on home button for example, you will see onPause() message.
This is the way which is guaranteed to be called.
IIUC, there should only be one instance of a given Android service, it is a singleton.
However, my service gets instantiated multiple times, although I
do nothing for it.
When the service crashes (for example when I uninstall the app through adb), it
gets scheduled for restart ("Scheduling restart of crashed service.. "). I
understand this is an effect of the service being sticky.
After that, when my app starts, it calls startService() and bindService(), and
the service gets appropriately started and bound. But the service is then
reinstantiated and onCreate() is called repeatedly, as many times it was
scheduled for restart.
Each instance then wait for clients to bind and register, but onBind() is only
called in the "main" service instance. The additional instances wait a bit for
client to bind, and since that doesn't happen, they call stopSelf().
But stopSelf() has absolutely no effect in these "dead" instances, onDestroy()
is never called.
The "main" service instance does work as expected, and when it decides to call
stopSelf(), onDestroy() is indeed called.
Worse, all these dead instances accumulate, they never gets destroyed.
Therefore, their only possible end is a crash (which happen every time I
launch/install through adb), and thus scheduled restart.
So that in the end I get many of these dead instances, which are restarted
progressively once by minute approximately.
Does anyone know what's going on?
I got similar behavior if I use eclipse to restart an app with a remote service. According to logcat, system consider the killed service had a crash and tried to restart the service. At the same time, the service has been restarted with the restarted app. For some unknown reason, Android system does not realize there is already a running service, and tries to start a new one.
It happens several times on Optimus one, Galaxy tab, and EVO 3D. It is fine with Nexus one.
Because I haven't seen your code, this is just a guess: Maybe you have a memory leak that prevents the service from destroying properly. That's the only reason I could think of to get multiple instances of service. For example, if you service is holding on to some object that also have a reference to your service. It happens a lot with inner classes.
Check out this video from Google I/O to see if this problem applies to your services and how to find it: http://www.youtube.com/watch?v=_CruQY55HOk&feature=player_embedded
if you use the section to be excecuted in onstart() . if ur starting the service by onclick button or like clicking on icon multiple time means ,what it will do is if service is already running means ,it will go to onstart(),so the method is excecuting again and again its not that service is starting multiple times .... ur method is running for multiple time ,This i told accornding to my guess may be exact code will be Explaind properlly
if your app exit on crash or kill the process it belongs to like System.exit(), it will start after your app exit or start if your service is running in the same process with Application.
Because you kill the process, and Android detect your service should not stop, so Android restart it for you after your app exit. And why service start again after app restart, I think it is Android's bug, it reallocate a new process to your app instead of using the process allocate to your service.
So, how to solve this problem?
just set the attribute android:process=":background"(whatever you want here, starts with :) to your service node in AndroidManifest.xml. hope it helps you.