Sprint Galaxy Nexus: not supported in AOSP

I've been getting a few questions about AOSP support for the Sprint Galaxy Nexus.

The short answer is: the Sprint Galaxy Nexus is not supported in the Android Open Source Project.

The long answer: the release process for the Spring Galaxy Nexus is similar to that of the non-yakju variants of the GSM Galaxy Nexus (e.g. yakjuxw, yakjuux, yakjudv...), which makes that device similarly impossible to support in AOSP. There are no source files, no proprietary hardware-related binaries and no factory images available for the Sprint Galaxy Nexus. In addition, since it's a CDMA device, it would probably be limited by the usual CDMA licensing issues that have been affecting the other CDMA devices.

I've also had a few questions about IMM76I. I'm planning to tag it in AOSP in the next few days, unless emergencies decide otherwise.
Quinn Phillips's profile photoRyan West's profile photoJean-Baptiste “JBQ” Quéru's profile photoMichael Brumlow's profile photo
Developers have to know that CDMA devices are at the mercy of the closed source providers.
I like the "Verizon destroyed the nexus brand" comments and people acting as if sprint is any different/less greedy. Only difference is level of desperation

I wish a GSM network had any coverage where I live. But they don't.
No offense JBQ but I really wish I could -1 a post :(
What does this mean for open source ROMs, like CyanogenMod?
So what is the true meaning of Nexus brand phone? With all different brands it doesn't feel like a nexus. Just another original motorola droid.
+Chris Sucharda the fact that they're unlockable via fast boot and run on aosp framework to give developers a baseline to program for. Nexus wasn't created for the users. Carrier framework is irrelevant to an application developer
Between this and the non US Xoom (with Nexus like expectations if not name) the brand is getting a bit tarnished in my mind.
+Zach Tibbitts it means that we will update extract-files.sh for these devices for people who roll their own. As for releases and people who download from get.cm, at this point in time, it doesn't mean much. While we wish there was a fully open, easy, and, most importantly, legal path for people interested in these devices to follow, our hands are tied by what the oems and such provide us.

Long story short for the end user: the Sprint Galaxy Nexus will be supported, but the proprietary files will come from the actual devices than from the Google page directly.
yes because Google's all powerful entity isn't able to support them even though they are closed.
No offense +Jason Smedley , but I think you underestimate they power of market leverage... just look at what Apple pulled off (Verizon refused to play that game so Apple took the product to ATT and made bank... Now every carrier it's happy to have an iPhone and make exceptions)

It doesn't seem to be in googles nature to play hardball... But don't think they couldn't
I wouldn't call this along the lines of market leverage I would call it the equivalent of asking apple to comply with the gpl. Cdma carriers do not like throwing proprietary framework out. And when they do they generally give you something that's almost unusable, also like apple in situations where they complied with the gpl
+Jean-Baptiste Queru thanks for letting me know this, I won't be buying a CDMA Nexus Device. -typed from a Verizon non-supported AOSP Galaxy Nexus
I know the reasons have all been given, but it's still just frustrating that the only Galaxy Nexus variant to officially get Google Wallet ("Pure Google!") won't be supported as an AOSP device.
What a really nasty surprise from Google to those who were unfortunate enough to get a Sprint Galaxy Nexus... thinking it was a Nexus class device with all the benefits that implied... I feel bad that the Nexus concept has been totally changed (from what the Nexus One was and all around it) and lots of promises broken.
Oh well...it's business after all... some may say...
Is the GN coming to tmobile... bye bye cdma if it is.
Is there a changelog for IMM76I?
Google, it's time to become a carrier, so that you don't have to let carriers twist your arms and tarnish your flagship brand. You're already looking at becoming an ISP, this is the logical step afterwards.

If Google deployed a "Google Mobile", I'd be happy to switch from VZW, especially if was a good fast 4G network. I like VZW's network at tech support, but I can't stand their anti-competitive business practices. Likewise I'd happily ditch AT&T for Google Fiber if it were available in my area.
+Derek Morr - There'll be one when I do the source push :) I don't remember the exact details off-hand, and I'm not at work so I can't check, but I think it boils down to a few kernel tweaks for GSM Galaxy Nexus, no platform changes IIRC. I might be wrong, and I don't know any more details.
+Jason Hsu I believe it recently became available on AT&T.

What would it take to get Verizon and Sprint to open their drivers? Like, realistically. There doesn't seem to be any reason to keep them closed is there? It's not like some CDMA carrier in another country is going to rip them off since CDMA is US-only. Maybe Sprint and Verizon worry about eachother? But their tech stacks are pretty different I believe, although they're less different now that LTE is the 4G standard...
+Andrew Rabon I though that the CDMA drivers were proprietary due to Qualcomm, rather than VZW/Sprint.
+Jean-Baptiste Queru thanks in advance for IMM76I! Who has got the OTA reported it solved the no-signal-during-sleep issue. We are looking forward to have it!
Cant wait for the IMM76I to hit the developer site so I can flash the full ROM.. For some reason I get yakju updates really late on my phone so Im forced to manually flash them when available. Good work, a lot of people with the issue report it as solved over at XDA. I feel for the CDMA users, but here in Australia its all GSM so I guess we are lucky
Google doesn't seem to want to portray any leverage against the carriers and this effect is leading to diminish the people's perception of what the Nexus brand stands for. You may very well say that it means 'unlocked fastboot' but what consumers are expecting is faster updates. The PR communication, timing and process behind the Nexus S update to ICS should have been an embarrassment to whoever was leading it; especially, considering the fact that HTC was getting ready on their updates with Sense customization first.

I feel someone really needs to reign in the whole feedback cycle, UX (not UI) and quality standard across too many of Google's products lately (not to mention, kick some carrier balls).

/Off-topic example of a strategic miss:
Regarding Google Wallet: I was amazed that someone in the project thought that a payment gateway depending upon carrier support would grow unhindered. Carrier opposition to network neutrality and removal of unlimited data plans, two years ago, should have been a pretty clear indicator that for GW to succeed, it would have to completely bypass all reliance on the carrier back-end.
Don't worry jbq, i'll crack sprint lte just like i cracked Verizon LTE for Xoom.
This definitely changes my opinion of the Google line of phones. Since I'm on Sprint, I gotta jump through hoops. Sounds like carriers are bullying Google on it's signature phone.
+Ananya Gupta +1 on the "(not to mention, kick some carrier balls)"

Google Wallet does NOT rely on any carrier backend. All it requires is an internet connection -- ANY internet connection, NFC and Secure Element (hardware in the phone), and Google's and Money Network's servers.

Despite VZW's contention, its not a "security issue" for their network, and they ARE, in fact, blocking the app in violation of the Network Neutrality terms forced on them by Google as part of Auction 73. LIke you said, what Google needs to do is "kick some carrier balls". Of course the FCC could weigh in on the Wallet issue, since VZW is violating the terms of the FCC spectrum auction.
+Jean-Baptiste Queru when VZW finally does an OTA (of 4.0.4 or 4.0.5, or 4.0.65535, or whatever we're at when they finally approve it) do you think the factory images for that version will be available in AOSP like the VZW 4.0.2 images are?
+James Mason Google Wallet relies on IMEI/ carrier-based authentication and will not work without it. GW ultimately needs the carriers to play along otherwise you would have seen it on every variant of Nexus S/ Galaxy Nexus phone with NFC out-of-the box.
"Google Wallet relies on IMEI/ carrier-based authentication and will not work without it."

Before I arrogantly proclaim, "Then it's broken by design," could someone explain why the carrier needs to be involved at all in what is to all outward appearances an end-to-end authentication issue?
+Leo L. Schwab Someone at Google didn't do their homework? (Just like the Nexus brand dilution lately; the open handset alliance that was going to get us updates on all phones?)
I'm surprised at the animosity toward carriers here.

The situation with the Sprint Galaxy Nexus is exactly the same as with most other Galaxy Nexus variants. It is related to the release process of those variants, which happens without direct involvement from Google's Android R&D team. That's why I don't have access to the files I would need to support those devices in AOSP: I can't piggyback on the work of the R&D team around me. There is absolutely no pressure from Sprint to try to limit AOSP support for those devices, and Sprint also had no problems with my attempts at supporting Nexus S 4G in AOSP. This separation isn't new in Galaxy Nexus, and it existed on every previous flagship device as well.

As for the CDMA side of things, there is also no pressure against AOSP support from carriers, neither from Sprint nor from Verizon. The difficulties are primarily around licensing: the details of the CDMA implementations require broader licensing terms, while at the same time they require to get licenses from multiple companies at the same time, and so far Google hasn't been able to find a way out of that inextricable maze of licensing spaghetti.

Looking all around, though, I'm not aware of any action of any kind at any point in time where any carrier has tried to restrict any aspect of AOSP support.
+James Mason - I expect that I will, though it's not really critical: you can just install an older one and get an OTA. Publishing the latest released one adds convenience, but doesn't make anything possible that wasn't already possible through other means.
+Jean-Baptiste Queru I am still waiting for the 4.0.4 OTA update on my GSM Galaxy Nexus. Here in Brazil i don't received. I'm still running 4.0.2
Finally, some real proof that Google dropped the ball and is killing the Nexus brand (and even perhaps the Android brand for the non-techie market)

The average Joe (who represent the majority of the market) doesn't and/or can't manage to "make" the phone works on their own by rooting/flashing/etc.. They will most probably, go for the alternative that does offer better native support to its product.

It's really a shame though because Android is a great product with great potential but, if nothing changes, it'll only be interesting to the Geek/tech crowd.

Still hoping to receive at least one update for my Gnex in Canada in the next year or so...still stuck on 4.01 and no news for the next OTA rollout 
+Kamil Niewczas - Essentially, same answer as above: I expect to, but you can achieve the same result by flashing an older version and getting the OTA. Having the latest version just adds convenience.
+Jean-Baptiste Queru Do you know when the 4.0.4 OTA will be available again? I'm with the 4.0.2 in my yakju galaxy nexus and I'm still wating for the update. Thank you
+Jean-Baptiste Queru

If I were at the Nexus team, the first question I would ask is, 'how does Apple manage the licensing for both CDMA carriers'?

The reasons you described are probably why the Nexus One never finally made it to Verizon inspite of being listed.

However, if the Nexus team realized that with the Verizon Galaxy Nexus and the Nexus S 4G, they possibly brought Nexus phones to carriers without the guarantee of timely updates/ AOSP to end-users due to licensing, then the devices should probably never have been brought out until the situation was resolved or should not have been called Nexus. As it stands now, you have thousands of users that bought the Nexus devices with the hope of near-instant updates. When that does not happen it tarnishes the brand over time. The multiple variants of Android besides yakju only makes the situation worse. Since, any GN device variation apparently can be converted to the Google managed build (yajku in case of the GN) this seems to be another separation that implies Google bowed down to some other carrier/manufacturer demand and ultimately leads to delayed updates for the end consumer, further destroying their perception of what the Nexus line stands for.

A lot of these situations can probably be tackled by a brand/Nexus evangelist role whose team would evaluate the complete UX of Android (and quite frankly Google products as I will attempt to outline below), beyond just that of the OS.

Android and Google need to push beyond the bounds of just good UI and focus more on integrated UX.

A few examples that a role like this could help with:

1. Roping in rogue Google blogs that are completey different, especially inferior, UX.
2. +Vic Gundotra +Google+ currently does not have a feedback button in the 'Profile' section. This is especially hindering, because there is a bug in the education history box which does not intelligently re-order the list based on dates of attendance.
3. +Vic Gundotra +Google+ feedback button scrolls up and gets hidden. This means, if I catch a bug 10 screens down (which I sent a few days ago), I need to sroll 20 screen in total to report it. Increased barriers for free user feedback is not the best UX but someone outside of development/engineering has to catch something as subtle as this.
4. Contact images assigned in +Gmail are resized to a lower resolution in some use-cases which messes with ICS high-res contact images. This is a good example of silos but something the UX evangelist team should catch by cross-product assessment. It also a serious one since it impacts Android users beyond just web GMail users.
5. There is no consistency in the usage of fonts and styles across Google blogs - some do it one way; others do it another way. This may be acceptable as long as the level of UX remains at a common standard.
6. some of the best +Gmail Labs tools have remained in the Labs section for far too long. Many are the real assets of GMail and greatly improve UX but it's unfortunate that most average users will not be exposed to it because they are not being promoted. The evangelist team would have them on the radar and suggest them at some point.
7. Google Maps on +Android requires ~5 clicks, including throwing you out of the application completely, into the browser if you want to expand and read a restaurant review or go into further pages of reviews. This is probably the single greatest violation (I have found so far) of the great UX in a Google crown feathered Android app.
8. Setting the Android +Gmail app to 'notify once' as the default breaks the principle of over communicating. It is frustrating to a user to spend 20 minutes figuring out why they are not getting email notifications as opposed to offering an initial setup screen that allows the user to make his/her own preference for a setting with great impact.
9. Most people I know that have +Google Chrome have no clue of the Google Chat extension that is available - it a great tool that's not promoted enough. Thus, it is doing nothing to elevate the UX for Google+/Gmail chat web-clients. I would strategize to link to the extension (and any others) that enhance Google product experience in Chrome during setup or aggressively bundle them by default, just like Chrome background is currently forced upon installation.
10. There are hundreds more such small enhancements that I hope Google begins to take with a more eager eye. Google lost the battle of social in spite of having Orkut in their lap for all these years because it was ignored while they are also close to losing more ground to the on social photo sharing to competitors such as Instagram. I have some ideas but I think I would prefer to share them with a more appropriately focused group.

Ah.. this was a longer than expected post but I care for your future +Google ! :-)
+Felipe Fernandes - I know the hardware is slightly different to deal with Sprint's network, and the software contains the matching changes. Beyond that, I don't know the exact differences.
+Ananya Gupta - Wow, long post, much of which is far beyond the scope of AOSP.

On just a few points:

-Apple doesn't release iOS as Open-Source, so from there the question of licensing hardware-specific binaries never comes up.

-As for AOSP support, like I mentioned above, that has nothing to do with the retail name of a device.

Edit: - End-user updates don't fall under the same licensing constraints as AOSP.
Why not have a website that shows what is delaying/stopping ota updates of a specific GN variant? Then users would know who to complain to instead of writing in the comments on posts about AOSP.
Is there any chance Google will increase the speaker volume on the next update? Its always been way too quiet
+Ryan Simmons If you mean the in-call volume, it is baseband or the radio firmware issue. Not many phone manufacturers have got it right. Definitely not LGE for sure. Got tired of owning the world's first dual core LG Optimus 2X and pathetic in-call audio and moved to HTC One V. Nothing can beat the good old Nokia when it comes to making a phone that works as a great phone.
He means the loudspeaker (hands free / playing music etc) volume. It's a point raised in most reviews of the Galaxy Nexus.
Yeah I was talking about the loudspeaker. Its way too quiet and everyone seems to have the issue
+Ryan Simmons For increasing overall volume and if you are willing to try custom kernels, I would suggest Voodoo kernel. However, I am using not on Googne Nexus to give a feedback on Voodoo on it but have used it on LG O2X to increase the volume. I have heard +supercurio has done a good job on Samsung devices, worth exploring it.
Yeh I heard about Voodoo but I'd much rather just keep my phone completely stock. Thanks anyway though. It would just be nice to have a nice loud volume level by default. I too feel sorry for Mr Queru for everyone including me hijacking his post
+Afzal Najam - I've had a look at your change, but since I'm not a UI person at all I don't actually know whether that's a good change or not, I'll need the opinion of someone familiar with that part of Android.
+Johan Appelgren - That's not really my domain, since there's very little relationship between AOSP and updates for individual retail devices (beyond the very first one, which triggers the AOSP release). I can see how that'd help people understand where they stand, and specifically whether the fact that they're not running 4.0.4 right now is because of an issue on their side or simply because 4.0.4 isn't ready for their device yet.
+Ryan Simmons - Sorry, I don't know much (or usually anything) about specific details on individual features. Smartphones are so complex that it'd take too much of my time to track every possible change and I wouldn't be able to get any of my own work done.
+Jean-Baptiste Queru still confused, you mention carrier has no part in the aosp support of the handset. If we were talking the sgs 2 I'd agree with you but this is a Google phone. Branded by Google advertised as the pure Google experience etc. what does it say for purchasing the developers headset that you cannot develop on with support from Google. I could be misled thus far, but this isn't the only issue, both sprint and att 86ed the free tether support when Google demanded it be left alone seems like there are changes going on and the signature Google phone is just another handset to draw in the change no development significance to it. What's different now we can't get the binaries from Google like before and compile with those packages?
And switch to a carrier who doesn't allow me to actually use data there ya go!
On the AOSP front, even if your carrier is CDMA, you'll have better results with a GSM device than a CDMA one: at least you'll be able to call 911 in an emergency.
The Sprint Gnex shipped with 4.0.4. Wtf?
Yes. My question (I guess) is how the heck is aosp not supported. Is VZW playing big brother and blocking it? Wouldn't be the first time anyway.
+Joshua Russell no developing for it on your own isn't supported aosp must be tweaked by Verizon for its cdma code to work
Oh I gotcha. Thank you.
+Joshua Russell - I explained earlier in the thread that neither Sprint nor VZW have ever done anything to block AOSP support (nor any other carrier for that matter). There's no conspiracy.

The issue boils down to licensing the proprietary hardware-specific files that allow the device to run on those networks. Those files are more complex than similar files for GSM networks. Licensing them is therefore more complex, complex enough that so far Google hasn't been able to get a license for them that covers the AOSP use case.
That makes perfect sense. I apologize for not reading the whole thread. I have three little girls running around today. In the future I will refrain from commenting until I have read thoroughly. However, thanks for your excellent response and your maturity in pointing out my laziness. Heh
+James DeVesci - You won't get anything on your own network with any AOSP build (including LTE), no matter what, because none of the necessary files are available. With a GSM device, you still won't get any connection on your own network, so you don't lose anything on that front, but even without a SIM card you'll be able to connect enough to any GSM network in the area to be able to call 911.

Trying to put this another way: no Galaxy Nexus running an AOSP build can connect to a CDMA/LTE network, regardless of whether they have GSM/UMTS or CDMA/LTE hardware. From that point of you, you might as well work with a device that can connect to some networks, i.e. a GSM/UMTS one.
+Ananya Gupta "Google Wallet relies on IMEI/ carrier-based authentication and will not work without it."

Multiple posters have noted that Wallet works fine on their VZW Galaxy Nexus, even though VZW does not want it. Thus, it does NOT rely in carrier support, because it works despite the carrier's desires. What VZW has done is twisted Google's arm into not shipping in in the stock ROM, and hiding it in the Play Store.

Still, this isn't really an AOSP issue, but a Google Wallet issue. There was active discussion on these two posts:
as well as another that seems to have been deleted. We should probably take the Wallet discussion to one of those threads, since Wallet seems to be the cause of much of the off-topic "animosity against carriers" (mine included) that JBQ has noted.
+Jean-Baptiste Queru sorry if it's a noob question but...I flashed the 4.0.2 stock rom from google. When I enter in to the bootloader and in to the recovery appears a android with a red exclamation...It's this ok? maybe because of this I don't recieve the OTA...thank you everyone
+Jean-Baptiste Queru Thank you. Then I'll just wait for my IMM76D OTA. Or maybe just flash the 4.0.4 stock rom and loss all my data (again XD)
+Justin Moore - The Nexus name is related to the consumer experience, and has nothing to do with AOSP support. When I prepare AOSP support for a new device, I don't even know what that device's retail name will be.
So essentially all nexus means is that it ships with "pure" android aka no UI customization by the manufacture?
Thanks heaps for replying to us Jean-Baptiste Queru :)
+Jean-Baptiste Queru You say "the Nexus name is related to the consumer experience, and has nothing to do with AOSP support", but my consumer experience with a CDMA Nexus is that I have to root and rom to be on the same/latest version of the OS as my GSM Nexus. Thus making my "consumer experience" completely different. Please explain why Google insists on pushing the Nexus name onto devices that in all reality are not.
+Matthew Sholtz - I'm a technical guy on the Open-Source side of things, I have no influence on branding or any other similar matters. Google has people who specialize in those matters, and I let them do their job and expect them to let me do mine.
+Jean-Baptiste Queru So in other words, you have no idea what the definition of a Nexus device is.

This is the second time you have replied to a question that I asked and told me that you just "trust" everyone else you work with to do their job. It is precisely because Google's own employees do not even bother to question or apparently even talk about what the company and it's other employee teams are doing that is cause for the mess that Android and the Nexus currently is. I had asked you before why the Nexus S 4G took four months to update to ICS when the Nexus S was updated by Google so soon after 4.0.3 source was released. You couldn't answer that either as it is apparently someone else's department and not of concern to you. You must be able to see how there could be some confusion as to what Nexus is when one is updated right away and the other is delayed for four months (even when the NS4G was directly advertised by Google as being the first to receive updates). When Google's own employees can not convey the definition of their own branding to their own co workers there is obviously a communication problem. So my question to you is how can the "every day" consumer understand what the Nexus moniker stands for when Google's own Android team employees do not know and can not explain it?

I am not trying to pick on you, but you are the only person that responds to Android users with real replies. Which directly calls into question Google's poor customer service, but that can be a conversation for another time.
+Jean-Baptiste Queru +Matthew Sholtz Unfortunately, there doesn't seem to be any reliable gateway to reach the Android/ Nexus line/experience team. They are notoriously missing a Nexus Google+ page (looks like +Vic Gundotra has not yet whipped them into creating one) and their Google Group is utterly useless where they randomly choose to only provide the most trivial solutions.

Is there a team/person here on Google+ where our questions and concerns might be better directed?

PS Apologize for the thread hijack - you're clearly an awesome guy replying to our random questions around the Nexus line :-)
To be fair it's not jbq's department he's managing aosp supported devices and doing a damn good job at it. The most communicating employee at Google with the development community. standing back, he's getting shit for this post when it's really him staying protocol. It def leaves questions jbq but don't let it get to you we're all anxious which is never positive lol
+Ananya Gupta - My best guess on Google+ would be to reach the Android page itself. Their most recent post is about Sprint Galaxy Nexus. I suspect there's no Nexus page simply because there wouldn't be enough activity to justify such a page (just like there isn't an AOSP page).
J Agnew
I love living on the bleeding edge.
I'm no developer (but I did sleep at a Holiday Inn Express last night).
fwiw I read all the posts here. My question goes to anyone interested in holding my hand.
If I'm going to root and run custom ROMs (such as CM9) would I, an end user, be likely to notice that CMDA Nexi (or any other rooted CDMA device) are not supported in AOSP? I understand that question might be hard to answer since no one can know what experiences are important to me.
+J Agnew When CM or similar adds support for it you will probably not notice the lack of AOSP support that much, no. You can also disable root in CM9 if you don't want it.

To get a feel for how it has currently affected CDMA devices you should look at the Verizon GN, ie. toro. Granted, there are some binary blobs released officially for that but the ones that differ should most likely be possible to pull from the official Samsung/Sprint updates. That is assuming that the CDMA blobs are similar.
+Jean-Baptiste Queru, several users (myself including) are reporting some issues on IMM76I, for example eventual signal lost (not as frequent as the IMM76D) and 3G/Wi-Fi connection lost, a lag on unlock screen...

Are you aware about those issues? Corrections for them are on the way?
Oh, and issue #28291 is regarding the unlock screen lag issue.
+Jean-Baptiste Queru, I'm watching closely that topic I've mentioned in my previous reply (at http://code.google.com/p/android/issues/, issue # 28133) and another 8 different users reported the same issue in the last 2 days.

There's any other channel where I should report officialy this issue to google? It seems to me that this is not an isolated problem and I would be glad if I could help somehow in order to have the issue fixed asap.

Thanks for the attention!
I got it. But unfortunately this forum you've suggested does not seem to have enough information about this issues I've mentioned.

Any other suggestion?
+Jean-Baptiste Queru Hello; I apologize if this question is being posted in the wrong thread/has already been answered, however I was curious about what licensing issues (if any) the newer LTE technologies represent. In other words, is their a realistic possibility of an LTE device gaining AOSP support, or would licensing restrictions prohibit such an occurrence? Tank you for any response you are able to provide. 
+Mark Morrow - To be honest, it's hard to tell which way things are going to evolve. I'm not going make broad predictions, I'd rather work on every flagship device as it comes and support every device that can be reasonably be supported. We'll see how things go.
Feel pretty dumb buying the Sprint Galaxy Nexus thinking I would have full support from Google. Luckily, I have already unlocked my bootloader and flashed CM9. Thanks +Sprint for ruining this for me.
+Jean-Baptiste Queru I would like to know, in all likelihood, will there be any images for the Sprint Galaxy Nexus? I know AOSP support isn't there for it due to licensing issues, but, (as my second question) could you potentially explain to me why the Galaxy Nexii on CDMA are so restricted? Pardon my ignorance, I've worked with building from source for a while but never had any of these scenarios rear their ugly heads.
+Ryan West - Factory images for the Sprint Galaxy Nexus are up to Samsung.

As for your other question, the only restriction that's fundamental to CDMA is the licensing of the proprietary network binaries: those binaries tend to belong to multiple companies, which makes them hard to license, and at the same time they're implemented in ways that require broad license terms, which makes them hard to license.
+Jean-Baptiste Queru That's fantastic. So, as a result of them not being AOSP, that's why you have to wait on carriers to provide the images? In addition to that and in the vein of that line of thought, did the AOSP team have similar difficulties with AOSP and the NS4G?
+Ryan West - For licensing reasons, factory images are tied to the matching consumer OTA updates.

Indeed, I had similar difficulties for NS4G in AOSP. As originally planned, I had been told that the Sprint network implementation would be manageable and temporary, which is why I had originally attempted to support it in Gingerbread. It ended up being more complex than planned, but since that complexity was supposed to be temporary I decided to proceed anyway, hoping that IceCreamSandwich would fix that. When IceCreamSandwich didn't fix that complexity, I decided it was time to stop sinking time into it.
+Jean-Baptiste Queru in which case, is it possible for a consumer to produce images similar, if not identical in function, to the ones presented at the Google page here? Perhaps using fastboot?
+Ryan West - It's possible on the GSM Nexus S, and an AOSP build on that hardware should present itself to applications with the same system functionality as a retail build.
I know this is likely a old dead horse but I see that Verizon is now listed on ASOP but Sprint is not. What changed for Verizon and what can we do to get Sprint to join in on the fun?

Or has Verizon always been in ASOP ?
Add a comment...