I have a service that executes in 2 phones. They communicate with each other using sockets and execute some script (which may take 1-2 minutes approx.) and exchange files (using HTTP Post) between them.
I want this execution to continue, even when the screen is off, i.e acquire a Wakelock. I saw this link, but I'm not sure where to incorporate this in my code(as the device may sleep in the mid of execution). Any guidance is highly appreciated. Thank you.
I m using same app for 2 phones. In onCreate() it starts a service listening on a port. Clicking a button in phone1, does a HTTP Post of a file to phone2 and the communication keeps going on(as phone 2 also listens on a port initially).
Well, your primary objective seems to be to cause the owner of phone2 to attack you with a scimitar, since the phone2 will run out of battery.
That being said, your HTTP daemon will need to be in a service, where you acquire and release a WakeLock (and presumably a WifiLock, since what you want won't work over most mobile data connections).
WakefulIntentService is not useful here, because it is designed for sensible scenarios, where we need to keep a WakeLock acquired only for a brief period of time, to complete some specific task. In your case, you need to keep your WakeLock acquired indefinitely, as you have no idea when work might need to be done.
I m not sure where to incorporate this in my code.
In the service, presumably. You will probably acquire the WakeLock in onCreate() of the service and release it in onDestroy() of the service. If you wish to avoid a scimitar-related demise, you will make sure that the user has plenty of control over exactly when this service is running, and therefore have plenty of control over when this WakeLock is in force.
Why not implement that functionality with a service? See here. I'm not very experienced in android development but have worked recently in a project where a functionality similar to that was implemented using services.
Related
Question
I am wondering if we need to aquire the WakeLock or if the service.startForeground() command does that anyway for us? I didn't find anything in the documentation.
Goal
We want to remove unnesessary stuff which might slow down the service start as we want to start capturing the sensor data as soon as possible and as the service might be restarted frequently.
Context
We're developing an Android library to capture sensor data with ~ 200 Hz for up to a couple of hours (research environment). Right now we aquire a WakeLock and start the capturing service as ForegroundService to make sure our capturing isn't stopped when the device is not used.
To answer my own question (if no one else finds more details on this):
In my understanding "foreground" just describes that the user would notice if the app was killed e.g. when browsing a large page. For this reason the system is asked to try to avoid killing the service.
Just because a foreground service is running probably not implies
that the CPU can't go into deep sleep mode.
In order to collect sensor data all the time from user-defined start to stop we still need to aquire the WakeLock ourselves.
No, wakelock can be used to make sure your foreground services run when device goes to sleep
If you must use partial wake locks, follow these recommendations:
Make sure some portion of your app remains in the foreground. For example, if you need to run a service, start a foreground service instead. This visually indicates to the user that your app is still running.
https://developer.android.com/topic/performance/vitals/wakelock#best_practices
my knowledge of services in any operating system, is that they usually run in the background and perform whatever work they have to do.
but the first time I got familiarized with android services, I got confused.
it appears they only run when the application is working, and that for me, makes them no more then sophisticated threads.
do I have this all wrong? how do I make a service that runs when the application doesn't? (so that I can check for updates and create notifications for the user that will then lead him to the application if he chooses to open them).
does push notifications have anything to do with it?
Edit:
thank you guys for your answers so far.
my problem seems to be the fact that the service is only started officialy when the device is booted up. I do call startService when the app starts, but that doesn't seem to help. the service still dies when the app is turned off (unless it was booted)
also I never call stopService
If you are trying to implement a long running task that is performed in a (background) service, you have to start one or more threads within your service. So the service just gives you the opportunity to have an application context without having to have a user interface ;) you can consider it as a kind of container.
This page give you a nice overview about different thread approaches in Android. As you can see a service has not its own thread.
Anyway, in your case it seems that an AlarmManager is probably the better option. Running services for polling information all the time can be quite CPU and battery consuming (see this post for instance). So try to avoid having threads that run all the time.
If you can push information about updates from a server it's just fine. Check out Googles Cloud Messaging in this case.
Michael who commented on my question first was right in his comment about startService()
so it goes like this:
my receiver is only activated on boot, and uses an AlarmManager to
time the service to certain intervals.
what I did was to bind the activities to the service. if the service
was off and I binded it and unbinded it, then by the time the app was
terminated, there was nothing keeping it alive.
by simply making sure that the service was started properly with
startService if it is not already on, I managed to keep the service
alive at all times
also thanks to Trinimon who gave a very nice explanation on what
services are, and the importance of not overloading the CPU with
excessive polling. (which is kind of a trade off situation)
good luck to all :)
I have a VOIP app that I would like to always run in the background to make it responsive to incoming calls. Reading through some forums I found running the app in the background would cause a battery drain.
Are there good practices that I should follow so as to run the app in the background?
Reading through some forums I found running the app in the background would cause a battery drain.
It is more that having something run all the time increases your opportunity to drain the battery.
Are there good practices that I should follow so as to run the app in the background?
Being a VOIP app already violates some of the "good practices". For example, you will need to (try to) have a service that runs forever, to maintain your open socket connection to the VOIP server. And, depending upon how your networking is set up, you might need to try maintaining a WifiLock, which will drain the battery.
Generally speaking, then, you just want to make sure that your service is doing as little as possible except when a call is in progress. For example, while you may need to send packets over to the VOIP server periodically to keep your connection alive, try to do that as infrequently as you can.
There are many smart VoIP applications that use Push Notification feature. That will not eat up as much battery, but you must have a consistent internet connection. One such option is Axvoice. Check out their apps at: http://www.axvoice.com/support/mobile-voip-applications.html
They will also run in the background like other apps, but the difference between Axvoice and other apps is you can reduce battery consumption because it will not be communicating with live servers all the time. Please have a look at this: http://www.wikihow.com/Save-Battery-Power-on-an-Android
Use a Broadcast Reciever. It is documented here
http://developer.android.com/reference/android/content/BroadcastReceiver.html
A BroadcastReciever will execute it's code when the specified broadcast is broadcasted through the system. In other words when you receive a call the system sends out a broadcast saying that there is an incoming call. If your receiver is made to pick up on that broadcast than it will react. Think of it like the Android system is broadcasting a lot of different radio stations and a BroadcastReciever is like a radio. You can set it to pick up whatever broadcast you want and execute some code when it does.
My company has, in essence, undertaken a project to replace some of its pagers with stock smartphones running Android. As long as they are signed in, the device should be listening on a particular socket to receive "pages" from a server. My naive implementation was to create a foreground service that 1) kicked off a listening thread, and 2) holds a PARTIAL_WAKE_LOCK.
This works fine unless the device has a long period of inactivity, 1+ hours. Then, it appears that the OS shuts down my app's process, understandably believing it to be not in use.
I completely understand their reasons for doing so, but I'm wondering if I can somehow get around this restriction. Are there ways to signal Android that my process really is important enough to keep alive/the device awake? I learned both Java and the Android API for this project, so there are plenty of areas where my knowledge is incomplete.
Failing that, given the description of my business needs, how would you suggest implementing this functionality? While the user is signed in to our custom app, the device should always be listening.
Thanks to everyone for reading this question.
The OS won't kill your process if you are using Service.startForground(). This is what things like music playback use, and you wouldn't want those to be killed after some amount of time.
That said, for this kind of thing you generally wouldn't need to make your service foreground -- when the system does kill your process because it has been sitting around or needs the memory, it still knows the service wants to remaining running so will restart the service shortly after that. This is how Google's own services work, they have one .apk that has a background service running that keeps a network connection open to a Google service which reports back when interesting things should be done like sync new e-mail, retrieve and deliver a C2DM Intent, etc.
Also you should not hold a wake lock during all of that time. You will kill the battery, especially on some devices like those with Samsung's Hummingbird processor. The right way to do this is to just leave the socket open and let the device fall asleep. If data is delivered to the socket, the CPU will wake up to deliver that data and at that point you should acquire a partial wake lock just for the time you need to read and process the data.
What you describe sounds like a job for Android Cloud to Device Messaging Framework.
It's currently not completely open but there is a signup link on that page. I signed up and was accepted within 20 minutes of my application. Worth a look IMO.
I'm developing an app that checks several conditions during an incoming phone call. The main parts of the app are a BroadcastReceiver listening for Intents related to the phone's status and a local Service checking the conditions.
At the moment the service is started each time an incoming call is detected and is stopped when the phone status changed back to idle.
Now I'm wondering if this procedure is correct and whether it is reasonable to start and stop the service related to the phone's status. Or would it be better to let the service run regardless of the phone's status and bind/unbind to/from it when needed.
Are there any performance issues I would have to think about? Perhaps it is more expensive to start/stop a service than letting it run and communicate with it. Are there any best practices out there regarding the implementation of services?
Or would it be better to let the
service run regardless of the phone's
status and bind/unbind to/from it when
needed.
Please don't. It will just take up RAM for no good reason. It is everlasting services like this that cause users to attack developers with task killers.
Are there any best practices out there
regarding the implementation of
services?
Here are two of my posts on the subject, for what they're worth.