6

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??

Goo
  • 1,318
  • 1
  • 13
  • 31
NitZRobotKoder
  • 1,046
  • 8
  • 44
  • 74
  • 1
    Use wakelocks and drain the battery; or else don't try to do this. Or decide if C2DM can meet your needs instead. That's the tradeoff of running on batteries! – Chris Stratton Jul 02 '12 at 17:09
  • 2
    C2DM will not serve my cause..Anything else u can suggest chris!! – NitZRobotKoder Jul 03 '12 at 06:37
  • Maybe your device have save battery setting that turn off network when screen lock? – xtr Jul 05 '12 at 07:15
  • please be more clear in asking questions next time... After 2 days u wrote that App is working WITHOUT problems on S2..From 1st version of question one can come to logical conclusion that u have problem trying to do it on SGS2.. Samsung Rugby Smart I847 u mention first time after 2 days of original question... – Ewoks Jul 05 '12 at 15:57
  • There is an advance wifi setting that says 'Keep Wi-Fi on during sleep' on my i9003, the default value set to never. – xtr Jul 11 '12 at 01:50

5 Answers5

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..

Community
  • 1
  • 1
Ewoks
  • 12,285
  • 8
  • 58
  • 67
  • I do have the service, Issue is my C/Native Code is the one who receives the requests from server and then it will give it to my android Application Layer(UI),Here the requests are not reaching the C/Native Code as CPU is not running. – NitZRobotKoder Jul 05 '12 at 06:45
  • I am doing this "mPartialWakeLock.release()" on my Application Shut Down..So it will drain my Battery!!! – NitZRobotKoder Jul 05 '12 at 09:39
  • Ewoks Like i have mentioned..Other locks will not my server my purpose!!My Service Will talk to my C/Native Code!!! – NitZRobotKoder Jul 05 '12 at 10:18
1

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.

Artyom
  • 1,599
  • 12
  • 22
  • totally agree with @Artyom . I guess his problem is using of native code for "all business logic of login/Logout etc.." - meaning everything! That is why he is keeping WAKE_LOCK too long, which of course drain battery.. – Ewoks Jul 05 '12 at 11:56
  • But application works on S2 Device like charm!! Issue is with Samsung Rugby Smart I847 – NitZRobotKoder Jul 05 '12 at 13:41
  • @NitZRobotKoder Maybe on S2 the device stays awake long enough for your processing to finish. Have you tried what I suggested in my answer? – Artyom Jul 05 '12 at 13:58
  • @Atryom point here is when device is in sleep,network packets are not reaching my Native/Code at all(Seen in WireShark,its not capturing requests). – NitZRobotKoder Jul 05 '12 at 14:31
  • Unplug your adb-usb cable which is probably keeping the device awake, then see if you can talk to it over the network sometime later without using a wakelock or a designed in wakeup mechanism such as the "network tickles" of Google C2DM. – Chris Stratton Jul 05 '12 at 20:28
  • @ChrisStratton Did this many times, everything works. I'm not using C2DM by the way, nor do I have any wakeup mechanisms... – Artyom Jul 06 '12 at 07:48
  • Obviously you do have a wakeup mechanism or stay awake condition, you just are not aware of it or why that is the case on your device. Code can't run while the processor is powered down... – Chris Stratton Jul 06 '12 at 14:44
0

No need for using the wakelocks, as they are unreliable and buggy.

It would be more efficient to use the system's own version of keeping the screen on in a manageable way that is taken care of by Android:

Within the onCreate in your activity, do this:

getWindow().addFlags(WindowManager.LayoutParams.FLAG_KEEP_SCREEN_ON | 
                     WindowManager.FLAG_SHOW_WHEN_LOCKED);

This is from the developer's API found here:

public static final int FLAG_SHOW_WHEN_LOCKED

Since: API Level 5 Window flag: special flag to let windows be shown when the screen is locked. This will let application windows take precedence over key guard or any other lock screens. Can be used with FLAG_KEEP_SCREEN_ON to turn screen on and display windows directly before showing the key guard window. Can be used with FLAG_DISMISS_KEYGUARD to automatically fully dismisss non-secure keyguards. This flag only applies to the top-most full-screen window.

Constant Value: 524288 (0x00080000)

By combining it with the efficient screen on flag, should get around the screen-lock facility. The only thing is to make sure that your activity is the top-most on screen.

To quote, on the usage of FLAG_KEEP_SCREEN_ON of PowerManager

public static final int SCREEN_BRIGHT_WAKE_LOCK

This constant is deprecated. Most applications should use FLAG_KEEP_SCREEN_ON instead of this type of wake lock, as it will be correctly managed by the platform as the user moves between applications and doesn't require a special permission. Wake lock that ensures that the screen is on at full brightness; the keyboard backlight will be allowed to go off.

t0mm13b
  • 34,087
  • 8
  • 78
  • 110
0

UDP data cannot be received while you App is running in the background. Because your client which is sending data as multicast. While you Mobile device screen locked and App is running in the background, in this case mobile hardware there is mac filter and ip filter which only can accept data which point to a particular IP which belongs to device . In simple word is you need to do unicast. For example : There is client which sends data on a particular socket and ip( in your case you may be sending data on 255.255.255.255) and your data is broadcast on a particular port if there is any device ready to receive data on that port which is acting like a server for instance you App is acting like a server and if your app is running on foreground it received data. and When you app in the background App will not.

So that , what you have to do is you have to get the device IP Address and you have to send data on your device IP Address it means you are going to do unicast . In this your app will receive data either running the background or foreground and your mobile screen locked.

Abhay Singh Naurang
  • 141
  • 1
  • 6
-1

There is no need to create such codes that do not work - why don't you use a software that is ready? We use Ozeki Phone System XE PBX and Android phones (have 30 Android phones connected to the system with VoIP) and they work troublefree.

Check this out: Link

There has never been problem with RTCP protocol handling. Try the trial version if you want.

Hope I could help.

Nikhil
  • 16,194
  • 20
  • 64
  • 81
daniel_sinclair
  • 7
  • 1