"If the service has been started, then its hosting process is considered to be less important than any processes that are currently visible to the user on-screen, but more important than any process not visible. Because only a few processes are generally visible to the user, this means that the service should not be killed except in extreme low memory conditions." http://developer.android.com/intl/fr/reference/android/app/Service.html
"Note this means that most of the time your service is running, it may be killed by the system if it is under heavy memory pressure. If this happens, the system will later try to restart the service." http://developer.android.com/intl/fr/reference/android/app/Service.html On Nov 2, 4:43 am, Indicator Veritatis <[email protected]> wrote: > Thank you for a useful post. But it raises a question, one which I am > sure the OP will also find relevant: how do you know that an Service's > process will not be destroyed by Android (when it runs low on memory) > also? The description of the Service lifecycle > inhttp://developer.android.com/intl/fr/guide/topics/fundamentals.html#p... > does not say under what conditions onDestroy() is called; the > Reference is scarcely more informative, saying only, "Called by the > system to notify a Service that it is no longer used and is being > removed." There is nothing about restarting it. > > On the contrary: the words "Upon return, there will be no more calls > in to this Service object" imply that no such restart will ever occur. > > Please note that this does not explain how the system decides that the > Service is no longer used. But without that information, putting the > task in a Service instead of an Activity accomplishes nothing in terms > of protecting it from Android deciding to kill it. > > On Nov 1, 3:26 am, Lance Nanek <[email protected]> wrote: > > > In Android a service can be used to perform work in the background > > while the user is using other > > apps:http://developer.android.com/intl/fr/reference/android/app/Service.html > > > If the work should be done at a certain time, then there is the > > AlarmManager:http://developer.android.com/intl/fr/reference/android/app/AlarmManag... > > > Using the Timer and TimerTask classes in your app would not allow you > > to reliably perform work while other apps are being used. This is > > because Android may decide to kill the process for an app that is in > > the background. This would interfere with the thread used by the Timer > > class. A new process would only get created when the app was again > > requested by the user. > > > The process for a service may be killed as well, but the system will > > try to restart that on its own. Background apps are killed before > > services when resources are needed, so it is less likely as well. > > > That said, just reporting to the user the elapsed time between uses of > > an app requires no background work at all. Just store when the app was > > last used and compare with that when it is used again. > > > On Nov 1, 3:39 am, Indicator Veritatis <[email protected]> wrote:> Richard- > > > > Your answer is true, and even helpful. But I fear it will sound too > > > much like the "fan-boy-turned developer demanding he read 12 gazillion > > > pages". > > > > Yes, he should read the fundamentals, he should also do some of the > > > elementary tutorials, especially the classic "Hello World" in its > > > "Hello Android" incarnation. But we could answer his questions a > > > little more directly, too. > > > > In particular, in the case of his specific example of the app using > > > the timer, the answer is yes. Any Activity can relinquish control of > > > the screen to be woken up by a timer event. The specifics of how this > > > will be done, however, can only be explained once he has read the > > > 'Fundamentals' and knows what an 'Activity' is, what an 'Intent' is, > > > and how to filter on intents or listen for Broadcasts. > > > > Unfortunately, the Fundamentals section says precious little about how > > > to use the Timer. For that, he will have to go to the API reference > > > and look at the Timer and TimerTask classes. > > > > We cannot tell him how to use which of these, he will have to make > > > that decision for himself based on the specifics of his planned > > > application. But we can at least point him in the right direction. > > > > I hope this post will accomplish that. > > > > On Oct 30, 1:33 am, RichardC <[email protected]> wrote: > > > > > Yes, and here is one page to get you > > > > started:http://developer.android.com/intl/fr/guide/topics/fundamentals.html > > > > > -- > > > > RichardC > > > > > On Oct 29, 2:24 pm, tob <[email protected]> wrote: > > > > > > Hi, > > > > > > I started down the road towards an iPhone app but was dismayed by so > > > > > many things (e.g. you do not have access to some very fundamental > > > > > aspects of the device such as enabling/disabling Bluetooth, EDGE, WiFi > > > > > subsystems; you cannot run your app 'in the background', and, finally, > > > > > the arrogance of so many of the developers there.) > > > > > > Because my knowledge of Android (and even Java) is currently minimal, > > > > > I understand that I may be trashing and smashing terminology such as > > > > > PROCESS, THREAD, APPLICATION, TASK, SERVICE, ACTIVITY, etc etc etc > > > > > > I would (simply) like to understand if I may develop an Android > > > > > "app" (see Trashing and Smashing note above ;<>) that can have > > > > > aspects operating "in the background" while the device is being used > > > > > in a completely different manner as demanded by the user --- here's > > > > > one example --> > > > > > > The USER runs my brandy new "App" which monitors the TIMER > > > > > subsystem... but then (because staring at my App's GUI CLOCK is really > > > > > boring) the user then decides to use the "phone" or play a game, > > > > > etc ... > > > > > > Can my App continue monitoring the TIMER subsystem while these other > > > > > user-initiated activities take "control" ? > > > > > > In this example, when the user 'returns' to my App, it could tell him > > > > > elapsed time since he "originally started" my App. > > > > > > I ask this question so bluntly because the iPhone Fan-Boy-turned- > > > > > developers berated me for not having read all 12 gazzillion pages of > > > > > documentation first. > > > > > > Thanks for any info you can provide... > > > > > > tob -- You received this message because you are subscribed to the Google Groups "Android Beginners" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/android-beginners?hl=en
