I m actually developping an application in which I need my phone to be active even if it's locked.
Explanations
The applications connect to a remote nodejs server using socket.io. In that case, it cans sends realtime messages to a socket server that can handle this and make anything it needs. The fact is the socket management is in a service class (extends Service class).
The problem is that, when I lock the phone, the device stop to send heartbeat, and so is disconnected (by timeout) from the nodejs socket io server.
Actually, the normal behaviour of an android phone locked is to sleep. Meaning no activity.
Question
I was wondering how does others applications to be able to receive notifications, and so handling notif by a background service. it means that there's an activity even if the phone is sleeping right ?
How can I do to make this without draining a lot of battery ?
You use wake locks to keep CPU awake while locked: https://developer.android.com/training/scheduling/wakelock.html
You should aquire it for a small amount of time to not drain battery.
I think if you will acquire a phone wake lock it will drain the battery which is not a good thing . On the other hand, The use of service is really very good,and you talk about the notification of other apps and they works in background because notification does this by default
So in you case As I do not know what are you really trying to do with server, But Service is good option. Service works even your mobile is locked. But in your case if it stops make sure it is not bind with the class.
You should make sure that the Service is not binded with the class or activity as when the activity will be destroyed the service would also be. Just trigger your service and let it handle all the things in background.Please read the discussion in this link. It might help you in understanding better.
Related
I would like to make an app that always works in the background (from boot up), which sends GPS coordinates to a server. This app should ALWAYS be active and should never close.
Should I use the services? I would like to use UDP sockets to send coordinates but I accept alternatives. I would also like to avoid using the google API.
Thanks a lot :)
If your app need to run in the background , you need Service and you need to make it a foreground service which means you need to show a notification to the user as long as your application is running.
To open app on device boot, from Android O, its not allowed. You will get an IllegalStateException.
The main reason for this is to prevent exactly what you are trying to achieve.
Its not good to keep running an app in the background and its especially bad to keep tracking users GPS coordinates and send it to the server.
Because it will drain the battery very soon.
However it is possible to keep a foreground service running which can take the GPS coordinates and send it to the server. But for that user has to open your App first.
Please refer to
https://developer.android.com/about/versions/oreo/background#services
Other alternative is to use JobIntentService which will schedule your tasks in smart ways to avoid draining users battery and data.
Regarding UDP sockets , it depends on your backend.
So I've made an Android video-calling app that tries to be available in the background so that the user may receive calls when the screen is off. I've noticed however that the app would be paused when the device went to sleep.
The solution I've found that worked was to rewrite everything to a service and then request a wakelock so the service wouldn't be paused during sleep.
Surely, since there are so many of these types of apps, there is a more elegant way to do this? A periodic check wouldn't work since you would want to take the call in real-time.
It depends on the Android version, for version older than 6 a partial wakelock is enough to keep the device awake, for Android 6 you also need a foreground service, that's a Service that calls startForeground() and shows a notification, but to keep the device awake has a big impact in battery usage.
You do not necessarily need to transfer all the code to the Service due it is the whole application that stays awake.
A more elegant solution to replace all this would probably be to use Push Notifications, it is what most messaging applications use. Firebase has Push Notifications.
I need to keep an open connection in the background, even when the app is not running. It's not possible to use GCM because the connection will be in the same LAN as the server, and the device may not have a working Internet connection.
The connection will be some kind of local Push, so the device will just get some short relevant data from time to time (in addition to the keep-alive messages).
My use case is quite specific so I can consider that the battery is not an issue. I may show a huge red warning saying that enabling the feature will drain the battery, or just disable it if the device is not charging.
On the other hand, is quite important that the process with the connection is not "randomly" killed by Android.
I thought about implementing this with a service, but I would like to hear opinions from someone else. Maybe there is a better way to do it, considering the constraints mentioned before.
"even when the app is not running"
That means that your app is not running, and it doesn't have a process. Without using a third part app (such as the GCM service) that awakes your app, nothing can reach you.
You can, however, have a service that remains active and keeps a connection to a server (say, for instance, an XMPP server) to receive notifications and wake up this or that activity.
You can also do that in a separate application.
You can add robustness with a regular watchdog started by the alarm manager, for example.
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.
I am running a remote service which has a handler which does an operation every 15 minutes (handler.postDelayed()) which involves making an internet request. Sometimes i notice that it does not happen. Does the internet (mobile data connection get switched off when the mobile sleeps or processor sleeps). What happens during this time ?
I guess internet gets turned off when the screen goes to sleep. What could be the efficient way to make sure that in the required time interval(half an hour) it wakes up (turns the internet on) and does the job in the remote service? This service is supposed to run in the background throughout. Can i do this with an AlarmManager (can it trigger some job to happen in a remote service)?
As stated in a related question's answer, you can give a try to WifiLock if you use only Wi-Fi for this service.
Another reason is maybe your service is destroyed by Android when it sees no use. If it is the case you can try the Foreground service option. Note this does not guarantee the service won't be destroyed but the priority compared to other service will be decreased, thus giving more chance to your service to survive.