UDP/RTCP Packets not reaching Device/Application Whens device screen is Locked

Question

My VOIP Android Application has the C/Native Library which does all business logic of login/Logout etc.

Issue with this is when the device screen is locked the application(c Code) is not able to receive any packets from the server. I verified this with Wireshark. It looks like the CPU is not running.

I was able to solve the issue doing below on my application INIT.

WakeLock mWakeLock =  null;
PowerManager pm = (PowerManager) cxt.getSystemService(Context.POWER_SERVICE);
if(mPartialWakeLock == null){
    // lock used to keep the processor awake.
    mPartialWakeLock = pm.newWakeLock(
        PowerManager.PARTIAL_WAKE_LOCK
            | PowerManager.ON_AFTER_RELEASE, TAG);
    mPartialWakeLock.acquire;
}

But doing above will drain my battery.

Why the requests are not reaching my application? How can I make device CPU up all time when Screen is LOCKED and receive requests from the Server?

Note: EDITED Device Used: Samsung Rugby Smart i847 OS : Android OS, v2.3.6 (Gingerbread.UCLA4)

The the application works on Galaxy s2.(Is it because its Dual Core Processor and CPU is up on Screen LOCK?) How Does SKYPE and VIBER designed WRT to Sleep Mode??

Answer 1

Did u consider using service?

Service is providing a facility for the application to tell the system about something it wants to be doing in the background (even when the user is not directly interacting with the application). By starting it, system will schedule work for the service, to be run until the service or someone else explicitly stop it.

I guess that can help.. Cheers

EDIT: Oki, u didn't mention services before.. I am still not sure if u have two problems (draining battery AND not receiving data) or just one where u r receiving data with drain..?

Considering draining battery u could experiment with different flags of WAKE_LOCK.

Important thing I noticed is that you didn't release lock with mPartialWakeLock.release() as adviced on linked WAKE_LOCK page:

Device battery life will be significantly affected by the use of this API. Do not acquire WakeLocks unless you really need them, use the minimum levels possible, and be sure to release it as soon as you can.

Additionally, according to some other posts, battery drain speed depends on work and effectiveness of things u r doing in the service, so this is where we are not able to help without seeing more of the code.. :S

Btw.. IMHO if u just wait for incoming call and u keep WAKE_LOCK all the time, that might be a reason of high drain of battery.. Think what u need what for and try to minimize use of resources if u don't need them..Consider WIFI_LOCK for example, and release WAKE_LOCK as soon as possible..

Answer 2

I am working on a similar application that runs a service that establishes a persistent TCP connection to a server upon launch in order to be able to receive messages from the server. The service does not acquire any locks. This part of the application has been implemented a while ago, and so far I haven't had any problems with not being able to receive messages from the server. After reading your question I decided to test why I wasn't having this problem.

I thought that even if I am not holding any locks, maybe there are other applications that are, which therefore keep the CPU alive. Running adb shell dumpsys, I noticed that this wasn't the case: mLocks.size=0.

This must mean that the application is still able to receive packets, even if the device is asleep. I could not find anything official on this, but several posts on the internet seem to agree:

Although I haven’t found a good example of where this is documented, it seems that even if your phone is asleep, if data is received on the connection, your code will be woken up [...] (source)

---

> Say that the device is in deep sleep and the network stack receives an incoming packet. Will that wake the device up?

It should. (source)

However, note that both sources recommend that you should acquire a wake lock to process the packets, in order to prevent the device from falling asleep during this processing. I don't do that in my application (maybe I should), but my processing is really short.

When you say that your requests are not reaching your application, are you sure that they aren't? Maybe they are, but your application falls asleep before it can send a reply? Try acquiring the wake lock when you receive data on your socket and releasing it after you are done with your processing.