At my work we all have Android devices which are used to dispatch jobs to us. It uses a web-app accessible through any web browser. When a new job arrives we are notified with an audible alert. However, because of the way Android handles the memory, it often "sleeps" (don't know the proper terminology) the web browser so if we get a new job through, we aren't notified unless we manually re-open the web browser to "wake" it.

Is there any workarounds for this issue?


  • 1. The device should also have app 2. Isn't it better to just send an email, maybe from the *webapp it self 3. don't let the screen sleep and you will get the notification.
    – roxan
    Commented Apr 12, 2013 at 3:37
  • @roxan - why the comment 2 hours later after comment below the answer I posted said it all?
    – t0mm13b
    Commented Apr 14, 2013 at 23:59
  • @t0mm13b Sorry, didn't see your answer from review window.
    – roxan
    Commented Apr 15, 2013 at 3:27

2 Answers 2


Presumably, the device is using wifi to access the internet - it might be worth a shot to try this:

  • Settings > Wifi
  • Hit on Menu to bring up Advanced
  • Tap on that menu option
  • Keep Wifi on during sleep, check that, make sure its set to Never

In that way when the device goes to sleep, wifi is still active and running and the web app should still work and

When a new job arrives we are notified with an audible alert


The above answer is not the correct answer, rather from the comments below, this is definitely the one, in which I quote,.

Maybe, the approach to managing the jobs is done the wrong way, especially in context of Android - a custom app that has a service using a partial wake-lock to "ping" checking on jobs, send an event to the app and the app wakes up. IMHO, a browser is not the right tool for the requirements in your case.

In short, there is nothing that can be done to keep the web-browser "alive" while the device is sleeping, as Android, behind the scenes, when the kernel is not in sleep state, is tracking what apps are running, and depending on power and memory constraints, especially in the case of a web-browser page, (if it has a lot of styles, the more elaborate the page, the more resources hogged up as a result, especially if it has a lot of Javascript behind the page) this could be the job for the kernel to shoot it down and eject it from memory hence not reliable route to take.

TL;DR: A proper application instead of just web-browser will resolve the OP's problem.

Off-topic: There was a piece covered by the technology section under the BBC news in respect to mobile web browsing and how it can affect the battery due to the way web pages are designed, rather, they were designed incorrectly for the mobile platform, too much styles, too much scripting, not to mention Flash as well, they all had adverse affect on how Android displays/renders the page which in turn meant a lot of CPU cycles consumed to do just that.

  • This is likely not an issue with wifi, but rather Android itself suspending the Browser app after a long period of inactivity to free up that memory for something else. But I don't know any way to prevent it from happening. Commented Apr 12, 2013 at 1:15
  • 2
    Maybe, the approach to managing the jobs is done the wrong way, especially in context of Android - a custom app that has a service using a partial wakelock to "ping" checking on jobs, send an event to the app and the app wakes up. IMHO, a browser is not the right tool for the requirements in your case... :)
    – t0mm13b
    Commented Apr 12, 2013 at 1:23
  • I agree with this. The browser on a mobile device certainly is not the best way to accomplish this. I think the best option would be creating an app that supports Android's Cloud to Device Messaging (C2DM). This would allow server to notify the app without needing the app to be open or even running. Commented Apr 12, 2013 at 3:27
  • We have just migrated from Win Mo which was an app but now its gone web based. Yes, the real issue is the memory management in Android sleeping the browser to free up memory, nothing to do with the WiFi (plus we are on mobile data 95% of the time), and no email would not be better, data needs to be input which is much easier and quicker through an app. I agree, a webapp is not the right way, it should have been an app but unfortunately this is not the case. Anyone else know how to keep the browser "alive" in memory? Commented Apr 14, 2013 at 22:41

The best option would be to tweak the low memory killer's minfree parameters.

Some background:

The Low Memory Killer is the mainstay of Android memory management. It's a more elegant approach than the Linux oomkiller and it works proactively to maintain the free pool rather than only kicking in when you're completely out of free memory. It separates apps into several categories for killing if the free memory pool gets below certain points. They're generally in the following order, from first-to-die to last:

EMPTY_APP - These are apps that are not doing anything, nor waiting to do anything. They're just sitting around in memory.

CONTENT_PROVIDER - These are background apps that content to active apps (e.g. The play store uses one to check for updates periodically. HTC Facebook sync is another common example).

HIDDEN_APP - These are sitting in the background, not doing anything, but are still alive and possibly waiting for something.

SECONDARY_SERVER - A server running in the background to provide services for a currently running app.

VISIBLE_APP - This is an application that is in the background, but it is presently doing something.

FOREGROUND_APP - This is what is presently running and on-screen.

If the free memory pool drops below a certain amount (e.g. 80MB is the default on my GS3), the system will first start killing off anything listed as an empty app until the pool is back above that line. If after it kills off all the empty apps the memory is still below the next line (e.g. 64MB), it'll start on the content providers, and so on, until eventually if only the foreground app is taking up all the memory (On my GS3, if everything except the foreground app has been killed and there's still less than 32MB of memory free) and threatening the system, it'll get killed off eventually.

Coming back to your actual question, what we want to do is adjust these values down, so the killer will kick in later and hopefully not kill the browser when you're still wanting it open.

The app MinFreeManager will allow you to adjust these values. Alternatively, they can be edited directly in /sys/module/lowmemorykiller/parameters/minfree where the parameters are in pages (4 kilobytes, so a value of 8192 means 32MB as ((8192*4)/1024=32MB), and listed in reverse order from what I listed above. Both of these will require root. If you don't have root, there's basically nothing we can do to help.

In your case, the HIDDEN_APP parameter (4th item in the minfree file) is probably what we need to change. For example, this parameter is by default 56MB on my GS3. Cutting this in half to 28M or using the mild preset in MinFreeManager would be a good starting point for tweaking.

  • The OP makes no mention of whether they are rooted or not, but considering the OP's question, it is a device designated for work (possibly not the OP's but owned by their company) so your answer is not exactly on the ball! And MinFreeManager app requires root and also, the OP is not intending to mess with the device in question also! :)
    – t0mm13b
    Commented Apr 15, 2013 at 19:46

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .