That may be true - but that's little comfort to the end consumer, and earns you no points next time they find themselves in a store picking out a new phone.
I don't understand why Google doesn't support offline/non-OTA patches. Apple achieved phenomenal adoption speed for new releases pre-OTA, there's no reason Google can't do the same. The fact that Google needs a carrier's blessing to patch phones is a non sequitor.
These are non-OTA updates, so I'm not sure that analysis holds. Note that the Verizon CDMA Galaxy Nexus ("toro") is in a similar position, but that JBQ promised an image would be coming soon.
I think a stronger case can be made that Google lacks an architecture like the desktop distros have where they can update packages independently. Why should, e.g., UI improvements to the shell or bug fixes to the settings app be held back by driver validation for an LTE modem?
Comments
I have the Nexus S 4G, specifically. Still waiting :)
I believe that's a sprint issue, not a google one.
That may be true - but that's little comfort to the end consumer, and earns you no points next time they find themselves in a store picking out a new phone.
I don't understand why Google doesn't support offline/non-OTA patches. Apple achieved phenomenal adoption speed for new releases pre-OTA, there's no reason Google can't do the same. The fact that Google needs a carrier's blessing to patch phones is a non sequitor.
These are non-OTA updates, so I'm not sure that analysis holds. Note that the Verizon CDMA Galaxy Nexus ("toro") is in a similar position, but that JBQ promised an image would be coming soon.
I think a stronger case can be made that Google lacks an architecture like the desktop distros have where they can update packages independently. Why should, e.g., UI improvements to the shell or bug fixes to the settings app be held back by driver validation for an LTE modem?