Interested in solving a real puzzler? Then read on!
The patient: a rooted, otherwise stock Jelly Bean (JRO03C 4.1.1) Galaxy Nexus. Being used as an everyday phone (and a bit of development).
The symptoms: Excessive battery drain by "Google Services", but ONLY on my home Wifi network!
This is where things get weird: on 3G, on my company's work Wifi, and without network, the battery drain is absent. I can *reliably* cause Google Services to start hammering the wakelocks, and stop them, just by moving to a different Wifi hotspot. There's NO change in functionality: Google Talk, Play Store, and network access work exactly the same. Push messages seem to come in normally too, but I haven't tested that very well. There's no configuration change whatsoever.
More details: After installing BetterBatteryStats, I've gotten a better look at the wakelock draining the battery. After gathering stats for 25-30 minutes, the following wakelock is the top user:
Code:
GTALK_ASYNC_CONN_com.google.android.gsf.gtalkservice.AndroidEndpoint (Google Services): 7 m 47 s (467 s) Count:786 30.3%
So, I decided to check logcat for "GTalkService" messages, and see if there's a major difference between work (good) and home (bad).
Turns out I get a lot of the following at home, but not at work:
Code:
[ 08-15 17:36:02.719 709: 709 I/GTalkService/c ]
[[email protected]] connect: acct=1000000, state=CONNECTING
[ 08-15 17:36:34.461 709: 1177 E/GTalkService ]
connectionClosed: no XMPPConnection - That's strange!
This is repeated a LOT and looks like it correlates quite well with the wakelock.
I use the phone, and I would hate to wipe it completely: I would really like to get to the bottom of this.
First of all, I'm not 100% sure this is a Galaxy Nexus only problem. It might be Jelly Bean, or ICS, or whatever. Would you suggest I post on the Google Android bug list, where the crickets chirp, and major bugs disappear into a big Python black hole?
Thanks guys! If only for reading this far!
Update 2012-10-02:
OK, I have eliminated my firewall from the equation: obviously I can't necessarily just whack the work's firewall without consequences. Nothing's blocked, and all services on the phone seem to work.
As for other devices: I dug up my old Nexus One (Gingerbread, stock), and upgraded my Transformer Prime to Jelly Bean. Both do not show the error in logcat, and neither have the battery drain issue. Just for kicks, I checked the version of the Google Services Framework on all three:
Samsung Galaxy Nexus: 4.1.1-398337
ASUS Transformer Prime: 4.1.1-438695
HTC Nexus One: 2.3.6
Wanna bet there's a bug in 4.1.1-398337 that got fixed in 4.1.1-438695?
Further update:
I also tried the following with no success:
Delete app data for Google Services Framework (NOT RECOMMENDED!)
Remove Google accounts from the phone.
Re-add Google accounts to the phone.
Update: 2012-10-04
I think I found a workaround. It looks like it's a domino effect thingy that happens here:
1) I've got a Netgear N600 ADSL/Wifi router at home. On my 2.4GHz radio, I set up two access points: one for my stuff and one for guests. I made sure to delete the guest account from all my Wifi equipment to make sure there's no "fighting" or "flapping".
2) It appears that the phone ignores the Wifi-'stay connected while sleeping' setting, or the radio is broken. When the phone goes to sleep, it disconnects from Wifi.
3) When the phone disconnects from wifi, the Google Services Framework lose connection: this causes the phone to wake up.
4) When the phone wakes up, Wifi gets re-established. This makes Google re-connect.
5) The phone goes back to sleep and we return to step #2.
This causes a LOT of wakeups, lost connections and other crap. Since the phone doesn't lose connection when it's awake, it's fricken difficult to debug. Also, it's NOT a signal quality issue. My phone can be right next to the access point and it wouldn't help.
So, could you guys try different access point settings at home? I've heard WMM, QoS and some of the protocols could cause the Galaxy Nexus's radio in Jelly Bean to go a bit wonky.
-- Jan Gutter
jangutter said:
Interested in solving a real puzzler? Then read on!
The patient: a rooted, otherwise stock Jelly Bean (JRO03C 4.1.1) Galaxy Nexus. Being used as an everyday phone (and a bit of development).
The symptoms: Excessive battery drain by "Google Services", but ONLY on my home Wifi network!
This is where things get weird: on 3G, on my company's work Wifi, and without network, the battery drain is absent. I can *reliably* cause Google Services to start hammering the wakelocks, and stop them, just by moving to a different Wifi hotspot. There's NO change in functionality: Google Talk, Play Store, and network access work exactly the same. Push messages seem to come in normally too, but I haven't tested that very well. There's no configuration change whatsoever.
More details: After installing BetterBatteryStats, I've gotten a better look at the wakelock draining the battery. After gathering stats for 25-30 minutes, the following wakelock is the top user:
Code:
GTALK_ASYNC_CONN_com.google.android.gsf.gtalkservice.AndroidEndpoint (Google Services): 7 m 47 s (467 s) Count:786 30.3%
So, I decided to check logcat for "GTalkService" messages, and see if there's a major difference between work (good) and home (bad).
Turns out I get a lot of the following at home, but not at work:
Code:
[ 08-15 17:36:02.719 709: 709 I/GTalkService/c ]
[[email protected]] connect: acct=1000000, state=CONNECTING
[ 08-15 17:36:34.461 709: 1177 E/GTalkService ]
connectionClosed: no XMPPConnection - That's strange!
This is repeated a LOT and looks like it correlates quite well with the wakelock.
I use the phone, and I would hate to wipe it completely: I would really like to get to the bottom of this.
First of all, I'm not 100% sure this is a Galaxy Nexus only problem. It might be Jelly Bean, or ICS, or whatever. Would you suggest I post on the Google Android bug list, where the crickets chirp, and major bugs disappear into a big Python black hole?
Thanks guys! If only for reading this far!
-- Jan Gutter
Click to expand...
Click to collapse
Could it be that your home router's firewill is somehow blocking parts of GTalk traffic, causing it to continuously retry connecting?
Petrovski80 said:
Could it be that your home router's firewill is somehow blocking parts of GTalk traffic, causing it to continuously retry connecting?
Click to expand...
Click to collapse
Nope, I checked that: there's no firewall. At work there is, but it doesn't affect my phone (services are not affected visibly). Google Talk works fine in both situations.
any developments in this? have an s3 which is behaving similarly. my WiFi is always on as I'm usually near a hotspot at work home /gfs.gtalk_async wake lock showing up in better bat stats. been having battery drain issues for a while now and decided it was time to do some research.turned off pretty much every synch/auto backup app on the phone but still draining, not quite as bad, but still seems to struggle to stay asleep for very long!
Exactly the same
cricka15 said:
any developments in this? have an s3 which is behaving similarly. my WiFi is always on as I'm usually near a hotspot at work home /gfs.gtalk_async wake lock showing up in better bat stats. been having battery drain issues for a while now and decided it was time to do some research.turned off pretty much every synch/auto backup app on the phone but still draining, not quite as bad, but still seems to struggle to stay asleep for very long!
Click to expand...
Click to collapse
Does anyone have solved this.. i have got exactly the same situation as Jan. No trouble at work but only at home.
Not affecting ASUS Transformer Prime
Nothing new here, except I also cross-checked with my ASUS Transformer Prime. There's no drain on it, and also no errors in logcat about GTalkService.
I'll post an update once I've checked my trusty old Nexus One out of storage, that'll happen next week, though.
Interesting note about the wifi. I only seem to get this problem during the week at work, on the weekends it doesn't happen that often. I get poor data connection at work and rely on the wifi instead. I'll try to not use the wifi for a day or so and see if the wakelock is reduced. Thanks for the tip, this has been a problem for a while now.
Galaxy s2 on Sprint
sgtlange said:
Interesting note about the wifi. I only seem to get this problem during the week at work, on the weekends it doesn't happen that often. I get poor data connection at work and rely on the wifi instead. I'll try to not use the wifi for a day or so and see if the wakelock is reduced. Thanks for the tip, this has been a problem for a while now.
Galaxy s2 on Sprint
Click to expand...
Click to collapse
Just take note: in general Wifi uses a LOT less battery than 3G. A better test might be to disable Wifi AND sync.
Jan
some decent insightful ideas here. My S3 on official stock based custom has bad drain over wifi. My google services framework version is the 4.1.1-438695 which isn't affected in your case so it's not that.
Better battery stats at first put google maps as the wakelock so I realised it's location service was left on so I turned that off. Then BBS varies and shows different apps and what not causing wakelocks but the drain remains the same.
My router is an Asus with custom linux firmware Tomato with a robust plethora of functions. I updated it yesterday and put the settings back closer to default. I'll have to try disabling WMM and QoS settings as their both already on at the moment. Also the kernel developer i'm on to quote: "Made a change in wifi offload filtering to deny muticast packets but allow multicast DNS packets."
After leaving wifi on last night the drain still remains at about 10% per 3 hours. Compared to before it used to be almost 15% per 3 hours. BBS doesn't show wlan_rx_wake as the top wakelock as most common before as that's down to running for 8 minutes in 9 hours rather than the top around 45 minutes. Instead battery-monitor is the top at a little over half an hour in the 9 hours. Googling battery-monitor shows little useful information but I assume it's like before where Wifi is waking the device and something OS related that turns on with it gets given the wakelock status although its not the trigger.
I'll have to try disabling WMM, QoS, auto-sync and gtalk and see how I go. Hopefully you're right about it being wifi disconnect related and can be fixed.
Infy_AsiX said:
Googling battery-monitor shows little useful information but I assume it's like before where Wifi is waking the device and something OS related that turns on with it gets given the wakelock status although its not the trigger.
Click to expand...
Click to collapse
Have you tried disabling the WiFi Power Save Mode on the S3? From this article:
http://www.s3forums.com/forum/galaxy-s3-general-discussion/1329-wifi-tip.html
1. Open up the Galaxy S3 phone dialer
2. Dial *#0011#
3. Look for the “ServiceMode” screen and press the left menu button
4. Select “WiFi”
5. You should see that the “WiFi Power Save Mode” button is “ON” – turn it “OFF”'
My colleagues with the same phone has serious battery drain until they use that.
Infy_AsiX said:
I'll have to try disabling WMM, QoS, auto-sync and gtalk and see how I go. Hopefully you're right about it being wifi disconnect related and can be fixed.
Click to expand...
Click to collapse
I seem to recall that the Google framework sends/receives a keep-alive packet once every hour or so. LOTS of stuff in the Android framework keep TCP connections open from the server side because otherwise the service provider just kills them. Blame stateful firewalls.
What could be happening here is that the WiFi chip offloads a number of these functions from the main CPU: i.e. it's got a simple TCP offload stack that just queues data for the main CPU to wake up. If the WiFi chip receives a keep-alive TCP packet with no payload, it doesn't bother to wake up the CPU and just absorbs it. If the WiFi chip goes to sleep, rather, it never receives these, the connection dies and the CPU needs to wake up on timeout and re-establish everything (eating battery in the process). It's paradoxically cheaper to keep the WiFi chip running on full power, than to let it go to sleep. This is pure speculation, and only one of many scenarios that might fit the facts.
The S3 has the *option* to change the WiFi sleep-mode from aggressive (default) to a value that lets the entire system use less battery. The Galaxy Nexus doesn't: which means that it may, or may not have the sleep-mode built in. In any case, it seems my router can remotely trigger disconnects when the main CPU is off, and by switching settings on it, I managed to perform a workaround. Unfortunately the Galaxy Nexus (on Jelly Bean, at least) seems to have a serious bug in this respect, and other people are not so lucky: http://code.google.com/p/android/issues/detail?id=35352
It seems that the core issue (WiFi disconnect), causes a knock-on effect, raising Google Services Framework, Android OS and potentially anything that syncs's battery profile.
Jan
Getting good drain now 1% an hour compared to 3%. Seems setting WMM to auto rather than enabled in tomato fixed it. The night before I had it disabled as well as QoS and it was bad as well. I will test further to be certain what's the scenario.
I've got a second S3 that's been suffering as well. Having two to test makes testing much faster. The service menu power save mode off didn't help. It caused strange disconnects with WMM in all states. S3 wifi menu would state poor connection and wouldn't reconnect. Note the S3 already has strange disconnects to begin with I find but in this case it sometimes wouldn't reconnect. Also restarting the phone resets the power save mode to enabled.
Can't find any information on a difference between enabled and auto in tomato WMM. I'll be sure to keep testing.
Sent from my GT-I9300 using Xparent Cyan Tapatalk 2
New Google Services Framework
Hey guys,
looks like Google Services Framework got a version bump on the latest Galaxy Nexus update: it's now listed as version 4.1.2-485486
This is for JZO54K (4.1.2).
It could be that they've fixed the knock-on effect (but the core issue is likely the same, since the radio code is apparently exactly the same).
Jan
I have this same wakelock on my evo 4g lte. Same log error exactly. Only on my works wifi. Problem is eliminated when running a Vpn on the phone. Only caveat Is all the free vpn services seem to disconnect after a period of inactivity.
I know this is an old topic but I had the same drain (30% overnight) on my Galaxy S2.
After weeks of searching and trying different things I found the solution.
Change DTIM value in your router configuration from 1 (default) to 255.
This value is usually in Advanced->Wireless tab on most routers.
Now my phone uses 2% battery overnight with wifi on, sync on instead of 30%.
Rawi666 said:
I know this is an old topic but I had the same drain (30% overnight) on my Galaxy S2.
After weeks of searching and trying different things I found the solution.
Change DTIM value in your router configuration from 1 (default) to 255.
This value is usually in Advanced->Wireless tab on most routers.
Now my phone uses 2% battery overnight with wifi on, sync on instead of 30%.
Click to expand...
Click to collapse
I tried this and got weird results. My phone couldn't connect to my network, but my tablet could (GT 7510) which also experiences the drain issue. How did you come up with the value 255? Any other value I can try? Thanks
Sent from my SGH-T999 using xda premium
SpinTX said:
I tried this and got weird results. My phone couldn't connect to my network, but my tablet could (GT 7510) which also experiences the drain issue. How did you come up with the value 255? Any other value I can try? Thanks
Sent from my SGH-T999 using xda premium
Click to expand...
Click to collapse
Try lowering this value to 10 or 8 and see if it helps.
Rawi666 said:
Try lowering this value to 10 or 8 and see if it helps.
Click to expand...
Click to collapse
Thanks, will give it a shot. Also, because of your post, I discovered that toggling wifi on and off stops Google Services from draining. It will still drain, if your wifi is set to turn off, when the device sleeps. I really think you hit the nail on the head, discovering the source of the problem. It's an issue I have been trying to fix for a long time and your post at least got me to toggling the drain. So thanks again!
Sent from my SGH-T999 using xda premium
Would love to he root cause of this... I had the same problem on my s3 and now on the s4.with and without custom roms etc. The problem only is work, and I'm putting it down to some service that the work firewall or something blocks... Only solution I've come up with is turning off the wifi when I'm at work.. Else I get in excess of 15min /hour of wakelock.
All apps etc. Up to date, sync on/off, no difference, all "location" settings turned off.
I give up.
Wifi signal strength!
Whatever Google did to cause a variety of wakelock problems, having a strong wifi signal seems to solve them. Apparently, wakelocks occur when there are unreliable connections to Google's servers.
Kal
keltickal said:
Whatever Google did to cause a variety of wakelock problems, having a strong wifi signal seems to solve them. Apparently, wakelocks occur when there are unreliable connections to Google's servers.
Kal
Click to expand...
Click to collapse
A friend with the nexus 4 and same problem told me to try disabling Google hangouts (formally talk).. Apparently it keeps refreshing itself once ur signed in (and it signs in automatically)... Will experiment tomorrow at work where I get the problem.
Sent from my GT-I9500 using xda premium
Hi all,
Posting this here because it's the device in question and no one answered over at general Android Q&A and Reddit hasn't been able to help.
Long time since I posted here but I'm at the limit of what I can effectively do so I'm looking for some help here and I believe this is a problem with the OS itself and how it handles shared settings and even with the Maps application, rather than being device specific.
First, specs:
Samsung Galaxy Nexus (UK HSDPA+) running Jelly Bean 4.1.1, completely stock and unrooted.
Asus Nexus 7 (also UK, though I'm not sure this makes a difference as the N7 has no GSM radio), Jelly Bean 4.1.1, completely stock and unrooted.
All apps are the latest versions.
Background: This problem has only existed as long as I have had the Nexus 7 in addition to the Galaxy Nexus. I'm 90% sure that the issue relates to the fact that I have location reporting enabled on the GNex and NOT on the Nexus 7. I'm signed into both devices with the same Google account. Occasionally one or the other will pick up the opposite one's settings with regards to location sharing, a PITA.
The problem: Ridiculous amounts of wakelocks caused by the Play Store, Maps and the Launcher. As you can see here (BetterBatteryStats pic included). imgur . com/ a/yz83J (I can't post the hyperlink because I've not posted 10 times yet.) This only seems to cause a problem on the Galaxy Nexus. I haven't noticed wakelocks or battery drain on the Nexus 7.
This absolutely drains my battery. If I kill off Play Store and Maps and clear all cache data then the wakelocks stop for a while.
Two days ago I was forced to uninstall all updates to Maps and return it to the default version and update it again as killing the process or even rebooting the phone failed to stop the wakelocks. This didn't stop the wakelocks but out of curiosity I just told the device to completely stop updating my location on it's own. This has completely stopped the wakelocks and the resulting power drain..
The catch: I'd really rather not have to leave location updating off to resolve this. It's only been happening since I got the Nexus 7 and I'm trying to get that to NOT report my location and the GNex to report. The reason I have it turned off is that I have it on train WiFi a lot, which displays my location as wherever the connection terminates. E.g. for an entire journey from London to the north, my history for that day shows that I travelled the distance between every point on the route that my phone reported and London Euston station where the Nexus 7 was connected, in about 1 second. This led to my location history being an utter mess!
The question: Any ideas on getting this working as intended? If I can provide any more data let me know. I've already run an ADB output of my alarm manager stats and it's showing the same as the BetterBatteryStats info.
The apps will constantly try to refresh maybe because it's trying to receive data like notifications.
You can try JuiceDefender or Greenpower or apps like that in order to limit how often a certain app syncs. Some ROMs also have such a feature if i'm not wrong.
If all else fails try a factory reset and see if the problem is fixed. Did you do a full wipe before changing to jb from ics? Maybe that could cause problems.
Sent from my Galaxy Nexus (AOKP JB | Popcorn Kernel)
Press the thanks button if my post was helpful
JamesInsights said:
The apps will constantly try to refresh maybe because it's trying to receive data like notifications.
You can try JuiceDefender or Greenpower or apps like that in order to limit how often a certain app syncs. Some ROMs also have such a feature if i'm not wrong.
If all else fails try a factory reset and see if the problem is fixed. Did you do a full wipe before changing to jb from ics? Maybe that could cause problems.
Sent from my Galaxy Nexus (AOKP JB | Popcorn Kernel)
Press the thanks button if my post was helpful
Click to expand...
Click to collapse
Thanks for the reply.
No I did not do a full wipe because the update to JB was delivered OTA when Google released them, these devices are completely stock. I believe the issue is that the GNex is attempting to update the location, the Google account is reading the Nexus 7 setting of not updating the location, then the response is bouncing back to the GNex, which insists it does need to update the location, etc.
As I said, I've temporarily solved this by stopping the phone updating it's location at all, however this isn't the best solution and since I've found the cause, I'm not convinced a factory reset or even reflashing the stock ROM will help. I'm pretty sure this is a deep OS issue, using the same Google account across 2 devices is great, until you want them to have different settings.
I'm probably gonna report it on code.google.com, but I very much doubt I'll get a response.
Since I have not posted 10 replies to the site, I'm using the Q&A to post some issues with the new Slimbean 4.3 weekly build 4.
The WiFi won't activate whenever the S3 is in range of a signal or site saved into the phone. I have to turn off the WiFi feature for about 10 seconds in order for the signal to be noticed/activated.
There is feedback from the Google Play Music app. I did not run a logcat to determine the time or frequency of the occurrence.
Finally, there appears to be an issue with the latest version of Maps along with location access. I uninstalled Maps 7.1 and placed 6.14 from the Slimroms site. It works better but the location access is still glitchy with other apps that require it.
All in all, this is however great progress on 4.3!
vtwalk said:
Since I have not posted 10 replies to the site, I'm using the Q&A to post some issues with the new Slimbean 4.3 weekly build 4.
The WiFi won't activate whenever the S3 is in range of a signal or site saved into the phone. I have to turn off the WiFi feature for about 10 seconds in order for the signal to be noticed/activated.
There is feedback from the Google Play Music app. I did not run a logcat to determine the time or frequency of the occurrence.
Finally, there appears to be an issue with the latest version of Maps along with location access. I uninstalled Maps 7.1 and placed 6.14 from the Slimroms site. It works better but the location access is still glitchy with other apps that require it.
All in all, this is however great progress on 4.3!
Click to expand...
Click to collapse
I'm not running slimbean, but I am on pac 4.3 and my wifi works fine. Maybe try either leankernel or kt747, the wifi drivers are contained in the kernel so maybe you'll have some more luck with them.
I've had an issue with the GPS as well, and disabling "use assisted GPS" in the phone settings fixed it 100%.
exodus454 said:
I'm not running slimbean, but I am on pac 4.3 and my wifi works fine. Maybe try either leankernel or kt747, the wifi drivers are contained in the kernel so maybe you'll have some more luck with them.
I've had an issue with the GPS as well, and disabling "use assisted GPS" in the phone settings fixed it 100%.
Click to expand...
Click to collapse
Thanks I'll give it a try.
The kt747 kernel works great! I also found out that the new privacy feature blocks GPS data coming in or going out. Turn off the privacy feature in the apps that require locator service.
Sent from my SAMSUNG-SGH-I747 using xda app-developers app