Shared publicly  - 
Took a few extra hours to post this due to waiting for the OS images to hit the official download page while getting some clarifications about compatibility, mostly for the Nexus S variants.

So, here you go.
Ben Chow's profile photoMarthinus geen's profile photoChris Simms's profile photoTish Jason's profile photo
+Android Police & +Jean-Baptiste Queru i just wipe my nexus s i9020t and apply the soju file from recovery.
Error happens:
E:signature verification failed
Installation aborted

i lost my data, and it doesn't work
+Artem Russakovskii - LOL that you called me "chief build/release engineer". That's definitely not me :)

Seriously, about the i9023, the trick is that those arrived much later than the ones we did Gingerbread development on, so we were already fully stocked at work, and therefore they're extremely uncommon at Google (especially since they're not sold in the US). Testing on those is normally done by Samsung and the operators that sold them, which is why I don't have as much visibility over those from within Google.
+Aryell Caesar - Those aren't meant to be user from recovery, they are flashed via the bootloader with the fastboot tool. They're meant to be used if you've been flashing your own custom builds directly from source, and use the same tools. They live about 2 levels below recovery, so they can be used even in situations where you end up with a bad recovery.
+Renaud Lepage - Not really :(. When we worked on fewer devices at the same time and when the team was smaller, it was possible to get several of each individual device, but right now people rarely have more than 1 Nexus S, 1 Xoom and 1 Galaxy Nexus. I'm lucky as I already have several of those (I need them for AOSP), but I don't have one of each sub-variant.
i'm not a smart android user. i don't know what fastboot tool is. i just want update for my nexus s that i bought 3 month after it first release. The ICS 4.0.3 battery bug is drive me crazy.

Could someone give me a link to apply this update?
+Aryell Caesar - I strongly recommend that you wait for the OTA. The factory images that I released are really meant to be used by people who work directly with the Android source code and are familiar with the processes involved.
+Jean-Baptiste Queru well ok. but anyway, i suggest if there are notes on the page of the source that the source can not be applied without knowledge of android processes, so users like me didn't do wrong and wipe their data
+Aryell Caesar - You're definitely right on that front, there's currently no documentation at all... and writing the documentation in question is on my todo list on my whiteboard at work, I just haven't found time yet to actually do it.
+Aryell Caesar - Actually there are 2 engineers + 1 manager, but we try to not make our tasks overlap too much in order to avoid inefficiencies, and I've been the only one working on factory images so far as it's been quite a new thing for us (really, it's the first time I update them since the initial release).
Is there an updated base and available for the GSM variants for north America?
+Jean-Baptiste Queru If you're not the main release guy when it comes to AOSP, I don't know who is :)

Warning: this turned into a rant.

As for test devices, I'm not sure I'm happy to hear how few test devices you and your team has, considering how important the Nexus program is, how many Nexus users are out there right now, and that you're pretty much in charge of building, supporting, and releasing everything Nexus-related.

I mean, is it about money? Google can't afford to at least buy every Nexus variant out there for the very team that maintains it? It just seems so incredibly important, and while I don't want to diminish all the great work you do, but 1-3 people supporting millions of devices with variations they can't even test just seems insane. I realize Google is in charge of the source code that OEMs can they take and run with, but I'm talking strictly the Nexus program here.

And then there's documentation. It's so important, but it lacks everywhere across Android, and the image page is the perfect example. The Nexus program is so brilliant, it pains me that the tools to install software along with the software itself are very cryptic and not obvious, and the available packages are so ambiguous that even the build master isn't sure what they apply to. Samsung made ODIN to make flashing relatively simple, we would all love to see something that easy and straightforward for the Nexuses. I truly wish project managers paid attention to these things and not just engineers. I can say the same about the dev tools, like ADT and SDK tools, which I both loved and hated when developing apps. A man can dream that one day restoring to stock will be as easy as burning a DVD...

/end rant.
I think that there are a few misconceptions here.

At times, I have to remind myself that most people don't understand the technical depth of a software system like Android, because they don't see it. They only see the UI, and they think that the UI is everything.

I'm going to have to remind myself as well that most people don't see the organizational depth that's behind a project like Android. They only see a few people, and they think that those people are everything. I'm not everything, I'm at a boundary between the Android organization and the outside world, which is why I'm very visible. I'm extremely dependent on the depth of the organization for everything I do.

We've got a lot of work on our plate right now with AOSP. We were still dealing with the extra difficulty of Honeycomb not getting released in AOSP when went down, and combining the two has been keeping us more busy than usual for the last 14 months. We're catching up, we're still missing a few tools, and once we have our tools in place the task backlog will start to shrink.

As for the specific issue of documentation about restoring factory images, it's entirely my fault. What really happened is that getting them hosted for Nexus S was a very long saga of tricky discussions, and I wasn't confident that we'd be able to host them at all for Galaxy Nexus either, so I didn't prepare anything. Once we got a green light for Galaxy Nexus, I put them online quickly in the middle of the craziness between 4.0.1 and 4.0.2 and didn't have time to write the documentation, and now that we're putting an updated version out there, especially for Nexus S, the lack of documentation is striking. It's on my todo list, along with a few dozen other items.

About the bigger issue of documentation for AOSP, one of the old complaints I had received is that people wanted the AOSP site to be user-editable. I had an intern last year who implemented that, but we're finding out that we have few user edits. I had been hoping that we'd get more cooperation about the documentation than what we go, and I should have had my intern improve the documentation instead of making it possible for everyone to improve it.

Finally, about the i9023: I just need to find out the details. I'm sure someone at Google knows. I might even have known in the past, but Nexus S was several devices ago and I would simply have forgotten.
J Hart
I also have an i9023 its still on Ginger bread 2.3.6 will I get an update soon.. my provider is vodafone UK.. thank-you x
+Jean-Baptiste Queru Thanks for the response. However, nothing in your response changed the impression that I got and conveyed in my reply above. The Nexus program seems like it's beta vs the flagship program that it should be. Google is driven by engineering a lot more than other companies, including product decisions, and it shows in many ways. If this was something like Microsoft (blasphemy! I know), I could see a lot more polish and attention to dev tools, restoration tools, flashing tools, and making your customers happy, even the ones who are not techie. Especially those, in fact.

Right now, you have to have spent ages reading and getting familiar with xda and other sites to even remotely get comfortable to performing a lot of the tasks, like restoring an OS image. IF you even get the balls to do it, and IF you find documentation. Surprisingly, even something that came out of Google, like ChromeOS, has much easier and idiot-friendly restoration tools, though they're still not perfect by far.

Google gives engineers 20% to work on things they wouldn't otherwise get to work on - I hope at one point that could be taking a giant step back and looking at the big picture. Putting down the engineering cap and becoming an average consumer. Having focus groups, asking your parents. I'm sure my mom could restore a bricked iPod to stock, but she wouldn't in a million years figure out how to do that to the Nexus.

Furthermore, not everyone wants to wipe when flashing to the latest and greatest. Some people would just like to upgrade, whether it's because they don't want to wait for the OTA or because their OTA process isn't working. An ability to do that and a site where you truly feel like you have an easy way to get the latest would be perfect. Put in your phone's model, bam - download the files, flash them, and you didn't lose any data, and you're on the latest OS. That's what the true Nexus experience should be like. I know there are lots of reasons and excuses for why it's not like that, but that shouldn't stop Google from trying to get there. I'd just like to hope that one of the most popular mobile OSes in the world is even going in that direction. I'm not sure it is, or that anyone at Google who can make things happen cares for that kind of simplicity, beauty, and robustness.
+Artem Russakovskii - Thanks a lot for taking the time to write this. I'm not going to comment very far, as this discussion generally goes beyond the strict domain of technical AOSP issues that's my own realm of expertise. You can be sure that I've read it in detail, as well as the comment you pointed to.
I'm getting hints that we might be in the clear for i9023, but I'm waiting for an official confirmation first. If i9020t and i9023 are in fact interchangeable, that'd explain why I've never heard of issues before, but I'd rather be safe than sorry, especially since trying something similar on Nexus One would kill the display.
+Artem Russakovskii - That last comment you linked to is interesting, but mostly at a meta level.

First, when I see a comment like that, I have to remind myself that this is a user who cares. Deep inside, that's actually good news. I've worked in the past on products that users didn't care about, so I've learned to recognize the difference.

The next step is that this is a user who is almost but not quite satisfied by what they have. Given how incredibly complex cell phones are, that's actually good news too.

Now, in the case of that post, a core issue is the problem of documentation that we've talked about earlier: the images I post simply aren't meant for that user's situation. They're meant to be used by people who build and flash their own AOSP builds, and they're optimized for that specific case. I need to clarify that. I have a draft, but I won't be able to get approval to change the web site for another few days. For end users, the OTA mechanism is meant to hide away all the complexity, to the point where some users think that it's a simple problem, and that's good news as it means that OTAs successfully hides the complexity.

Also, that user's view appears to oversimplify things, by glossing over the constraints related to licensing, to regulatory approvals, to the costs of running manufacturing lines, to the costs of consumer support and to the costs of marketing. Now, you could argue that the comment you linked didn't say anything about any of those, but deep inside those are the constraints behind many of the aspects that the user complains about, and that's my point: there's a lot of complexity hidden in those gadgets that we take for granted, and we're in that in-between valley of technology where we can hide enough of the complexity for people to not see the whole depth, but not quite enough of it yet to make it entirely invisible.

Finally, the question of the relative schedules of releases across devices and operators keeps coming back. I've accepted for a long time that it's impossible to satisfy everyone. We see people willing to pirate leaked versions that are known to have severe issues. We see people willing to install software that wasn't meant for their hardware instead of waiting for the right version to be fully validated. We see people willing to go through a bunch of manual undocumented steps to update their phone instead of waiting a few days for the exact same update to be sent automatically to their device. And on the other hand we see people suggesting that all releases should be done at the exact same time, which can only be done by delaying all the releases as they get ready, until the last one gets approved. That's simply no way to reconcile the desires of those two groups of people without using time machines.
+Jean-Baptiste Queru Why can the Android team release the AOSP Builds simultaneously for each respect AOSP Nexus device or Xoom's. As a end-user of both a Galaxy Nexus(Verizon) and a Nexus S 4G(Sprint) i would like to join the party just like GSM Nexus devices. I know the carriers have to get their hands on the software for testing but, but why release update software for certain particular devices and hold back the rest? It really rubs salt in people wounds that expect to have the latest and greatest and get half assed for having a cdma phone.
"We see people willing to go through a bunch of manual undocumented steps to update their phone instead of waiting a few days for the exact same update to be sent automatically to their device."

The problem with this is that it's not a few days. It's months, if ever. I purchased a Galaxy Nexus from Telstra in Australia, and 4.0.1 (which was on it when purchased) is apparently my phone is "currently up to date" - but I know that's not true. Telstra has a page on their site detailing the progress of updates to phones through "certification", but the Galaxy Nexus isn't even listed there.

My Telstra Galaxy Nexus isn't a "yakju" device, it's "yakjudv". As far as I can tell, I should be able to install this image here, but there's nothing on the page telling me that this is OK (a list of yakju variants would be nice).

I sound like I'm complaining. I'm just frustrated. Sorry.
+Sodiq Awokoya - I'm not sure what you exactly mean. I personally take care of the AOSP releases, and I (almost) always do the releases for all devices at the same time, which only requires Google approval. The release of 4.0.4 that I did on Wednesday has all the files necessary for all 6 devices.

I can't release factory images before those are approved, because of their ties to the consumer end of things, which requires additional approvals on which I have no control, but for each supported device I do test that the AOSP code can be used with the most recently available radio and bootloader (even if those come from an earlier version).

The annoying part right this moment is that some retail variants of Nexus S are still running 2.3.6 or 2.3.7. When I finally and unexpectedly got the green light on Thursday to distribute the Nexus S factory images, I was not ready to go back to packaging the ones from 2.3.6 and 2.3.7. I was able to get things ready for 4.0.4, which meant that I had to limit myself to soju, and I'll take care of sojua, sojuk and sojus as soon as I get a chance.
+Jason Murray - I guess I should have been more precise.

What you're seeing is a difference in approval time for each individual OTA. Once an OTA is approved, it started getting deployed immediately to a handful of users, and within days it's available to all devices of that combination of model / operator / country.

I'm not familiar with the certification process of each operator, so I can't predict exact schedules, though I can confirm that for some operators it's measured in days or even hours, and for others it's measured in weeks or even months.

I realize that the situation is frustrating. Unfortunately, I can't recommend that you try to flash a yakju build on your yakjudv device. I've confirmed with Samsung that such combinations are expected to cause difficulties in all situations, but especially and specifically on devices sold in Australia and Japan.
+Jean-Baptiste Queru sorry, for the confusion. What I'm saying is all Nexus devices should be updated at the same time through OTA updates be it GSM/CDMA mode. I can also understand that the software needs to be approved 1st. What I'm suggesting is If one software version is approved and the other is not, you shouldn't release any OTA updates till every version software is approved. Just how the GSM Galaxy Nexus are running on 4.0.4 and the CDMA variants aren't. You should wait till those are approved by Verizon and have a simultaneously OTA update for all Nexus devices. Me and some friends are kinda ticked off that either their Nexus S 4G(Sprint) hasn't gotten 4.0 or their Galaxy Nexus on Verizon is lagging behind the GSM models. Thank you for replying.
+Jean-Baptiste Queru - are you saying that the "retail variants of Nexus S that are still running 2.3.6 or 2.3.7" are not getting 4.0.4 updates EVER? heart breaks
+Jean-Baptiste Queru Am I right in thinking that the i9020 is a no go? I'm not all that clear on the differences between the i9020 variants, so I'd rather get a go-ahead beforehand, thanks.

Edit: Now I look again, I can't see an i9020 mentioned at all in any previous posts on the group discussion, do I have a letter following it I don't know about (nooby questions, but I'm new to my Nexus).
Should I be worried that my CDMA version is going to be weeks behind for 4.04 thanks to big red? haha
+Jean-Baptiste Queru Firstly, I think its great that you're engaging with people here. Consumers really appreciate communication with companies, and I know that one of the biggest annoyance nexus owners have had with the delayed updates is the lack of any news from Google. I guess they don't know how much a simple 'we're almost done, the OTA will be pushed this week' means to people. So, thanks.

That said, I know its not your area, and I appreciate that, but do you happen to have any idea when the nexus s will receive the 4.04 OTA? I've held out against all the other methods of updating because I wanted to wait for the real deal (and I don't trust myself to meddle with that!). Thanks
Oh, that's definitely one thing I forgot to mention, +Jean-Baptiste Queru, thanks +Adam Morris for reminding me. One of the biggest annoyances and frustrations with the way the Nexus updates were handled was complete silence and disregard of questions regarding Nexus ICS updates by Google. I understand engineers were working on some bugs and there was uncertainty, but shutting off any response whatsoever and putting up that wall did a lot of harm. Remember, a lot of the Nexus owners are early adopters and huge Google/Android fans - by shutting them out in a manner that was worse even than some of the less popular OEMs (as far as public opinion goes) was a slap in the face. I don't own a Nexus, but I felt their pain, and I'm sure you did too when you read some of the stories that a few blogs wrote.

Please, more transparency. Sometimes knowing something is far better than not knowing anything at all, and more importantly, getting completely ignored.
+Artem Russakovskii Hit the nail in the head. Their was even a petition to bring the ICS to the Nexus S people were mad that a Nexus device that is suppose to get latest first be ousted by phones like the HTC Vivid. As a user, I can respect that you need to iron the bugs but let us know on the progress don't live us high and dry not everyone is flashing custom ICS roms.
1) Why do none of these problems seem to affect Apple?

2) Why, in the past, could I simply download an incremental Gingerbread update and install it on my Nexus S phone without any issues whatsoever, while that is apparently broken/forbidden now and all of a sudden subject to regulatory/carrier/OEM/hardware/whatever approval?

Surely Google know what hardware is in their own branded Nexus phones and can test their software/updates against it, and it has as much to do with the carriers as me buying a random SIM-free phone and turning it on on their network? Carriers have to cope with that possibility anyway; why are software updates to an existing phone different?

I wouldn't mind OTA patches -- in fact I'd prefer them to manually installing updates -- if there was any transparency about when and if they would actually happen. I'd much rather my phone updated itself. But that process has already proven to be completely unreliable and frustrating, a case of waiting for something that never comes.
+Sodiq Awokoya - Please keep in mind that I have no involvement in deciding the actual ship dates, and that I don't even have power to veto a decision to send an OTA in case I'm not ready to deal with the Open-Source implications myself. I'm just as much at the mercy of other people's decisions here as you are as a user.

Looking at this issue from the outside, since I have no influence on it, I see that there's fundamentally a conflict: some users want the updates as soon as they're ready, and some people don't want their own device to be updated last. Those two categories of users can't be satisfied at the same time. As much as nobody wants their phone to be updated last, nobody really wants their own update to be delayed by weeks or months because of another operator in another country.

While I don't always believe in free markets, I do believe that in this case competitive forces are a good mechanism: users who want updates quickly will eventually realize that there's a pattern between the operators where the updates arrive quickly and those where they take more time, and switch their service accordingly. They'll also eventually realize that buying devices that aren't sold by any operator (like the original Nexus One with the passion build) also receive updates faster, and they'll buy those preferentially. They've realized already that Nexus devices tend to receive updates faster than other devices. I'm pretty sure that there must exist some independent and unbiased community resources out there that track that information so that people can make an informed decision.
There are multiple questions about the update schedules for Nexus S, and I can't answer that, because I don't have access to all the information, and because it's not by job to talk about that in public. At my level, in the Android Open-Source Project, there are source files and binary files available for 4.0.4 for all variants of Nexus S, and that indicates that Google thinks that 4.0.4 works well enough on those (since Google independently makes the decision of what goes and doesn't go in AOSP).

I know this is somewhat of a non-answer, but really my domain is AOSP, and when it comes to the gap between Google feeling that something is ready and everyone else involved agreeing that the OTA can be sent, I have no involvement and no influence. It'd certainly be easier for me if everything happened at the same time, as e.g. I wouldn't have to let factory images trickle one at a time or to test combinations of the latest AOSP code on older versions of the bootloaders and radio firmwares.
+Jean-Baptiste Queru Your competition discussion makes sense in theory, but given the lack of competition as far as carriers are concerned, it's not realistic to expect users to switch to a different carrier just for faster updates. Sometimes, it's not even an option, like in the case where only one carrier has the latest Nexus for an exclusivity period of many months.
+Artem Russakovskii +Sodiq Awokoya - I have a rule of thumb about making predictions of software schedules: if something isn't shipping right now, it's because there's time left in the schedule that is meant to allow changing the planned release date (or to cancel or skip a release, which does happen quite a bit).

Because of that, there are really only two statements that can be reliably communicated: "it's shipping now" and "it might ship at some point in the future". Since exactly one of the two is true at any point in time, and since one of those reflects a fact that can be independently verified, there's really no possibility of any communication about software schedules that's both accurate and informative.

When I see how angry people get because of the delay between a leak (thinking it was days away from shipping) and the actual release, I don't want to imagine how angry they'd get if Google said anything about future plans and future dates and those dates turns out to be inaccurate.

Actually, I can somewhat imagine how that'd be. I've been threatened just because I work on Android. I've been defamed. I've received racist comments. I've even been targeted by a petition last year that almost got me to quit (I left the team for a few weeks). After all that, I'm extremely cautious about making any kind of promise that I can't back. As an example, that's why I'm not making any strong promise about releasing future factory images. If a lawyer shows up in my office on Monday morning and tells me that I can't release any factory image ever again, there's nothing I can do about it.
+Jean-Baptiste Queru Thank you for replying to my concerns. Much respect. In my strongest honest opinion Google needs to grab the bulls by the horn and handle every update themselves. I believe the carriers are the cause for the delays, you guys work hard on Android and I can see that by using 4.0 cause it was thoughtfully design than any pervious version of Android. The carriers can careless on what the user wants in 4.0. They look to include bloatware and make as much money they can squeeze from a consumer. (The Verizon logo on my Galaxy Nexus back shows that and lets me know Google is not in control no more of their own products) Its actually disappointing. Its also messed up that people insulted you I'm actually disgusted that people will disrespect a Android Developer who basically works to distribute free software. Once again thank you for replying, this is something i can tell other users who don't understand the update process of Nexus devices.
+Leo Davidson - I'll skip the part about Apple, for lack of a precise answer (since that's really not my domain of expertise). There are many differences in the way Apple does things, and I don't know for sure which ones are relevant to this discussion.

About sideloading OTA packages: this isn't meant to be a user feature. OTA packages aren't licensed to be touched manually by end-users. The feature exists for rare cases during development (our primary mechanism is to send regular OTAs, as that's what's exposed to end-users, and the secondary mechanism is to flash via the bootloader and fastboot), and it's possible that it got accidentally broken at some point. I don't believe that it was intentionally removed. But it clearly still hasn't fully adapted to devices that don't have an SD card, and it might have gotten damaged by mistake in an effort to try to make it adapt. Someone with enough technical skills and enough time to do so could have a look at the recovery source code, since it's all Open-Source.
+Vladimir Costescu - Well, I feel that there's certainly a lot more competition in cell phone carriers than in just about any other utility or public service: I can't choose my cable TV company, my landline company, my electricity company, my garbage company, my bus company, my train company, but I can choose between quite a few carriers (the big 4, metro, regional carriers, MVNOs).

Things aren't perfect in the US, where we don't benefit from regulated interoperability as much as people do in Europe, but I think that it is reasonably possible to shop around, to buy no-contract devices and prepaid no-contract plans and to use number portability to follow the best devices around.

I do wish that we had better interoperability between carriers, to avoid getting stuck with phones being strongly tied to a single carrier, but if the goal is to have specific devices with the carrier being a generic utility, that's not such a big issue.
+Jean-Baptiste Queru About the mass-edited Android SDK Reference, how did you find out that "we're finding out that we have few user edits." ? Was it released to the public? I would like to help sooo much in editing the Android SDK reference, especially after I opened the framework source code to find out what a method does precisely and I found some enlightenment, I really desired to share that knowledge into the world. Wouldn't user-editable or at least user-commentable (like docs!) reference site be useful! I think a lot of +Android Developers will also contribute to the docs. Revive the wikiism!
I was under the impression that nexus devices had updates pushed directly from Google, bypassing the carriers. I'm sure I'd read that somewhere. Or is that just a myth?
+Jean-Baptiste Queru +Artem Russakovskii Will this Update (i9023) whenever it arrives fix the recovery bug that has been there the day 4.0.3 was launched? I am not sure (never been released by google) why they stopped OTA updates for ICS. IMO it was stopped due to this recovery bug issue.
+Yuku Sugianto - The SDK reference itself has always been part of the Android Open-Source Project, and I'm pretty sure that it does receive some contributions on a regular basis. Most of the leaf content is javadoc and therefore sprinkled (mostly) in frameworks/base and in libcore, and the structure is (I think) in the build and development projects. I realize that this requires working directly in the Android source tree, but at the scale of a project like Android it's the most practical way to keep the code and the documentation in sync.

I was more specifically talking about the source code for AOSP itself at, which (ironically) wasn't Open-Source until about a year ago. It now lives in the Android Open-Source Project as well, under docs/ That's where we haven't received many contributions: it looks like we only got 3 contributions since we Open-Sourced it.
+Adam Morris - At the technical level, all Nexus updates come from Google's server using Google's update mechanisms.

Looking from the sidelines, I know that the development process (including testing) involves many companies in addition to Google, and that means that the decision to ship to a given device can vary based on the device manufacturer, the country, the operator.
+Brian D'Souza - The OTA path gets tested continuously to make sure that it never breaks (since, obviously, if it breaks, we couldn't send an OTA to send a fix), and each consumer update path gets explicitly double-checked as well before each release gets approved.

If there was an issue that prevented OTAs from working, I assume that I'd be asked about distributing factory images as a plan B, since I have some expertise in packaging and distributing those, but since I haven't been asked anything of that nature I assume that there hasn't been any known issue there.
+Yuku Sugianto - That's exactly it. I should have directed you there in the first place, sorry. I spend so much time with that site in front of my nose that I take it too much for granted.
+Jean-Baptiste Queru I own a Nexus S. When Google rolls out any OTA update, he should get it within say 2 weeks. What is the point of owning a Nexus handset when I still need to wait for an OTA update? Wait for an OTA update to be certified by operators, device makers etc.? That was not the reason why Google made the Nexus program. Looking at your replies, it looks like the Nexus program is just "another" project for Google. The same statement stands true for Android.

Android is now big enough to get priority over other projects/teams in Google. There are quite a few features in Android that does not work because umm well there are different teams for everything and they don't work together. Example - In Android 4.0, Google introduced the People's app that syncs a high-resolution photo of your contact. Problem - You add a high-resolution pic of your contact; sync it with Google Contacts and bam! the image gets down sized to 200*200. Why? Because Google Contacts does not support high-resolution pictures.

Another example - The People's app pulls in your contacts info from popular social network sites like Facebook, Twitter etc. However, users cannot sync their Facebook and Twitter friends using the official Facebook and Twitter app. Why? Because Google (Search team) has some issues with them, and for some reason the Contacts syncing feature was removed.

What happened to the Google Alliance program? Google takes a HELL lot of time from announcing a product to releasing it. Example - At Google I/O 2011, Google said some new features are coming to the Android Market including the ability to host up to 50MB APK files with 2*2GB additional files. This announcement took more than 8 months (or possibly more) to materialize.

I am a die-hard Android supporter. However bad Android may be, but I will still prefer it to iOS, but I expect Google to take Android more seriously and fix all the issues with the OS and its eco-system.

P.S. - I know most of the above stuff might not be under your department, but you are the only way I can voice my issues to them. Also, I really appreciate your hard work, and it is my dream to meet you someday.
And for all Nexus S (I9023) owners, the stock Android 4.0.4 image will work with your handset flawlessly.
Add a comment...