Gautam wrote:
Though it is recommended to run the service as required and stop
after it is done, I'm planning to keep my service active always,
Don't do that.
because
1) I want to listen to some system CP change and update my own DB. So,
need to register Content Observer and act
That helped me,... Thanks a ton
On Dec 15 2008, 9:36 pm, Sergi Velez sergi.ve...@gmail.com wrote:
Maybe AlarmManager will work for
you:http://code.google.com/android/reference/android/app/AlarmManager.html
---
sergi.ve...@gmail.com
[In theory, theory and practice are the same. In practice,
I am currently researching the way to do this right and find the
response below a bit interesting. It would seem that any and all long
lived background services are being heavily discouraged.
What I want to do is periodically check url that returns data. If the
change in data between one
Maybe AlarmManager will work for you:
http://code.google.com/android/reference/android/app/AlarmManager.html
---
sergi.ve...@gmail.com
[In theory, theory and practice are the same. In practice, they are not.]
On Mon, Dec 15, 2008 at 16:17, joshv jvanderb...@gmail.com wrote:
I am currently
Cannot thank you enough for this - exactly what we needed to know.
Using the shell command we found out that our service hosting the
playing mediaplayer was marked with an oom_adj of 2 - and would be
killed after opening several other apps or extended phone idle.
After changing the service to a
Any tips on this? Or are we on our own? This is a big issue for us
right now.
On Dec 9, 10:40 pm, John Spurlock john.spurl...@gmail.com wrote:
Would you mind clarifying this a bit? What are some techniques a
legitimate background service hosting a running mediaplayer can
employ to ensure
Do adb shell dumpsys activity to see the current state of the processes
and your own. Look at the oom_adj for the processes to see which ones are
more important (larger is less important = 8 is a background process that
is okay to kill, 2 is a service process that we try hard not to kill).
Would you mind clarifying this a bit? What are some techniques a
legitimate background service hosting a running mediaplayer can
employ to ensure that it does not get killed by the os?
We are running into this right now - our app (hosting a running
mediaplayer) is hosted in a service, and we
We use startService in our application to keep the xmpp connection
alive when the user exits the main activity so that he can be notified
of incoming messages or other events.
We an option in the settings to deactivate the background service
(e.g. the service and the xmpp connection will be
Locale needs to run in the background all the time. It puts an icon in
the status bar. Please do not eliminate light location aware and time
aware services that show presence in the status bar. That would make
the phone a lot less helpful.
There is room at the end of the boot process to list
Or put together an app that would allow a user to see and kill
existing running services. Maybe it's just me, but this seems like a
no-brainer and would allow users (not just devs) to identify apps that
keep useless services running and slow down the phone's performance.
Of course I say this with
That is what I've been trying to do, below is the service definition
in my AndroidManifest.xml file
service android:name=.MDService android:process=:remote
intent-filter
action android:name=com.episode6.android.carolla.MDService/
action
/intent-filter
I just realized that the in API Demo for Remote Service Binding, the
service is destroyed when the activity is destroyed as well. So it's
no help in this case. Can anyone point to a code sample in which a
service outlives it's binding in an activity? Do I need to use a
BroadcastReceiver or
EUREKA! I've figured it out based on some of the documentation I
missed. For those who also have trouble...
The docs for ContextWrapper.startService(Intent service) includes the
following line...
Using startService() overrides the default service lifetime that is
managed by bindService(Intent,
Please please please be sure to stop the service when it is no longer
needed. For a media player, this generally means only having it in the
running state when it is actively playing music; otherwise it should only be
needed when there are clients bound to it.
If you don't stop your services,
Don't worry, apps that leave services running is a pet peeve of mine
too. Making sure my service stops when it's supposed to is a priority
of mine.
On Nov 23, 7:47 pm, Dianne Hackborn [EMAIL PROTECTED] wrote:
Please please please be sure to stop the service when it is no longer
needed. For a
It's a huge huge waste of resources for you to have the system keep
your app running forever to just have a timer go off every 5 minutes
or more. Please use the alarm manager instead.
On Oct 27, 10:24 pm, Eric B [EMAIL PROTECTED] wrote:
I have created a service that runs a Timer and TimerTask.
Perfect, that's what I was looking for. Thanks for your help.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google
Groups Android Developers group.
To post to this group, send email to android-developers@googlegroups.com
To
18 matches
Mail list logo
