Obsolete
Status Update
No update yet.
Comments
st...@gmail.com
Information redacted by Android Beta Feedback.
da...@gmail.com
Thank you for reporting this issue. For us to further investigate this issue, please provide the following additional information:
Please upgrade to the latest release from the link
da...@gmail.com
Upgrade was never offered. I was offered directly Android 16. I can't
install Android 16 as I want to leave beta.
<buganizer-system@google.com> schrieb am Do., 27. Feb. 2025, 08:55:
install Android 16 as I want to leave beta.
<buganizer-system@google.com> schrieb am Do., 27. Feb. 2025, 08:55:
vi...@gmail.com
Thank you for reporting this issue. We have shared this with our product and engineering team and will update this issue with more information as it becomes available.
vi...@gmail.com
Thanks for reporting this issue.
-
We are handling "No more paying via Wallet because the system is not up to date" wallet issue here.
-
Please file a separate ticket for "Upgrade was never offered to install android 16" with details.
vi...@gmail.com
Just want to add, same situation as yours, only it's been happening since December.
After upgrading to stable the issue persists.
After upgrading to stable the issue persists.
mw...@gmail.com
Google, please DO NOT FORCE the radio to Constant Awake Mode all the time. I for one appreciate the *three-day* runtime I get with my HTC EVO 4G, which I'm sure would not be possible if the Wi-Fi radio were listening constantly.
The only course of action that will appease everyone would be to add a new user-configurable option to the Wi-Fi "Advanced" menu:
802.11 Power Save Mode:
* Auto (the current behavior)
* Constant Awake Mode (CAM) only
* Power Save Polling (PSP) only
The only course of action that will appease everyone would be to add a new user-configurable option to the Wi-Fi "Advanced" menu:
802.11 Power Save Mode:
* Auto (the current behavior)
* Constant Awake Mode (CAM) only
* Power Save Polling (PSP) only
st...@gmail.com
reminder / clarification:
the wifi sleep policy is *different* from the wifi power saving mode. in android, "sleep" for the wifi means to turn it completely off.
the wifi sleep policy governs when the phone should switch between wifi and mobile data. the power saving mode governs *how* the wifi device behaves while it's on.
i think the "constant awake mode" term is confusing people, since it refers to a power save mode. but since "constant awake mode" and "power save polling" are established industry terms and "sleep policy" is a google-invented term, i kind of think google ought to change "sleep policy" to "switching policy" or something. especially since the term is buried deep in an advanced settings menu.
this issue is about the power save mode, *not* the sleep policy. i think we'd better keep them separate or it will be harder for the developers to work these issues.
the wifi sleep policy is *different* from the wifi power saving mode. in android, "sleep" for the wifi means to turn it completely off.
the wifi sleep policy governs when the phone should switch between wifi and mobile data. the power saving mode governs *how* the wifi device behaves while it's on.
i think the "constant awake mode" term is confusing people, since it refers to a power save mode. but since "constant awake mode" and "power save polling" are established industry terms and "sleep policy" is a google-invented term, i kind of think google ought to change "sleep policy" to "switching policy" or something. especially since the term is buried deep in an advanced settings menu.
this issue is about the power save mode, *not* the sleep policy. i think we'd better keep them separate or it will be harder for the developers to work these issues.
da...@gmail.com
st...@gmail.com
linking the android discussion:
http://www.google.com/support/forum/p/android/thread?tid=01a47ff5b0a92d52&hl=en
recapping the latest:
there's a legitimate bug that makes later-model nexus ones (the test is whether your mac address starts with 00) receive no data while in PSP mode. it's been patched now, and is available on the latest cyanogen nightly.
note though that this won't help people with buggy access points or people who want to use VoIP. i'm trying to direct people from the group to star this issue.
recapping the latest:
there's a legitimate bug that makes later-model nexus ones (the test is whether your mac address starts with 00) receive no data while in PSP mode. it's been patched now, and is available on the latest cyanogen nightly.
note though that this won't help people with buggy access points or people who want to use VoIP. i'm trying to direct people from the group to star this issue.
st...@gmail.com
so i was reading about http://en.wikipedia.org/wiki/IEEE_802.11e-2005#Automatic_power_save_delivery . it's apparently a replacement to PSP mode that seems to be designed with VoIP applications / devices in mind.
the system even provides a way for APSD for to be active for some applications and not others, by changing the ToS-or-DSCP-or-whatever field of outgoing data packets.
are there any real network engineers (not pretend ones like me) in the crowd who can speak about whether this is what we need, or whether it's already enabled and accessible somehow?
the system even provides a way for APSD for to be active for some applications and not others, by changing the ToS-or-DSCP-or-whatever field of outgoing data packets.
are there any real network engineers (not pretend ones like me) in the crowd who can speak about whether this is what we need, or whether it's already enabled and accessible somehow?
se...@gmail.com
The fix is in the MSM kernel tree now as well:
http://android.git.kernel.org/?p=kernel/msm.git;a=commitdiff;h=8097ca0f92819b977472381f46315de15633361c
I have a newer nexus one (got it just before they stopped selling) and my MAC address does not start with 00. It seems to work properly with the updated kernel module.
I have a newer nexus one (got it just before they stopped selling) and my MAC address does not start with 00. It seems to work properly with the updated kernel module.
mm...@gmail.com
This severely limits applications that utilize a 'push' paradigm such as instant messengers and third party mail clients. As soon as the screen goes dark on certain devices, connectivity disappears. No more instant updates. As soon as the device fails over to gprs, everything comes back (this could be 15-20min or not at all -- i haven't figured out a stable pattern yet). Please fix this!
si...@gmail.com
[Comment deleted]
si...@gmail.com
"A "CAM" (a.k.a. constant awake mode) type of WifiManager.WifiLock would allow apps that need uninterrupted low-latency to request it."
Does that mean WiFiLock when the screen turns off is PSP by default? That doesn't make a lot of sense, as even Market downloads fail when the screen turns off - you'd think someone would have caught that...?
So basically, the only reason market downloads work when the screen is off on most devices is that the device manufacturers have tweaked the software on their own devices to make it work? WITHOUT contributing that knowledge back to Android?! :(
Does that mean WiFiLock when the screen turns off is PSP by default? That doesn't make a lot of sense, as even Market downloads fail when the screen turns off - you'd think someone would have caught that...?
So basically, the only reason market downloads work when the screen is off on most devices is that the device manufacturers have tweaked the software on their own devices to make it work? WITHOUT contributing that knowledge back to Android?! :(
bo...@gmail.com
When are they finally going to push an update out with this fix in it ...
Might need to move to cyanogen to get these sort of fixes without having to wait months
Might need to move to cyanogen to get these sort of fixes without having to wait months
si...@gmail.com
@Bond711
I've been talking to a few people on XDA-Developers about integrating the fix into Desire ROMs based on CyanogenMod (it's apparently really simple - yesterday a guy rewrote my bcm2439.ko module within like half an hour... all I had to do was replace the file via ADB in recovery and voila, CAM), but it seems like they actually WANT the WiFi to enter PSP mode when the screen is off.
Apparently it's not a bug, it's a feature.
So far I can confirm that power usage is higher: ~8mA idle vs. ~5mA in PSP mode. Translates to 175h of standby time instead of 250h...
However, since I use my phone as an actual smartphone and not just as a telephone, I need to be able to access the FTP and Wireless ADB servers while the screen is off... not to mention VoIP. SipDroid works fine with the screen off now, btw.
What we really need is a toggle switch for PSP vs. CAM in the Advanced Wireless Settings menu...
I've been talking to a few people on XDA-Developers about integrating the fix into Desire ROMs based on CyanogenMod (it's apparently really simple - yesterday a guy rewrote my bcm2439.ko module within like half an hour... all I had to do was replace the file via ADB in recovery and voila, CAM), but it seems like they actually WANT the WiFi to enter PSP mode when the screen is off.
Apparently it's not a bug, it's a feature.
So far I can confirm that power usage is higher: ~8mA idle vs. ~5mA in PSP mode. Translates to 175h of standby time instead of 250h...
However, since I use my phone as an actual smartphone and not just as a telephone, I need to be able to access the FTP and Wireless ADB servers while the screen is off... not to mention VoIP. SipDroid works fine with the screen off now, btw.
What we really need is a toggle switch for PSP vs. CAM in the Advanced Wireless Settings menu...
mw...@gmail.com
> What we really need is a toggle switch for PSP vs. CAM in the Advanced Wireless Settings menu...
Do you really want to have to keep going in there to toggle it? What if you receive a SIP call while it's set to PSP? Do you want to tell the caller to stand by while you go into Advanced Settings and switch to CAM?
I would think a better solution would be to have the WiFiLock keep the wireless interface in CAM as long as it's locked, regardless of whether the screen is on. If no apps are holding a WiFiLock, then the behavior should continue as it is now, switching to PSP to conserve power when the screen is off.
The devices that cannot receive any packets at all while in PSP mode are suffering from an entirely different bug, which should be fixed separately.
Do you really want to have to keep going in there to toggle it? What if you receive a SIP call while it's set to PSP? Do you want to tell the caller to stand by while you go into Advanced Settings and switch to CAM?
I would think a better solution would be to have the WiFiLock keep the wireless interface in CAM as long as it's locked, regardless of whether the screen is on. If no apps are holding a WiFiLock, then the behavior should continue as it is now, switching to PSP to conserve power when the screen is off.
The devices that cannot receive any packets at all while in PSP mode are suffering from an entirely different bug, which should be fixed separately.
si...@gmail.com
[Comment deleted]
si...@gmail.com
I wouldn't toggle it. I want to be able to set mine to CAM permanently, but other people might want PSP. Hence the toggle switch ;)
As is, you have to recompile your own wifi driver module to change the setting, see here:http://forum.xda-developers.com/showpost.php?p=8037062&postcount=44
Works fine, but will probably F up as soon as the kernel in the ROM changes, requiring a recompile... which sucks because I have no idea how to recompile it myself :(
Keeping the interface in CAM mode while WiFiLock is on would be a good alternative, of course. However, it'd have to switch to CAM mode from PSP as soon as certain connections are established. Say I've got an FTP server running in the background - when no clients are actively connected, PSP mode would be fine... but when a client connects, it should switch to CAM...
As is, you have to recompile your own wifi driver module to change the setting, see here:
Works fine, but will probably F up as soon as the kernel in the ROM changes, requiring a recompile... which sucks because I have no idea how to recompile it myself :(
Keeping the interface in CAM mode while WiFiLock is on would be a good alternative, of course. However, it'd have to switch to CAM mode from PSP as soon as certain connections are established. Say I've got an FTP server running in the background - when no clients are actively connected, PSP mode would be fine... but when a client connects, it should switch to CAM...
eg...@gmail.com
To comment 17, of course PSP mode is a feature, and a valuable one at that - it improves battery life while maintaining WiFi connectivity sufficient for *most* uses.
What is a "bug", or rather a "mis-feature" is that PSP mode is hardwired to screen sleep mode, and cannot be controlled separately from that.
We need a separate type of wake lock in the API, like "WIFI_CAM_LOCK", so that the applications that *really* need full-speed connectivity while the screen is dark (SIP UAs (only during the call), FTP/HTTP servers (only during data transfer)) can get this lock. Currently, such applications have to resort to obtaining a generic wake lock, that keeps the screen lit (and touch-sensitive, which is often rather undesirable).
As noted in comment 18, people who loose connectivity entirely have a different bug that should be reported and discussed as such.
What is a "bug", or rather a "mis-feature" is that PSP mode is hardwired to screen sleep mode, and cannot be controlled separately from that.
We need a separate type of wake lock in the API, like "WIFI_CAM_LOCK", so that the applications that *really* need full-speed connectivity while the screen is dark (SIP UAs (only during the call), FTP/HTTP servers (only during data transfer)) can get this lock. Currently, such applications have to resort to obtaining a generic wake lock, that keeps the screen lit (and touch-sensitive, which is often rather undesirable).
As noted in comment 18, people who loose connectivity entirely have a different bug that should be reported and discussed as such.
mw...@gmail.com
Ideally, the power saving mode of the Wi-Fi interface would be exposed through the public API as just another privileged method call. But achieving that would require the cooperation of the Google developers, and it seems like we haven't even gotten their attention yet.
si...@gmail.com
[Comment deleted]
si...@gmail.com
@egcrosser: That's a good way to look at it. Having apps be able to lock the WiFi into CAM mode at will would be great...
As for the devices that lose connectivity entirely in PSP mode (connected but unpingable): That's due to faulty custom ROMs and router settings, IMO. Had that on earlier versions of my ROM (OpenDesire), and it was fixed with kernel changes or something... Also, the dynamic power reduction settings on my router cause this problem too. Obviously it has nothing to do with this problem...
Continued testing with the CAM driver provides the following power consumption values:
2010/09/07 08:39:21 -10mA
2010/09/07 08:40:21 -4mA
2010/09/07 08:41:21 -5mA
2010/09/07 08:42:21 -9mA
2010/09/07 08:43:21 -5mA
2010/09/07 08:44:21 -5mA
2010/09/07 08:45:21 -17mA
2010/09/07 08:46:21 -5mA
2010/09/07 08:47:21 -5mA
2010/09/07 08:48:22 -4mA
2010/09/07 08:49:22 -5mA
2010/09/07 08:50:22 -5mA
2010/09/07 08:51:22 -5mA
2010/09/07 08:52:22 -34mA
2010/09/07 08:53:22 -4mA
2010/09/07 08:54:23 -8mA
2010/09/07 08:55:23 -5mA
2010/09/07 08:56:23 -5mA
That's actually BETTER than what I got with PSP. Never had dips to 4mA with PSP, and the average is lower too. Screw the toggle switch Google (or any complicated switching, for that matter), just make CAM permanent... PSP doesn't seem to save any power whatsoever.
As for the devices that lose connectivity entirely in PSP mode (connected but unpingable): That's due to faulty custom ROMs and router settings, IMO. Had that on earlier versions of my ROM (OpenDesire), and it was fixed with kernel changes or something... Also, the dynamic power reduction settings on my router cause this problem too. Obviously it has nothing to do with this problem...
Continued testing with the CAM driver provides the following power consumption values:
2010/09/07 08:39:21 -10mA
2010/09/07 08:40:21 -4mA
2010/09/07 08:41:21 -5mA
2010/09/07 08:42:21 -9mA
2010/09/07 08:43:21 -5mA
2010/09/07 08:44:21 -5mA
2010/09/07 08:45:21 -17mA
2010/09/07 08:46:21 -5mA
2010/09/07 08:47:21 -5mA
2010/09/07 08:48:22 -4mA
2010/09/07 08:49:22 -5mA
2010/09/07 08:50:22 -5mA
2010/09/07 08:51:22 -5mA
2010/09/07 08:52:22 -34mA
2010/09/07 08:53:22 -4mA
2010/09/07 08:54:23 -8mA
2010/09/07 08:55:23 -5mA
2010/09/07 08:56:23 -5mA
That's actually BETTER than what I got with PSP. Never had dips to 4mA with PSP, and the average is lower too. Screw the toggle switch Google (or any complicated switching, for that matter), just make CAM permanent... PSP doesn't seem to save any power whatsoever.
si...@gmail.com
Continued testing of drivers with permanent CAM mode (been using them permanently since my last post here) show no decreased battery life, even in long periods of standby, in which differences should show most drastically.
Losing about 1% per hour over night with Sipdroid, Locale,imo.im (IM client) and DroidVNC Server running and connected (where applicable) - same as with the PSP driver.
If any of you are still having trouble, I'd recommend taking a look at patching the source for your bcm4329.ko module (I linked to the XDA-Dev thread with all the info a few posts up) until Google comes up with a permanent patch.
Losing about 1% per hour over night with Sipdroid, Locale,
If any of you are still having trouble, I'd recommend taking a look at patching the source for your bcm4329.ko module (I linked to the XDA-Dev thread with all the info a few posts up) until Google comes up with a permanent patch.
ja...@gmail.com
Can anyone point me on how to compile a bcm4329.ko for the stock kernel with the CAM mode modification? Or at least a link on a modified one?
si...@gmail.com
See
pl...@gmail.com
[Comment deleted]
pl...@gmail.com
This issue seems to be somehow improved on update 2.2.1 for Nexus One.
Before this update my phone uses to completely stop responding to WIFI ping request as soon as he entered PSP mode (Wend the screen shut down).
Now with 2.2.1, it responds to most of my ping requests with the screen off. However, the latency is slower and if I use VoIP apps like Sipdroid with my screen off, most of the ping get unanswered (2 out of 10, mostly) and the VoIP conversation gets really badly choppy...
It’s like if wend the phone enter PSP mode, overall performance is decreases and even if he is still being used and having a hard time working properly, he won’t leave PSP mode.
All that being said, it’s still a really good update and they definitely improved the PSP Mode, witch work mush better for me.
Send me your feedbacks if you guys try this update.
Thanks for this update Google. =)
Greeting form Montreal, Canada.
You can follow the manual update procedure on the link below or you can wait for the OTA update.
Manual update procedure:http://www.androidcentral.com/nexus-one-update-android-221
Warring: follow the update step carefully; I am now responsible for any issue you may encounter during update and after. Some keyboard app are experiencing issues with this new update.
Before this update my phone uses to completely stop responding to WIFI ping request as soon as he entered PSP mode (Wend the screen shut down).
Now with 2.2.1, it responds to most of my ping requests with the screen off. However, the latency is slower and if I use VoIP apps like Sipdroid with my screen off, most of the ping get unanswered (2 out of 10, mostly) and the VoIP conversation gets really badly choppy...
It’s like if wend the phone enter PSP mode, overall performance is decreases and even if he is still being used and having a hard time working properly, he won’t leave PSP mode.
All that being said, it’s still a really good update and they definitely improved the PSP Mode, witch work mush better for me.
Send me your feedbacks if you guys try this update.
Thanks for this update Google. =)
Greeting form Montreal, Canada.
You can follow the manual update procedure on the link below or you can wait for the OTA update.
Manual update procedure:
Warring: follow the update step carefully; I am now responsible for any issue you may encounter during update and after. Some keyboard app are experiencing issues with this new update.
go...@gmail.com
This is still a problem for the HTC Evo with the latest October 2010 OTA update of Android 2.2. This is a huge problem for VOIP apps. Please fix.
js...@gmail.com
This report is a duplicate of, or related to, issues 1052, 1124, 1698, 6269, 7421, 2718, ... It looks like >>500 votes have been cast to fix WiFi problems, but the votes are divided among many issues. Add your vote to 1698!
r3...@gmail.com
All,
I think that android 2.3 will allow developers to workaround this problem.
I'm the author of a SIP application (CSipSimple - search on googlecode ;) ).
And reading the source of the Android 2.3 SIP stock application I noticed that they use a new type of wifi lock ....
It's : WifiManager.WIFI_MODE_FULL_HIGH_PERF (int 3).
I introduced that in my code and ask to Nexus S owners (Nexus S has PSP mode) to test. According to feedback from users it works !! No more PSP when screen goes of if I change my wifi lock from MODE_FULL to MODE_FULL_HIGH_PREF.
So my question to google and API maintainers :
Would you mind adding this lock mode to the official API ??!!
You need that for your voip app and think other application will not need that??
Besides if you do not document that we will have other device with android 2.3 and that will not support this wifi lock mode.
So you *MUST* add that to the official API. (Well we can get rid of that and simply add int 3 to our lock provided the fact it's api >=9 but... what's wrong with documenting that?
If you do not I fear that we will have some manufacturer that will not take that into account. And it will break the stock SIP application too...
It's just an update of the API, so pretty easy for you to do and I think that it will save a lot of future problems... for the stock SIP app and for all other sip application.
At least could you reassure us by saying that I'm right and that this wifi lock mode is intended to avoid PSP mode?
I think that android 2.3 will allow developers to workaround this problem.
I'm the author of a SIP application (CSipSimple - search on googlecode ;) ).
And reading the source of the Android 2.3 SIP stock application I noticed that they use a new type of wifi lock ....
It's : WifiManager.WIFI_MODE_FULL_HIGH_PERF (int 3).
I introduced that in my code and ask to Nexus S owners (Nexus S has PSP mode) to test. According to feedback from users it works !! No more PSP when screen goes of if I change my wifi lock from MODE_FULL to MODE_FULL_HIGH_PREF.
So my question to google and API maintainers :
Would you mind adding this lock mode to the official API ??!!
You need that for your voip app and think other application will not need that??
Besides if you do not document that we will have other device with android 2.3 and that will not support this wifi lock mode.
So you *MUST* add that to the official API. (Well we can get rid of that and simply add int 3 to our lock provided the fact it's api >=9 but... what's wrong with documenting that?
If you do not I fear that we will have some manufacturer that will not take that into account. And it will break the stock SIP application too...
It's just an update of the API, so pretty easy for you to do and I think that it will save a lot of future problems... for the stock SIP app and for all other sip application.
At least could you reassure us by saying that I'm right and that this wifi lock mode is intended to avoid PSP mode?
m-...@hotmail.com
Problems when using wifi related programs.
st...@gmail.com
I can confirm that on the stock 2.3.3 rom on my Nexus One, I can use native SIP calling over wifi with the screen off, with no loss of quality.
If WifiManager.WIFI_MODE_FULL_HIGH_PERF is part of the official API, I think this bug can be closed. However, I don't see it in the reference documentation athttp://developer.android.com/reference/android/net/wifi/WifiManager.html yet. Can Google add this please, or otherwise finalize their solution?
If WifiManager.WIFI_MODE_FULL_HIGH_PERF is part of the official API, I think this bug can be closed. However, I don't see it in the reference documentation at
si...@gmail.com
@r3gis:
Does CSipSimple provide some way to use apbxes.org account in hybrid TCP/UDP mode? With Sipdroid configured for TCP, I get 4-6mA of battery drain in standby on my Desire both on WiFi and on 3G, which is practically nothing. CSIPSimple kicks that up to 40mA (~8x as high!) because UDP is required to connect to pbxes.org .
If you have implemented MODE_FULL_HIGH_PREF, that would be a reason to switch...
Does CSipSimple provide some way to use a
If you have implemented MODE_FULL_HIGH_PREF, that would be a reason to switch...
r3...@gmail.com
@simonbro : probably not the right place ;)
Read and continue the discussion here :http://code.google.com/p/csipsimple/issues/detail?id=604&q=pbxes (but the csipsimple battery life has been improved in latest dev version ;) ... but well I don't want to spam here ;) )
@steven & all : I also confirm that the FULL_HIGH_PERF lock works on :
* Nexus S - stock ROM
* Nexus One - stock ROM
* Cyanogen ROMs (Cynagen's devs are aware about that and made the work to get it working properly AFAIK).
So, as I said previously, if somebody that has direct rights to enrich the SDK read that, it's really worth adding this tag to the SDK doc and to the SDK.
If needed I can propose a patch to the android git, should I?
At least we (as developers) need a clear position on this point. It could be acceptable to have this as a "private API". But if so, can you say it clearly so that we do what required in our apps to activate it only if we know it will be supported. (Basically I think that if stock SIP app is there, it mean that the feature is available and working too, else stock SIP app will also encounter the problem).
Read and continue the discussion here :
@steven & all : I also confirm that the FULL_HIGH_PERF lock works on :
* Nexus S - stock ROM
* Nexus One - stock ROM
* Cyanogen ROMs (Cynagen's devs are aware about that and made the work to get it working properly AFAIK).
So, as I said previously, if somebody that has direct rights to enrich the SDK read that, it's really worth adding this tag to the SDK doc and to the SDK.
If needed I can propose a patch to the android git, should I?
At least we (as developers) need a clear position on this point. It could be acceptable to have this as a "private API". But if so, can you say it clearly so that we do what required in our apps to activate it only if we know it will be supported. (Basically I think that if stock SIP app is there, it mean that the feature is available and working too, else stock SIP app will also encounter the problem).
st...@gmail.com
Reiterating: while realtime apps like SIP/Skype/Fring/etc are the most affected by this, it potentially affects any app where network performance is an issue, such as StreamFurious, AndFTP, etc.
Users interpret this problem as "this app sucks, it makes me drain my battery." App developers interpret this as "android makes my users think my app sucks, and I can't fix it." A solid resolution is needed here.
Users interpret this problem as "this app sucks, it makes me drain my battery." App developers interpret this as "android makes my users think my app sucks, and I can't fix it." A solid resolution is needed here.
si...@gmail.com
This is what incoming audio on Sipdroid sounds like when the screen goes off on my Desire with pm_max (PSP when screen off):
http://www.multiupload.com/N917I147PW
:(
@r3gis: Thanks for the link, still trying to get it to work wit pbxes. Is FULL_HIGH_PERF implemented on your latest nightlies?
BTW, I'd say this is the right place for (publicly, so that others affected by the problem can read about it) discussing workarounds ;)
:(
@r3gis: Thanks for the link, still trying to get it to work wit pbxes. Is FULL_HIGH_PERF implemented on your latest nightlies?
BTW, I'd say this is the right place for (publicly, so that others affected by the problem can read about it) discussing workarounds ;)
pa...@gmail.com
This is not fixed. WIFI_MODE_FULL_HIGH_PERF keeps the driver in a high power using state. A *real* fix is for the PM_MAX power mode in the bcm4329 kernel to work correctly (ie, not disconnect).
The rumor is that chips with MAC addresses beginning with 38:E7 have the problem that when they enter PM_MAX state, they will eventually disconnect (ie, drop all packets). Whereas devices with a MAC beginning with 00:23 behave correctly in PM_MAX mode, ie, they receive all packets but with high latency (this is the CORRECT behavior). I want my device to enter power saving mode when the screen is off, so I dont care if latency increases, i just do NOT want a complete disconnect (which is what i get).
Now, it is true that during a VOIP call, and the screen goes off, you do NOT want the wifi to enter PM_MAX mode as the latency will ruin the call, so that's where the WIFI_MODE_FULL_HIGH_PREF lock comes in handy as it will prevent the driver from entering PM_MAX mode.
On the other hand, if all you want to do is REMAIN connected/registered to a sip server, then you need a driver that is not going to disconnect when the screen goes off.
Google needs to fix this ASAP.
The rumor is that chips with MAC addresses beginning with 38:E7 have the problem that when they enter PM_MAX state, they will eventually disconnect (ie, drop all packets). Whereas devices with a MAC beginning with 00:23 behave correctly in PM_MAX mode, ie, they receive all packets but with high latency (this is the CORRECT behavior). I want my device to enter power saving mode when the screen is off, so I dont care if latency increases, i just do NOT want a complete disconnect (which is what i get).
Now, it is true that during a VOIP call, and the screen goes off, you do NOT want the wifi to enter PM_MAX mode as the latency will ruin the call, so that's where the WIFI_MODE_FULL_HIGH_PREF lock comes in handy as it will prevent the driver from entering PM_MAX mode.
On the other hand, if all you want to do is REMAIN connected/registered to a sip server, then you need a driver that is not going to disconnect when the screen goes off.
Google needs to fix this ASAP.
st...@gmail.com
"Wifi always enters PSP/PM_MAX when screen off" != "PSP/PM_MAX is broken". @comment 39, you should file a separate bug, especially if you have experience with it (I have a 00:23 device myself).
Engineers can only solve problems if you describe them in specific detail with reproducible steps. If you want things to get done, don't cross-post and don't cite rumors.
Wifi problems are especially tricky for the engineers; this buglist is already full of poorly-specified "wifi doesn't work" bugs that are actually a dozen different issues.
Engineers can only solve problems if you describe them in specific detail with reproducible steps. If you want things to get done, don't cross-post and don't cite rumors.
Wifi problems are especially tricky for the engineers; this buglist is already full of poorly-specified "wifi doesn't work" bugs that are actually a dozen different issues.
pa...@gmail.com
I agree that it's not a bug that wifi enters PSP/PM_MAX when screen goes off, in fact i think it's the desired behavior. What the bug is, is that in PSP/PM_MAX, the wifi will eventually completely disconnect (unpingable), until the screen is turned back on.
THAT is the bug.
THAT is the bug.
st...@gmail.com
May be a bug (I can't confirm), but it's not this bug. You should file a new one.
pa...@gmail.com
You are possibly correct. I opened this bug which details the problem of the wifi DISCONNECTING while in powersave/sleep mode:
http://code.google.com/p/android/issues/detail?id=15542
Anyone who has this problem please star this bug.
Anyone who has this problem please star this bug.
si...@gmail.com
AFAIr the issue you are describing (actual DISCONNECTS when the screen is off, even with WiFi sleep policy set to "Never") is limited to certain devices in the N1/Bravo series... hence why only certain MAC addresses are affected.
The problems described here affect ALL Nexus One and Desire devices and pretty much any others that use the same WiFi chip (BCM4329 IIRC)... Steven is absolutely right in classifying your problem as a completely different bug.
The problems described here affect ALL Nexus One and Desire devices and pretty much any others that use the same WiFi chip (BCM4329 IIRC)... Steven is absolutely right in classifying your problem as a completely different bug.
pa...@gmail.com
That's not entirely true. Many many android devices use the bcm4329 wifi chip, including my phone (Evo). Some bcm4329 chips have a MAC start with 38:e7, others start with 00:23. The rumor is that the 38:e7 chips have a problem that when they enter powersave state (PM_MAX), they eventually completely disconnect from wifi. Whereas the 00:23 chips do not have that problem. The *correct* behavior is for the wifi to enter powersave state when the device sleeps. This low power state does indeed result in high latency and low bandwidth. From what I can tell, a new type of wifi lock (WIFI_MODE_FULL_HIGH_PERF) has been created in Android 2.3 that deals with this. If an app holds such a lock, the wifi will never enter powersave state. Thus it seems that *this* bug is most likely resolved.
st...@gmail.com
IMHO *this* bug is still pending official documentation of WIFI_MODE_FULL_HIGH_PERF, so it's clear non-Google apps can take advantage of it. The underlying technical issue is fixed but this doesn't equal resolution.
You should save your discussion of the 38:e7 problem for your new bug.
And again, don't cite "the rumor is". My crazy uncle won't eat off of metal silverware because "the rumor is" it's poisonous. Folks will only take you seriously if you cite facts, or at least statistics. Don't be the crazy uncle.
You should save your discussion of the 38:e7 problem for your new bug.
And again, don't cite "the rumor is". My crazy uncle won't eat off of metal silverware because "the rumor is" it's poisonous. Folks will only take you seriously if you cite facts, or at least statistics. Don't be the crazy uncle.
r3...@gmail.com
As for this bug there is still one remaining open points :
* Add this flag to the SDK !
It will ensure that the feature is available on android. If it's not done, nobody can cry against a manufacturer that do not implement it and that would be a shame for the stock SIP app but for all others apps that plenty of hope use this private API.
As far as I can tell, I never get any feedback from any existing 2.3 or upper that do not support it correctly. (@simon : yes full_perfs mode is already included in nightly builds ;) ).
But I really fear that if it's not in the API and if there is not some unit tests for that feature it will be forgot by some manufacturer.
* Add this flag to the SDK !
It will ensure that the feature is available on android. If it's not done, nobody can cry against a manufacturer that do not implement it and that would be a shame for the stock SIP app but for all others apps that plenty of hope use this private API.
As far as I can tell, I never get any feedback from any existing 2.3 or upper that do not support it correctly. (@simon : yes full_perfs mode is already included in nightly builds ;) ).
But I really fear that if it's not in the API and if there is not some unit tests for that feature it will be forgot by some manufacturer.
si...@gmail.com
@Paul: Please read what you're replying to more thoroughly. We're already in agreement...
@Regis: With WIFI_MODE_FULL_HIGH_PERF activated and included in the ROM, it's still up to the app developer to make use of it, right? I.e. regular old CSipsimple or Sipdroid wouldn't benefit from this?
@Regis: With WIFI_MODE_FULL_HIGH_PERF activated and included in the ROM, it's still up to the app developer to make use of it, right? I.e. regular old CSipsimple or Sipdroid wouldn't benefit from this?
st...@gmail.com
To avoid confusion, I created http://code.google.com/p/android/issues/detail?id=15549 , which is specifically about adding WIFI_MODE_FULL_HIGH_PERF to the official sdk.
r3...@gmail.com
@simon : CSipsimple version of the android market already has it provided the fact you disable manually the PSP workaround.
Actually since I was really aware about this issue and that I read the android source code of the official SIP app, I was able to included it very fast to the source code. So the market version and devs version has it working. (Devs version just do the correct configuration for you since now I'm almost sure that it is the correct way to workaround the PSP behavior).
But yes indeed, all other apps should also use this mode to lock wifi instead of the previous mode_full if android sdk >= 9. Obviously this apps should already have a lock so changing 2 to 3 if sdk>8 should be easy to do ;). However, til this is not in the SDK it should be used carefully and be aware of the fact on some device it may not work. As consequence I'd advise developers to wrap it - and maybe add a "Hack" option somewhere (hidden from mainstream users).
@steven : ok cool for the new bug :).
I hope that will make android sdk maintainers focusing on this task.
// I didn't read your comment 46 before posting 47 ;) and as you guess I completely agree with you. :)
Actually since I was really aware about this issue and that I read the android source code of the official SIP app, I was able to included it very fast to the source code. So the market version and devs version has it working. (Devs version just do the correct configuration for you since now I'm almost sure that it is the correct way to workaround the PSP behavior).
But yes indeed, all other apps should also use this mode to lock wifi instead of the previous mode_full if android sdk >= 9. Obviously this apps should already have a lock so changing 2 to 3 if sdk>8 should be easy to do ;). However, til this is not in the SDK it should be used carefully and be aware of the fact on some device it may not work. As consequence I'd advise developers to wrap it - and maybe add a "Hack" option somewhere (hidden from mainstream users).
@steven : ok cool for the new bug :).
I hope that will make android sdk maintainers focusing on this task.
// I didn't read your comment 46 before posting 47 ;) and as you guess I completely agree with you. :)
pa...@gmail.com
Apparently this bug might have a lot to do with which bcm4329 firmware you're using. Broadcom has their own AOSP (binary blob) firmware here:
http://android.git.kernel.org/?p=platform/system/wlan/broadcom.git;a=tree;f=bcm4329/firmware;h=272c922044b3eb4b98466d5f65e8c340d90a7418;hb=HEAD
But apparently HTC also has their own bcm4329 firmware. According to a developer named Zinx, the Broadcom firmware does not support 5GHz (which the Evo can't do anyway due to lack of proper antenna), but it also does not have the problem of the wifi dying when the phone sleeps. I have just replaced the firmware that came with cm7/supersonic with the Broadcom AOSP firmware and will test all day today and post back the results.
But apparently HTC also has their own bcm4329 firmware. According to a developer named Zinx, the Broadcom firmware does not support 5GHz (which the Evo can't do anyway due to lack of proper antenna), but it also does not have the problem of the wifi dying when the phone sleeps. I have just replaced the firmware that came with cm7/supersonic with the Broadcom AOSP firmware and will test all day today and post back the results.
st...@gmail.com
to anyone still watching this issue looking for answers: i've been able to directly confirm that some access points simply do not work with android's PSP mode (others may have confirmed this on their own, but not in this thread yet).
i tested the same phone in PSP mode on two different access points. on one (ubiquiti routerstation pro + ubiquiti xr2 + openwrt), packets were simply delayed. on the other (ubiquiti nanostation loco m2), packets were dropped entirely, and the phone would disconnect from wifi after a minute or two.
to users: if wifi totally dies when the screen turns off and you have the sleep policy set to "never", it might be the access point's fault. try a new one if you can. based on previous experience, i recommend you avoid netgear.
to google: users need a way around bad access points. there are apparently a lot of them ...
i tested the same phone in PSP mode on two different access points. on one (ubiquiti routerstation pro + ubiquiti xr2 + openwrt), packets were simply delayed. on the other (ubiquiti nanostation loco m2), packets were dropped entirely, and the phone would disconnect from wifi after a minute or two.
to users: if wifi totally dies when the screen turns off and you have the sleep policy set to "never", it might be the access point's fault. try a new one if you can. based on previous experience, i recommend you avoid netgear.
to google: users need a way around bad access points. there are apparently a lot of them ...
ca...@gmail.com
Confirmed on my home network, which is based around one of the cheapest routers around (also one of the least power-hungry ones), and when using connectify. Not being able to keep a connection is quite a severe bug.
mo...@gmail.com
Issue confirmed on Motorola Droid 2 (A955) with Android 2.3.4 (latest build).
Also saw this issue on my old phone, a Motorola Droid (A855) with 2.2.x.
Also saw this issue on my old phone, a Motorola Droid (A855) with 2.2.x.
si...@gmail.com
Hi guys, the workaround posted in
Sipdroid now works just fine with the screen off.
Sipdroid now works just fine with the screen off.
st...@gmail.com
Given that WifiManager.WIFI_MODE_FULL_HIGH_PERF is now present in the official android SDK docs, I (as original poster) consider this bug closed.
nb...@gmail.com
[Comment deleted]
nb...@gmail.com
[Comment deleted]
nb...@gmail.com
When my screen is on and unlocked I can ping to my device at 1ms-215ms. I receive an average of 89ms after 50 iterations. With the screen off, I receive 19ms-990ms.There is no packet loss, but the average is 400ms.
I'm using a Galaxy Nexus with 4.1.1 paranoid android (I had the same issue on stock) and my router is a Buffalo WZR-HP-G300NH running DD-WRT build 19519. This issue seems to be affecting the native sip function, because I can't receive calls when the screen is off for more than 10 minutes (roughly).
I do not have this issue with sipdroid, but I'd rather use the native sip client. It sounds better using g711u and there is no lag when pressing DTMF tones -- an issue I have with most android softphones.
I'm using a Galaxy Nexus with 4.1.1 paranoid android (I had the same issue on stock) and my router is a Buffalo WZR-HP-G300NH running DD-WRT build 19519. This issue seems to be affecting the native sip function, because I can't receive calls when the screen is off for more than 10 minutes (roughly).
I do not have this issue with sipdroid, but I'd rather use the native sip client. It sounds better using g711u and there is no lag when pressing DTMF tones -- an issue I have with most android softphones.
ca...@gmail.com
@nb1309
That sounds more like a radio bug than anything else. Try updating your radio to a later version, and try again.
That sounds more like a radio bug than anything else. Try updating your radio to a later version, and try again.
nb...@gmail.com
@59 I'm on XXLF1, the latest Jelly Bean radio. I'm going to flash a different radio, and report back. Thanks for the insight.
jb...@android.com
[Comment deleted]
Description
PSP mode apparently causes the wifi device to sleep, but wake up periodically and ask its access point to deliver packets that were addressed to to the device while it was asleep. This necessarily causes additional, "spiky" network latency. This additional latency means that some network-oriented applications experience problems when the screen turns off.
Most notably, Internet telephony apps simply cannot make a call over wifi with the screen off. As soon as the screen goes off, the call becomes heavily garbled or mute in both directions. Here's the associated bug on Sipdroid:
Sipdroid has kludged a solution for this problem by forcing the screen to be on while a wifi call is in progress. Fring may do the same, but I do not use Fring enough to know. The best that any Internet telephony app could ever do in this situation is use a large buffer to smooth out the audio, but the resulting delay would always be similar to calling China from the United States.
This also seems to cause problems with:
* live-source streaming audio (apps such as StreamFurious)
* bulk data transfer rates (FTP)
* potentially any app not designed for its connection quality to suddenly and dramatically change
* potentially any app, if the access point drops any packets from its queue or is otherwise not-perfectly-behaved
There are a number of issues in Android's queue already that seem to be the same or related to this issue:
From what I've read, this seems to affect HTC phones mainly (maybe only).
I also wonder if it couldn't be causing more nefarious issues than network latency. Intel has the idea that some access points simply don't play well with PSP mode:
In terms of solutions:
A "CAM" (a.k.a. constant awake mode) type of WifiManager.WifiLock would allow apps that need uninterrupted low-latency to request it.
An option to disable PSP mode might help some users diagnose their wifi problems.