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.
Related
I am creating an application that should show some Screen on incoming message.
I think I need some background job/service that's running permanently while phone is on. That job will handle for the incoming message and run the Application with some parameters, so based on these parameters the application will show corresponding Screen.
Is it possible to reach the goal this way? Or is there any other ways?
(I am creating the app using react-native, so if there's react-native solution, it would be even better, but native Java-Android solutions are welcome too)
This approach is very bad to battery life because it doesn't allow CPU to sleep. There is no guarantee that system will keep your background service alive. For deeper understanding I can suggest you to learn about services and doze mode.
Consider using Push notifications or at least job scheduling mecanism.
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.
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 want to create android app that while i am in my wifi area it will use the wifi soon as "MyWifi" is not in reach should change and start data connection through 3g/4g...so my question is how to make the application to run 24/7 and drain less as possible battery, also if anyone can givme something about wifi and data connection what are the system calls, or refer me to any tutorials od examples that think that i will find them handy<
Thanks
You will not want to let your app "run" 24/7, because that will cause the device to never go to sleep and therefore drain the battery in a way that is usually not acceptable.
You can easily catch an broadcast of the state change of your wifi connection.
For an example you can look here
If you want your app to be running 24/7, is it to react to some events? Because you can usually catch any event with BroadCast-Receivers or Intents. In most scenarios this is the way to go.
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.