[Samsung Galaxy Nexus] coolbho3000:
Okay, let me step in again and say that the people who are saying "bull**** on software fix" either don't know what they're talking about or aren't thinking hard enough. From what I understand, this problem is entirely fixable at either the kernel level or the firmware level. I posted that I would attempt a fix today when I get my Galaxy Nexus, but it looks like Google already has it handled.

To me, this seems like hardware issue that can be compensated for completely in software.

I don't have my Galaxy Nexus yet, but from what I gather from logs posted earlier as well as this video: http://www.youtube.com/watch?v=Rp-N352hwZY, the issue is that 900MHz interference makes the volume down button oscillate between on and off so quickly that it overflows the buffer for the keypad device. This is the key here. Such a thing would NEVER happen in normal usage - there's no way a human could possibly press the button quickly enough.

From the video, we can see that when the bug happens, the volume pretty much immediately jumps from maximum to minimum. We all know that if you hold the volume down button in Android, it doesn't decrease nearly that quickly (it lowers one level immediately and then gradually lowers the volume for as long as the button is held). So a 900MHz signal does not hold down the button. It just presses it (and releases it) really, really quickly.

The 900MHz signal never seems to hold the button for longer than tiny fractions of a second. A human wanting to change the volume would always hold the button down for at least many times that rate. So now we know the difference between the 900MHz signal and a human pressing the button - the 900MHz signal never holds the button for any significant period of time.

So how do we fix it? See source file: https://www.codeaurora.org/gitweb/q...fc70774;hb=aosp-new/android-omap-tuna-3.0-mr0

Pressing the button or releasing the button causes a hardware interrupt which calls omap4_keypad_interrupt(). An example fix (there's probably a better/more low level way to do this - this would just be a quick fix): All we'd have to do is add the following logic to omap4_keypad_interrupt():

- If we get an interrupt for volume down pressed, do not register it yet.

- In 100 milliseconds, volume down is still pressed, register the key press. If not, ignore it.

- If we got another interrupt for volume down in the meantime (volume down pressed or volume down released), ignore it even if it's pressed.

This would, more likely than not, fix the issue, or mitigate it so much that the interference becomes negligible.

Yes, it's a workaround, but workarounds like this happen all the time. Hardware is limited by the laws of physics, but that doesn't mean software can't compensate for it. The procedure is very similar to "debouncing." See: http://en.wikipedia.org/wiki/Debounce#Contact_bounce. This wouldn't fix the issue in the bootloader - you would need to have the above logic implemented in the keypad driver there, or just fix it in firmware.

DO NOT return your phones yet. There is no reason not to believe Google. I'll still look into writing a proof of concept fix, but as it stands, I live in the US where I can't easily get a 900MHz GSM signal (and I don't have easy access to baby monitors/portable radios or 900MHz cordless telephones).