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?
Cheers
Presumably, the device is using wifi to access the internet - it might be worth a shot to try this:
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.
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.
