Also, DEFINITION UPDATE FAILED. Network error attempting to access the Webroot servers. Please ensure your device is connected to the Internet.
Also, Webroot Secure Anywhere Mobile Premier (process com.webroot.securing full) has stopped unexpectedly. Please try again.
DEFINITION SET 330. Version 18.104.22.16859.
Is somebody know what to do??? The HELP recommended to post on FORUM to get E-mail from MODERATOR to send collected system data from phone for tech support. Or may be it would be solved by itself??? For example, via updates?? But how come, the updates fail to be installed?
Best answer by MikeRView original
I fully understand your frustration. Shouldn't I have my sentiment for WSA and shouldn't I have believed in Webroot capabilities to resolve this problem I would have already swapped WSA Android for another AV solution.
I think the main problem is that Webroot is complaining for insufficient RAM but WSA itself is the glutton in fact. In my case WSA eats around 70 MB of RAM whereas all other applications doesn't exceed more than 12 MB but majority of them is around 5-6 MB. So it easily explains why I am not getting the OOM error once WSA is terminated and restarted, i.e. RAM is freed up.
Yes it is annoying to terminate and restart WSA to let allow the proper definition sets updates but please give them at Webroot a chance to troubleshoot this issue. I trust Roloc and other folks are doing their best to get over this problem as soonest.
Yes it is annoying to terminate and restart WSA to let allow the proper definition sets updates
- I've tried to force update after WSA has been terminated and get the same problem.
but please give them at Webroot a chance
- they've had 8 weeks
RAM Management in Linux/Android
As I had mentioned before, on a PC, you have virtual memory that serves as sort of a "backup" to your physical memory. And I had mentioned that this sort of fail-over doesn't exist on Android devices. Well, it's worse than that. Android works more like Linux in terms of RAM management, in that there is really no such thing as "free" memory until the operating system declares that memory to be free. On Linux/Android systems, all memory is always in use at all times. Theoretically, and usually in practice, that means your memory is optimized for faster distribution. On Linux, that works wonderfully most of the time. On Android, well, it's kind of hit-and-miss.
It's so hit-and-miss that the process that controls memory allocation was actually replaced wholesale by certain device manufacturers (Samsung, notably), who realized early on how buggy that original process is. The process is called "Garbage Collector," (though it could just as easily be called Garbage - The Collector) and it's relied upon by everything running on your device. Problems were observed with Garbage Collector, dating back to the earliest versions of Android. It's actually been rewritten three times since 2.1, and it still doesn't really work right all the time. Suffice to say though, the older your version of Android, the older your Garbage Collector, and the more likely you are to run into OutOfMemory issues.
The trash man is saying the truck is full when it really isn't, so maybe it's time to look at a new trash collection service. Where would one find a newer trash collection service? In this case, in an upgraded OS.
The best way to deal with this, if your device will support a newer version of Android, would be to upgrade your OS, or if your provider won't allow you to do that (and that's squarely on them, as Garbage Collector has been rewritten multiple times due to known bugs), perhaps it's time to look at a new device. I know that's not something anyone wants to hear, but it's inevitable that eventually, with any technology, that's going to happen.
Where do we go from here?
So, if you're getting this error message, in short, you're running into a bug - the proximal cause of which is the Garbage Collector in the OS itself. All Webroot can do is call on the function that should work and hope it works like it's supposed to. If it doesn't work, it's due to what are, in fact, known issues in the Android OS itself. Webroot can only do so much to code around an OS defect. Limiting the size of our footprint is always a top priority, and the most recent changes to the definitions managed to help with this kind of problem in most cases. Amazingly, we cut the "out of memory" errors down from a sizeable amount to what I'm reading as a total of about 5 reports now, combined from here, support interactions, and the bug reports the apps themselves generate. What we unfortunately cannot do is rewrite an OS service, because that is locked down by Android itself. The only solution for some people will be to upgrade your OS. For people who can't do that, it's either time for a new device, or you can wait to see if we come up with another way to shrink the program, or unfortunately, perhaps Webroot is not for you. I'm sorry to be the bearer of bad news, but that's the word from development.
I'm sorry for the confusion. If you read my response just a bit closer, you'll notice that what I'm saying is that Samsung replaced the Garbage Collector with one that works better on their devices. So no, I realize you don't own a Samsung, or you likely wouldn't be reporting the problem at all (though it's possible the same issue could occur I suppose).
I'm also not trying to imply that this issue wouldn't ever exist on a more modern OS. It's just less likely to exist. You can still be either using all your memory and legitimately be getting the out of memory error, or the java garbage collector may still be malfunctioning even on a more modern OS. Ultimately, regardless of the fact that this error is appearing when a Webroot app is running, the error isn't even being thrown by Webroot - it's coming from the OS itself when the OS fails to function as designed.
What you are running as an on-screen app vs. what runs in the background (like in push notifications for instance), are different things. To check what's actually running, you can go to Settings -> Applications -> Running Services. Facebook, for instance, on my own device is set to generate push notifications, and it takes up 46MB just doing that alone.
The memory we are talking about is like RAM on your computer and has to do with how much can be going on on your device at any given time. It has nothing to do with storage space, which on a PC, would be referred to as hard drive space, which is the kind of memory you're referring to when you're talking about pictures. That is a different kind of memory.
If you would like to open a ticket, you are welcome to do so, but the response provided is coming straight from development. Support will not have a different response for you. If you wish to make a case for receiving a refund, a ticket through support would be the route to take in this case. I can't say for sure what the outcome of such a request would be, as I personally have no control over the refund process. Typically, refunds are not processed beyond 70 days, and you've indicated your purchase is over 70 days old.
It's certainly not your fault that you're getting an OutOfMemory error on your device, but it realistically isn't Webroot's fault either that a buggy Java subroutine in the Android OS isn't handling a request properly, thus generating an error. It's a lousy situation, and I feel your pain. I'm going to research what else we can do for you in light of your situation, and I'll follow up with you directly.
Jaxx, it appears you replied without reading the private message I sent you. Please check your private messages. There is a little mail icon under the search box towards the top right side of the screen when you are signed in. Please read the message there and reply to it, so I can attempt to assist you as best as possible with the given situation.
If I was in your position, as one of the handful of remaining affected customers, for which there is possibly no workaround, I would evalutate my options in terms of whether or not the PC protection is worth having on its own - Android protection aside.
Not all of your Webroot for Android features don't work. Backup & Sync, SecureWeb, Wipe, Scream, Lock, and Locate don't rely on definitions updates, so those should all still be working for you. The antivirus portion of the Android protection does not, and possibly may never, work properly on your particular device. That would bother me too, but even if it was my own device or one of the developers' devices, it's not something we can fix immediately or perhaps ever fix, for reasons outlined in prior posts.
To answer your question about the frequency of OutOfMemory errors across the board, yes, this actually is a relatively common issue across various programs. Try Googling "OutOfMemory Android," and you'll see a big list of threads on various forums that call out this issue. A great deal of them are from frustrated developers on dev forums, lamenting how their workarounds don't seem to solve all of the problems. Here and there, you'll see threads that appear to have been resolved, just like how our fix solved the problem for the vast majority of our users. Other places, you'll see developers running into the brick walls of Android OS limitations or users with OutOfMemory issues that never got fixed.
What does work in your particular case is the entire PC product, 3/4 of the Android protection, and all of the Mac protection if you have a Mac. If you've been with us for 10 years, you'll know there was a time when we didn't have Android protection at all, and you were still a customer then. Perhaps a combination of Webroot on your PC and something else on your Android would work out for you (again, please see my private message for more detail on this). If not, and you ultimately decide to leave Webroot, that's unfortunate and we'll be sorry to see you go. Sadly, there isn't anything we can do in the short term to convince you otherwise, beyond pointing out what I mentioned above.
Nobody likes "bad news" posts, myself included. If there was something development could do about this issue quickly for the remaining affected customers, it would be happening. You have my sympathy for your frustration. :( And of course, if development does manage to find a way to get around this issue for the remaining customers that are reporting it, either myself or one of the developers will be sure to update this thread.
Nice reading, you have shared tons of technical background information about Android and WSA, thanks for your effort. However I can conclude that in no of your post there is a plain explanation why other Android security solutions, and believe me I have tested more than 10 others, never have had this OOM error, at least not on my HTC. So, are they more smart as far as AV definitons deployment is concerned?
Thanks & regards,
The issue of placing a system requirement on the page for memory usage was something I initially agreed with you about when it was suggested a few pages back. That was before talking to our developers about why this issue isn't fixed for every last customer. Since the root of the issue is that the Android OS itself refuses to free up memory, when by all rights, it should be freeing up that memory, placing a value as a memory requirement would be misleading and arbitrary to anyone experiencing this particular issue. If we did specify a particular value, odds are, you, Jimbo, Jaxx, et. al, would report back "But I meet that value! This should be working!" And you would be right - you probably do meet that value. But again, the core of the problem is not that we are actually exceeding available memory. The core of the problem is that there is free memory to be had, and the operating system isn't handing it over to us as it should.
So it is not a matter of requirements.
My wife has a Droid Razr MAXX and webroot runs fine on it, so it is just some combo of apps installed or running and/or the version of the Garbage Collector that are still having the issue.
If it is not shedding threat definitions and is dealing with the same range of threats as WSA, then it looks like it has managed the memory issue in a way that has eluded Webroot so far. So far as I understand it,all these security products rely on having a register against which to check for threats and, it seems to me, as the number of threats grows these registers are going to have to grow as well. It could well end up as a race between these registers and the amount of system memory installed (and its management). Sooner or later, a brick wall is going to be hit because memory can't be infinite while the number of threats could be in comparison.
WSA and its competing security products are, I guess, sooner or later going to have to undergo a root and branch re-think and re-design to minimise the dependence on an ever growing register/database of risk defintitions. They are going to have to work differently. Don't ask me how, I have not idea but it does seem to me to be an impending issue. At the same time, it also seems that Android itself could do with a massive security overhaul.
Also I would like to add we are working on this still. We are not giving up. We have had 5 bug reports over the past week to week and a half and that is one of the lowest of all the issues our users see. We have hundreds of thousands of users so making a change specifically to address that low percantage of issues that could dramatically degrade performance for the rest is something we need to balance and not rush.
Like Jim I don't like writting these kinds of posts. I fully understand you guys are frustrated and we are to. We have even more fixes that are going into our 3.1 release.
You can rest assured that that process started a couple of months ago and is ongoing. Some of those changes went out in the last release some are coming in the next release and even more are planned for the future releases.
The OOM error occures once a new definition set is released. It means that if there are let's say 2 days before another new definition set is out I am not getting the OOM error. I can check updates manually thousand times and no error observed. However when a new definition set is available I always am getting the OOM error. So it is the sign for me that a new AV definition has been released. So I have to go to Applications Manager and terminate WSA. After that I have to open WSA what triggers WSA to restart. Immediately after restart the orange exclamation jumps out and the definition set is always 373. Afterwards I have to run updates manually what successfuly loads the latest available definition set (today it is 391). Since then I don't have the OOM errors (when checking updates) until a new definition set is released. It is 100% reproducible issue on my end.
Then I have to do all this procedure again to get the latest AV set what makes me indeed mad. This time is tough for me as I am full of temptations to throw out WSA in favour of Avast mobile. Nevertheless later, after having back the green status and a cup of coffee I am fine. I keep WSA yet on my phone thanks to my immense loyalty to Webroot but you, at Webroot, don't rely that this will last forever.
I hope that the above detailed explanation how the OOM error reigns over my HTC will help Webroot techies & developers (Jim & Roloc) to resolve this nasty bug and yes it is a bug regardless what you say.
Yesterday WSA auto updated to AV set 391. It was the first time when it was done automatically without necessity to undergo terrifying terminating/restarting procedure stated in my above post. However today WSA automatically checked for updates (observed notification Last checked for definition update on 22.11.2012 at 7:50) and reverted definition set to 373. It seems that this AV set plays an important role in this OOM error issue. I have checked the web console and again there was last definition update before 42 years. Funny thing, indeed. So then I manually run update and received AV set 393 what is now correctly recorded in the console.
Sorry for bothering with my posts in this thread but I want to give Webroot staff as many information as possible. On the other hand I would appreciate Webroot breaks its silence and begins to again communicate via this thread or PM.
There will be improvements in version 3.1 that may help to address the remainder of the OutOfMemory issues still being experienced. 3.1 should be available soon, but we don't have an exact date since Google still has to go through their QA process. Roloc or I will reply back again when it's out. 🙂
Thanks Jim, Roloc and others of Webroot for your hard work to beat this error.
Stay tuned ;)
I am anxious to hear how it is going after a few days of use in the field.
I underwent an extensive testing of the latest 3.1 build on my HTC focusing on the definition set updates which were malfunctioning due to the OOM error. I was playing with the date & time, I was shifting them back and forth to see if AV definitions will be automatically installed or the error will be occuring again. I have got satisfying results ... AV definitions were installed successfuly and no more errors appeared. After that I reverted the date & time back to the actual and waited for updates as per the set schedule which resulted in receiving AV set 400 yesterday and AV set 401 today.
Therefore I dared to proclaim the OOM error was defeated :D
I want to express my thanks to all at Webroot who contributed to resolve this issue. Well done ;)
Furthermore, I want to encourage all users who were plagued with the OOM error to share their experience with the latest 3.1 build.
Thanks & regards,