UDP / RTCP Packets inaccessible to the device / application When the device screen is locked

Question

My VOIP Android Application has a C / Native Library that implements all the business logic of I / O, etc.

The problem with this is when the device’s screen is locked, the application (c code) cannot receive any packets from the server. I checked this with Wireshark. The processor seems to be down.

I was able to solve the problem described below in my INIT application.

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 the above will leak the battery.

Why do not requests reach my application? How can I get the processor of the processor all the time when the screen is LOCKED and receive requests from the server?

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

The application works on Galaxy s2 (is it because its dual-core processor and the processor are on the LOCK screen?) How did SKYPE and VIBER develop WRT in sleep mode?

Answer 1

Have you had a use of service ?

Service provides an opportunity for an application to tell the system what it wants to do in the background (even if the user does not interact directly with the application). By launching it, the system will schedule work for the service, which will be performed until the service or someone else explicitly stops it.

I think this may help .. Greetings

EDIT: Okie, I haven't mentioned services before. I'm still not sure if you have two problems (drain battery AND not receiving data) or only one where ur receives data with drain ..?

Given that the battery is low, you can experiment with various WAKE_LOCK flags.

The important thing I noticed is that you did not block the release with mPartialWakeLock.release() , as the related links from the WAKE_LOCK page advised:

The battery life of the device will greatly depend on the use of this API. Do not buy WakeLocks if they really do not need you, use the lowest possible levels, and be sure to release it as soon as you can.

In addition, according to some other reports , the battery discharge rate depends on the work and the efficiency of the cheers performed in the service, so we can not help without seeing more code ..: S

Btw .. IMHO, if you just wait for an incoming call and continue to WAKE_LOCK all the time, this may cause a high battery drain. Think about what you need and try to minimize the use of resources if they 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 starts a service that establishes a permanent TCP connection to the server at startup in order to be able to receive messages from the server. The service does not receive locks. This part of the application was implemented some time ago, and so far I have not had any problems with the fact that you could not receive messages from the server. After reading your question, I decided to check why I did not have this problem.

I thought that even if I do not hold any locks, perhaps there are other applications that therefore keep the processor running. Running adb shell dumpsys , I noticed that this is not the case: mLocks.size=0 .

This should mean that the application can still receive packets, even if the device is sleeping. I could not find anything official here, but a few posts on the Internet seem to agree:

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

---

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

Must. ( source )

However, note that both sources recommend that you acquire a tracking lock for packet processing to prevent the device from falling asleep during this processing. I do not do this in my application (maybe I should), but my processing is really short.

When you say that your requests do not reach your application, are you sure that this is not so? Maybe they are, but your application falls asleep before it can send a response? Try to get a lock after you receive data on your socket and release it after processing is complete.

Answer 3

No need to use wakelocks, as they are unreliable and erroneous.

It would be more efficient to use a native version of the system that supports the screen in a controlled way that Android will take care of:

Inside onCreate in your activity do the following:

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

This is from the developer API found here :

public static final int FLAG_SHOW_WHEN_LOCKED

Starting with: API Level 5 Window flag: a special flag so that windows are displayed when the screen is locked. This will allow application windows to take precedence over key protection or any other lock screens. It can be used with FLAG_KEEP_SCREEN_ON to turn on the screen and display windows immediately before showing the key protection window. Can be used with FLAG_DISMISS_KEYGUARD automatically automatically cancels unsafe keyguards. This flag applies only to the top-most full-screen window.

Constant Value: 524288 (0x00080000)

By combining it with an effective screen by the flag, you need to bypass the screen lock. The only thing you need to do to ensure that your activity is the latest on the screen.

To quote, use the FLAG_KEEP_SCREEN_ON 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 tracking lock, as it will be properly managed by the platform when the user moves between applications and does not require special permission. Intrusion lock ensures the screen is turned on at full brightness; Keyboard backlight will be enabled.

Answer 4

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

Note this: Link

There has never been a problem processing the RTCP protocol. Try the trial version if you want.

Hope I can help.

Answer 5

UDP data cannot be received while the application is running in the background. Because your customer who sends data as a multicast. While the screen of the mobile device is locked and the application runs in the background, in this case the mobile device contains a mac filter and an ip filter that can only receive data that points to a specific IP address belonging to the device. In a simple word, you need to do unicast. For example: There is a client that sends data to a specific socket and ip (in your case, you can send data to 255.255.255.255), and your data is transmitted on a specific port, if there is any device ready to receive data on this port, which acts as a server, for example, an application works as a server, and if your application runs in the foreground, it receives data. and when the application will not be in the background.

So what you need to do is you need to get the IP address of the device, and you need to send data to the IP address of your device, which means that you are going to do unicast. In this case, your application will receive data either behind the background or in the foreground, and your mobile screen will be locked.