23
Nov
image_thumb161

There's been quite a stir caused in the past few days about a mysterious volume bug which surfaced on the Galaxy Nexus. The bug began drawing attention over at XDA's forums, where several users reported ostensibly random muting, and erratic response from the Nexus' volume rocker.

It was quickly discovered that the issue seemed to have something to do with the use of 2G signal, specifically the use of a 900 MHz frequency used by many European carriers. The bug could also be replicated using other phones situated near the Galaxy Nexus, leading to concerns that perhaps the bug was hardware-related. The issue also gained attention at Google's bug tracker site for Android, perhaps prompting Google's swift response.

After reaching out to Android PR, we got a promising response:

We are aware of the volume issue and have developed a fix. We will update devices as soon as possible.

There's no word yet on when the fix will be available, but it's good to know that the issue is not hardware-related, and that Google has already been working on a patch.

With a fix on the way and no need for recall or hardware fixes, there's relatively little for Galaxy Nexus users to worry about, as long as they can bear the frustration of erratic volume controls, or avoid using 900 MHz 2G signal until the update officially rolls out.

Update: Slashgear reports that Samsung has halted shipments of the Galaxy Nexus to retailers, and stock will not start rolling again until the volume issue is resolved. Samsung also acknowledged the issue on Twitter, echoing Google's statement verbatim.

The fact that Samsung has halted shipments tells me that perhaps the manufacturer wants to wait and make sure the issue can be fully resolved via software update, meaning there's an ever so slight possibility that a hardware fix may be necessary (especially considering reports of the bug being replicated in bootloader mode). It looks like this story is still developing, so we'll be sure to keep reporting on details as they roll in.

Update 2: Dan Morrill, a noted Android engineer, has not only confirmed once and for all that the volume bug can be fixed by a software update, but also linked to a rather eloquent explanation, courtesy of Google+ member Lee Johnston.

Lee explains that the problem is hardware-related only in that the interference is coming through the radio hardware. That being said, the problem can easily be fixed by adjusting something called debounce, a software function which essentially interprets the "flutter" caused by pressing a button (or likewise interference) as either a fluke or a legitimate input, based on duration of the "press." Upping the Nexus' volume rocker debounce threshold to the average button-tap range of 100-200ms should fix the problem, and Morrill hints that this is exactly what Google plans on doing. You can view Morrill's post on Google+ here.

Liam Spradlin
Liam loves Android, design, user experience, and travel. He doesn't love ill-proportioned letter forms, advertisements made entirely of stock photography, and writing biographical snippets.

  • http://greghesp.com Greg

    Rubbish. If it was a software issue it wouldn't happen in the bootloader, but it does

    • http://www.AndroidPolice.com Artem Russakovskii

      Google said it's in software. Perhaps they will go as low as the radio to fix it.

      • Telanis

        I would be surprised if it was truly a software issue, but it's perfectly feasible that the software fix compensates for a hardware deficiency. Either way, if it's fixed it's fixed :)

    • chomp

      They never said it was a software issue but a fix can be implemented via software, I read someone's post today saying they could either set a minimum hold time of the rocker to adjust volume which would fix it as the volume changes rapidly or, they could make the volume rocker only activate the on-screen volume animation which would then have to be changed by the touch screen eg sliding it, the first fix is a lot more likely as it keeps the "rocker" functionality

    • http://villainrom.co.uk Fysi

      Because a software update can't fix this issue <.<

      It will more than likely be a firmware update that is below the bootloader.

    • Stakker

      Wrong. If it is a driver-related bug it would happen in the bootloader too.
      I'm positive that the faulty driver will be patched in the next update.

    • level380

      I say Rubbish to you.... Think a little harder about how this fault comes about..... The problem has been tracked down to when your on 2g only and even then you have to be on the 900mhz freq, So it sounds like a baseband firmware issue could be at fault and google can drop out a new baseband firmware OTA to correct the issue.

      It most likely wasn't picked up during testing as those areas didn't use 2g @ 900mhz!

    • GergS

      Why couldn't it be a radio software issue?

  • Fred

    They are not really going to admit to a hardware issue until they really have to are they? Would be instant recall and nightmare for therm.

    Let them tell us what the software issue was then and how if caused the effect it did. Any software update is more then likely some find of frig to mask the the issue. Something like; "where volume press events are received in rapid succession, ignore them" This will only be a band-aid fix and not good enough.

    They need to give us the details now.

    • Randolph

      "This will only be a band-aid fix and not good enough."

      Not good enough for who, or what? If it solves the problem and doesn't have any side effects, then it should be good enough for anyone.

      Most other software and hardware solutions beyond basic complexity are an exercise in balancing competing effects and signals, especially when dealing with RF issues.

    • Rocky T

      Fred sex: "This will only be a band-aid fix and not good enough."

      Then don't buy it. And if you have, then return it. I just fixed your phantom volume problem. No charge.

  • jeremy

    REALLY?.............
    can this REALLY be the software~?

    • level380

      baseband firmware controls the radio.... the fault only appears when the radio is on 2g @ 900mhz.....

      So REALLY this could be a baseband fault, which is software and can be fixed OTA

      • Paul

        It seems though that updating the Radio firmware somehow 'may' fix it on that phone, but tests already show that another nearby phone broadcasting at 900mhz can also upset the rocker. It seems Samsung didn't properly isolate or shield the board properly against outside interference. This fix Google is talking about would have to be baseband-radio-firmware + software, ie "setting a minimum hold time of the rocker to adjust volume". This way the baseband/radio firmware will fix the erratic behavior of the switch, but in case of 900mhz interference, like from another phone, the software (Android 4.0) has the ability to compensate. But it is looking like a Samsung/Hardware issue but one that can be compensated with firmware and software. In reality, the volume rocker should never have been affected by 900mhz signals. Another phone nearby and the Galaxy Nexus being in the boot loader, and the problem is seen.

  • Rob

    If they're as helpful on the bug fix as they are about the Nexus US release date....DON'T EXPECT MUCH!

  • http://www.simonbrettellphotography.co.uk Simon

    This sounds like an EMC (Electro Magnetic Compatibility) fault to me and probably rooted in a hardware issue / design fault. As highlighted by Fred above, they can apply a "fix" which will not really cure the root cause of the problem but merely mask the symptoms.

    However, it's worth noting that the software filtering that would need to be applied may be a required / standard feature. It may be the case that the filtering was forgotten or incorrectly implemented in the original software release.

  • DragonD

    The problem seems to be caused by radio interference that somehow is interpreted as volume keys being pressed. But remember that EVERYTHING in a smartphone is software. There is no such thing as a physical direct line between a button and a function. Key-presses (and interference interpreted as key-presses) are handled by driver software that decides what to do. It is very likely that the hardware drivers can be updated to filter out the interference.

  • http://talk3g.co.uk Hands0n

    It is good that Google have spoken up, and shame on Samsung for their tight-lipped attitude to its customers.

    As long as the fault is found and fixed I could care less. This is what software is all about. Although it does bring into question how the device was tested before release.

    Perhaps Samsung/Google should draw on the blogging community to Beta test their stuff when it gets to final release, just before committing to a full release. We always find the bugs that the producers do not. There's a message in there!

    • Adam

      True but there will always be bugs. There's (obviously) no such thing as the perfect OS, so they'd never get it out to the public if they did something like that. It'd just be a never ending process of fixing bugs =\

  • Teovald

    what a nerd-rage tempest !
    I ordered my GN yesterday and i don't really care about that bug.
    Yes, early adopters encounter more bugs than casual users, you can not detect all problems your product have, sooner or later a buggy product will reach customers, and early-adopter are more likely to encounters these, since they buy the product as soon as it is available.
    But i don't think this particuliar bug deserves such attention.

  • http://www.komorkomania.pl Andrzej W.

    if it is happenig in bootloader mode (which means way BEFORE Android starts) it can't be software bug of Android OS

    it is hardware bug, where volume buttons circuit is not shielded or decoupled enough (probably some Samsung accountant forced engineers to save few cents on removeing decoupling capacitors)

    their so called "fix" will probably force OS/CPU to ignore most of signals on volume buttons GPIOs, if they will occur to fast/frequent (comparing to human hand speed)

    except that these volume buttons will be much less responsive from user point of view (there will be some delay, when OS will start to react for it), CPU/OS will be still busy for servicing fake signals and it will eat battery much more

    this is deal breaker for me, and I will hold with purchase till there will be next batch/revision (probably 2012)

    SAMSUNG SHAME ON YOU!!!

    • level380

      baseband firmware controls the radio.... the fault only appears when the radio is on 2g @ 900mhz.....

      So this could be a baseband fault, which is software and can be fixed OTA, the baseband is active during the bootloader mode.

      • http://www.simonbrettellphotography.co.uk Simon

        I'm not sure that the phone has to be on 2g @ 900MHz for the issue to be apparent. If a phone in close proximity is using 2G @ 900MHz this can also interfere with the Galaxy Nexus and cause the volume to change. It can also occur if the radios are turned off.

        • http://mgamerzproductions.com Mgamerz

          The solution is to not put your phone on other people's phones. That should be pretty easy to avoid.

    • http://twitter.com/hoeferh Henning

      Thanks for the first correct explanation on this page.

      Shame on Androidpolice for the misleading headline -- read the statement guys, you put it in nice big green quotes: Google did NOT say, the bug wasn't hardware related. They only said, they'll fix it in software.

  • UKAndroid

    A software patch of the kind people are describing will simply "hide" the hardware problem. Personally I think Samsung will re-design the circuit layout/screening for subsequent production batches and I will wait till next year before risking a kludged device.

    Of course, by then, there will be other ICS phones probably with a MicroSD slot that will be more attractive!

    • Adam

      It may be a workaround, but they'll NEVER publicly admit if it actually were a design/hardware related issue. That kinda goes without saying tho. Bug or not I still want this phone on vzw

    • Appelflap

      Why stop here? Lol. Why don't you say that there's a whole layer of patches in the phone that hides all kind of hardware problems.

      • UKAndroid

        Appelflap - you are absolutely right! But this applies to virtually all "computerised" devices. Even when you "click" a simple switch, the contacts "bounce" for a few millseconds and software has to filter out the bounce - especially for switch that is supposed to perform a "toggle" action.

        Every phone ever made will have software functions to "get round" these types of hardware problems/characteristics.

        It's just a worry that it seems the RF immunity in the early production models seems to somewhat lacking if reports are correct.

    • Aerogems

      So long as the symptoms no longer present, who cares if it "masks" the issue or not?

      It's also a little obnoxious seeing a number of people who have probably never written a line of code in their life, let alone held a soldering iron, claim to know that it MUST be a hardware issue. It was funny in a sad kind of way the first few times, now it's just getting obnoxious seeing all these people feigning understanding by regurgitating something someone else said that's probably utter bollocks, but sounded technical and was said with authority.

      Hardware, software, who cares as long as you no longer experience the problem?

      • UKAndroid

        All software "fixes" require processor time and affect ultimate performance of a device.

        I am a hardware/software designer and not only hand build development systems but write the code. I suspect that quite a few others here have also direct experience of writing code and soldering.

        Your "who cares" is the response of someone who does not understand the first paragraph of this reply. Probable the sort of person that would moan about response "lag" - likely caused by numerous software kludges!

        Who cares? Most people.

        • Aerogems

          In this case, not really. On a purely technical level, you're correct, but when we're talking probably a small handful of CPU cycles, you're never going to notice. The only people who are ever going to be able to tell the difference are the people who obsessively modify and tweak things to improve performance, to the point where they never stop to take the time and actually enjoy the fruits of their hard work.

          I'm all for people writing more efficient code, and making sure things get done right the first time, but yours is a bit of a purist view. The majority of people won't have your hyper-sensitivity to these things, and would probably never notice if one of the cores was completely dedicated to dealing with this fix.

          I know it can be hard to wrap your head around, since there's a natural tendency to expand our own experiences to others in the absence of other information, but most people don't give a flying leap about the specs of the phone. They walk into a store, pick out a phone based on how it looks. Go to a mall, and I'd wager around half the people couldn't even tell you the brand of phone they have, let alone anything about it. People like us are the exception, not that you'd really know it because we live in something of an echo chamber of our own design.

        • reverend t

          Agreed. This involves changing a filtering value, one that probably wasn't set correctly to begin with.

          UKAndroid, are you a particularly good "hardware/software designer"? Do you have the first ducking idea about how much harder a processor would have to work to provide a 'pressed' response to a perceived 80ms input as opposed to a 40ms input? You don't have a clue, do you? Much in the same way that EVERY input on a smartphone is subject to varying degrees of analogue noise.

          PM me your name so I can remember never to offer you a job.

        • UKAndroid

          reverend t

          RT. UKAndroid, are you a particularly good "hardware/software designer"?

          Me. Yes

          RT. Do you have the first ducking idea about how much harder a processor would have to work to provide a 'pressed' response to a perceived 80ms input as opposed to a 40ms input?

          Me. Yes

          RT. You don't have a clue, do you? Much in the same way that EVERY input on a smartphone is subject to varying degrees of analogue noise.

          Me. Keybounce only happens over a known finite period and is very different to a constant unexpected random noise that has to be filtered. Much more processing power is needed.

          RT. PM me your name so I can remember never to offer you a job.

          Me. You couldn't afford me and I don't need to work for someone who thinks they know it all - but clearly doesn't understand the problems caused by random noise - much like your response!

        • reverend_t

          There's no shame in admitting that you're wrong!

        • reverend_t

          Actually I accept your point that debounce is used to deal with a problem different to random noise, but it appears that the rapidly oscillating gsm signal could be filtered out readily using this technique.

          Furthermore no phone is fully RF shielded and from my existence it's very difficult to spot how an unshielded board is going to respond to a particular type of radio signal in advance of experience. They should have done more testing, agreed.

          However, do you seriously think that slightly more complex signal processing needed for tighter filtering will be even noticeable in a device which is already powering a high brightness AMOLED screen and a full speed HSPA+ radio? I'd like to hear your reasoning if you believe this is so, target than just an assertion of your prowess.

  • Jack42

    I guess that the patch will work out just fine for me... I hardly make calls when using bootloader ;-)

    • Brandon

      Hahaha! That is awesome! :-)

  • Intheknow

    I watched a movie once that had a phone in it, so I am pretty sure that it is the flux capacitor that is causing the issue here. This could be a real problem because Google is going to have to buy a Delorean off of EBay and find a way to get it to 85 MPH, to go back in time to find the Doc. This seems like it would take some time, so it will probably take a few months.

    However they may be able to come back in time to a few months back, thereby correcting the problem before the phone is even released. But, will this create a parallel dimension? That is the real question.

    I was really looking forward to getting this phone soon, but this is a deal breaker for me if it is going to cause a rip in the time-space continuum and fling me into a different dimension.

    I have also seen a lot of black unmarked Suburbans driving around, which we have to assume is a massive effort on Google's part to cover this whole thing up on a JFK scale.

    Now in case you doubt my credibility, I watch a lot of movies and read a lot of blogs. So I know more than any other person alive.

    • http://www.cyanogenmod.com ciwrl

      This (wo)man sounds accurate and knowledgeable; I think I will take their sound reasoning and hold off on this phone until the probability of myself being flung into a different dimension is minimized!

    • Brandon

      Well you've completely forgot about the most important piece. Where in the world is google going to get a hold of the plutonium?

      • rockstar323

        I'm sure Google already has a pretty decent stockpile of plutonium.

  • britishturbo

    I'm a Systems Engineer and also a Developer. I deal with things like this every day.

    What we have here is indeed a hardware issue, in that the radio interference is coming in through the radio hardware.
    However things like this can be fix fairly easily in software. It's called debounce.
    When you monitor an electronic input like the buttons on a phone there is always noise and flutter even when you just press the button. If testing by Google has shown that they just need to turn up the debounce time (the time which an input must exceed for it to be determined to be a genuine press) then it will more than likely just work and no one will ever see ti again.

    Like I said I deal with this kind of thing every day, it's not a big deal as long as your debounce time is not excessive. But noise happens down on the order of 1 to 40 ms, real inputs when you press a button last from 100 or 200ms if you tap the button, up to seconds if you hold it down.

    This is nothing like Apple and the iPhone 4 antennae problems that could not be fixed in software. I'm sure everyone will see in due time, the problem will be fixed, and the dust will blow over.

    Cheers,

    Lee.

    • Brandon

      Thanks, Lee. Your response seems to be based on logic and reason. People love drama and in general, logic and reason diffuse it, so I'm sure it won't be long before someone comes along and tries to dismiss your statement. ;-) Thanks again!

  • taylord

    Who cares whether the problem was hardware or software? A fix is a fix; as long as the problem is solved, what's the big deal? I think people who spent their upgrade on a RAZR or a Rezound are just mad that they didn't wait for a Nexus and are now taking out their frustrations on those who did actually get one.

  • Kevin

    Something tells me that Samsung's chances of ever manufacturing another Nexus phone are now less than zero.

    Should have stuck with HTC in the first place, eh Google?

    • Level380

      @Kevin...... Samsung was extra lucky that they got to make two nexus products. Google selects one OEM to work with for the year with the end result being a Nexus phone. This OEM is selected based on a hardware area that google wishes to improve, ie cpu/gpu/chipset support.

      Last year google was working with Sony, on the second Nexus device was meant to be the Xperia Play, but Sony pulled out with two weeks before the end of the development stage. That’s when Samsung stepped in and designed and manufactured the Nexus S in the time span of 2-3 weeks for the gingerbread release.

      This is why Samsung got two Nexus devices. Next years OEM has already been selected. More details on the Nexus program can be found here

      http://ausdroid.net/2011/08/16/the-nexus-program-the-basics-of-how-it-works/

      • http://pharaohtechblog.blogspot.com Conan Kudo (ニール・ゴンパ)

        If anything, that hurts Sony's chances of being a Nexus partner more than anything else...

        • level380

          Ummm yep, I doubt Sony will be asked back into the Nexus program at all!

          If you remember, last year they also brought out a Sony Google TV, I assume this was mixed in as part of the Nexus program.

          Silly move from Sony, such a screw up!

  • Charlie

    Do you think they will fix the lock and unlock functions too? (Or is it me being a dumb bugger)

    If I press the power switch to switch the phone into standby mode, it locks instantly (even though I have 30 minute lock display set).

    If I leave the phone to go into standby mode by itself, then it stays unlocked for 30 minutes..... (the way I would expect it to)

    • dave

      That's a feature not a bug... It allows you to lock the phone manually when pressing the switch. But if the screen times out while reading something then it gives you 30 minutes to resume what you were doing without having to log back in.

      It's supposed to do it this way.

  • Meg

    What a joke even on the purest of models, the idiots still fail to deliver an average product. ahahaha

Quantcast