Original Link: http://www.anandtech.com/show/5310/samsung-galaxy-nexus-ice-cream-sandwich-review
Samsung Galaxy Nexus & Ice Cream Sandwich Reviewby Brian Klug & Anand Lal Shimpi on January 18, 2012 1:34 PM EST
The evolution of Google’s Nexus line is an interesting one. Each year, Google chooses both a silicon partner and an OEM to make a unique hardware archetype which it caters a specific build of Android to. We've been playing with the latest Nexus - Android 4.0 on both the GSM/UMTS and CDMA/LTE Galaxy Nexus - for a while now and have put together a comprehensive review of all three. First, our thoughts on Ice Cream Sandwich and Android 4.0, and after that, a review of both devices.
Read on for the full review.
Google employs more than 20,000 people worldwide and the number of them working on Android are in the single digit percentage range. Google's business is search, but it has always had aspirations of more. Android isn't just a chance to capitalize on mobile search for Google, it's also an opportunity to grab power in the next era of personal computing. If you believe that smartphones will eventually replace mainstream PCs, who wouldn't want to be to smartphones what Microsoft was to PCs in the early 1990s?
Previous versions of Android have been cautious, evolutionary steps along a path to being a more open/flexible alternative to iOS. Starting with Honeycomb (Android 3.0) however, Google began to step out of the shadow of its competitors and really start to define Android as a mobile computing platform. Honeycomb was limited to tablets but its successor, Ice Cream Sandwich (Android 4.0), would bring unification to Android across both tablets and smartphones.
Today we look at both ICS and its launch vehicle, Google's Galaxy Nexus.
The Android vs. iOS Debate
It's very clear to me now more than ever that Apple and Google have completely different goals with their mobile OS strategies. Excluding the unclear strategy behind Chrome OS, Android is pretty much Google's primary operating system. The unified tablet/smartphone strategy behind Ice Cream Sandwich makes sense because for Google to succeed in the OS business it needs to deploy Android on everything from smartphones to notebooks. We've already seen the strengths in having a smartphone platform with a strong app ecosystem. Things become even more appealing if you have a phone, tablet and PC that all run the same OS and apps. As Android is Google's one-size-fits-all operating system, it needs to have a broader and slightly more ambitious focus than iOS otherwise it risks losing the race in the long run.
Apple is in a different position. It already has a successful desktop/notebook OS that is continuing to grow. While iOS has been a runaway success for Apple, the Mac OS X platform is a solid option for any user who needs more than their iPhone or iPad can provide. The two OSes may converge or at least borrow heavily from one another, but in the interim they can remain independent. If you need more of a computing experience Apple is happy to sell you a Mac. If you want the it-just-works appliance experience in your phone or tablet, Apple has a whole bunch of iPhone/iPad configurations to offer you.
ICS isn't a step towards iOS. If anything it proves that Google is committed to its own trajectory. Android is an OS that, although more closed than many would like, still allows more flexibility than iOS. You can sideload apps not purchased in the Market. The file system isn't completely hidden from you. You can even override the default zoom level on web pages. Apple and Google both pour tons of time and research into figuring out the best way to do something. And, to be honest, I feel like Apple generally does a better job of "getting it" for the very mainstream consumer. Rather than attempt to make the perfect mold however, Google gives you one that's a bit more flexible.
I've said this before but I do believe that Apple is trying to deliver more of an appliance experience, whereas Google is providing you with a modern take on a traditional computing experience. If the appliance is a smartphone, then both approaches are equally capable - it's just a matter of personal preference.
What's new in ICS really falls into one of three categories:
- Improvements in UI frame rate due to OpenGL ES rendering (non-skia) path
- UI tweaks
- New features
Nowhere in this list is a fundamental change in the way Android works. I feel that this is a very important point to understand and likely the cause for lots of disagreement when it comes to just how impressive (or not) ICS is.
ICS is smoother, more polished and has its own set of new features that make it a significant step forward for Android. What ICS is not however is an outright clone of iOS. If you prefer the iOS experience to Android, ICS will do nothing to change your opinion. If all you were missing from Android was a smoother UI, then its fourth major release should be almost everything you could ask for.
OS-Wide OpenGL ES Rendering
Although smartphone and tablets still lag behind the technology we have in modern day PCs by several years, their evolution is a highly accelerated version of what we saw in the PC industry. It took decades to go from the first GUIs to the GPU composited and accelerated UIs we have on the desktop today. Android has made a very similar transition in just three years.
Prior to Honeycomb, the majority of screen drawing in Android was done using its skia libraries. These libraries were almost exclusively CPU based and did very little work on the GPU. Over time Google rewrote key elements of Android to use new OpenGL ES rendering paths instead of skia for screen drawing. We saw the first major transition in Gingerbread where parts of the OS became GPU accelerated, but things like the browser were still being rendered to the screen using skia. Honeycomb was a significant step towards GPU accelerated drawing, and ICS all but completes the transition. The other component is the drawing model, which is completely revamped in 3.x and above.
From Romain Guy's Android Accelerated Rendering Google I/O 2011 Presentation
Honeycomb based tablets were significantly smoother than Gingerbread devices but even they showed some UI performance issues depending on what you asked of them. We later found out that this was a Tegra 2 limitation, something that would surely contribute to NVIDIA not being chosen as the lead SoC partner for ICS.
Also from Romain Guy's Android Accelerated Rendering Google I/O 2011 Presentation
With Ice Cream Sandwich, the OS, browser and all first party apps are OpenGL ES accelerated. The result is absolutely noticeable. App launches, scrolling and window transitions are all buttery smooth. Web browsing is unbelievably smooth and easily comparable to iOS and Windows Phone at this point.
Third party apps have to opt-into the OpenGL ES rendering path, which will likely require an update for those apps that haven't already done so. Google also provides the handy option of forcing all apps to use GPU accelerated apps and ignoring the opt-in (hardwareAccelerated="true" from the AndroidManifest.xml file). The obvious downside is not all third party apps will work gracefully with hardware acceleration enabled, though most do right now. The Southwest Airlines app, for example, will crash as soon as you try to check into a flight if you force GPU accelerated drawing, and Speedtest.net shows a blur for its line graph of throughput during the test. Google has outlined the draw operations that are unsupported in 3.x and 4.x already, which thankfully aren't many.
While it would be nice for Google to allow GPU acceleration settings on a per application basis, the truth of the matter is that many of them work just fine. Those that don't work are likely a simple update away from getting on board, otherwise they risk obsolesce as more platforms get ICS in the future.
If the sluggish UI held you back from Android in the past, ICS almost completely addresses the issue. I say almost completely because there are still some minor hiccups and a couple of more reasonably sized problems with the OS' responsiveness.
The biggest issue for me is the delay when operating any of the ICS buttons: back, home or the task switcher. While tapping a folder on any of the home screens results in an instantaneous display of its contents, hitting any of the three ICS buttons just isn't as responsive. There's a noticeable delay between when you hit the home button and when you actually appear back at the home screen. It's a delay that's, at least in my opinion, a bit too long. More frustrating is the delay in bringing up the list of recently used apps. It's less than two seconds but it should be in the milliseconds.
I monitored CPU usage while bringing up the task switcher and saw a small spike in CPU usage (~15%) and an associated increase in clock frequency, but nothing significant enough to lead me to believe we're CPU bound here. If anything I wonder if this is a GPU performance limitation similar to what we saw with Tegra 2 and the app launcher on Honeycomb. Given the incredible resolution of the Galaxy Nexus' display and the fact that we're still dealing with a 307MHz PowerVR SGX 540, it's quite possible that the platform just needs a faster GPU. I'm curious to see how well Tegra 3 will do here.
The UI: Holo Evolved
When I first met Holo, Google's Honeycomb theme, I wasn't convinced that it was something that would last. It was different, which earned Google points for sure, but it wasn't exactly comfortable. I was surprised to see an evolution of Holo used in ICS, but the theme has grown on me.
Ice Cream Sandwich feels a lot like Android meets Windows Phone. Part of that surely has to do with the very contrasty nature of the theme, but it's also the choice of font (Android 4.0 replaces Droid Sans with Roboto) and hard edges sprinkled throughout the UI. Holo is still distinctly Android in that there are still multiple home screens with support for widgets, but it's also different. Ice Cream Sandwich is Android maturing, it's the second implementation of Holo allowing us to finally plot a trajectory for where Google sees this thing going in the near term. It's different as I mentioned before. Holo and ICS aren't iOS nor does it look like they ever will be. The UI is either going to pull you in or turn you off. I like it. It's different, it's clearly a play on the whole Android theme; it's the type of UI you'd expect from an OS named after a robot.
Droid Sans v. Roboto (ICS)
At the same time it's no longer awkward. Elements of the design and many of the first party apps are just clean. It's truly a first class citizen. Different than both iOS and Windows Phone, but with a design that's just as credible.
The core of Android remains unchanged. You get multiple home screens (five by default) that you can populate with shortcuts, widgets or folders. Widgets are resizable just as they were in Honeycomb. Shortcuts work the same way they always have, while Folders get a nice update in ICS. Drag any icon on top of another one and they'll create a folder. Folders are quick to open and easy to rename, just tap on the name of any open folder and type away.
The app launcher gets a bit of a facelift. Instead of an endless scrolling cube, you get pages of apps that you flip through. Once you've reached the end of your pages of apps you'll start flipping through widgets. All of this is smoother than it has ever been on Android.
|Gingerbread vs. Ice Cream Sandwich|
|Gingerbread||Ice Cream Sandwich|
The New Contextual Menu Button
Play around with ICS for a little bit and you'll quickly pick up on a new UI element that appears inspired by Windows Phone:
These vertically oriented ellipses will appear at either the top or bottom of an app and reveal additional menu options.
In Gingerbread you had the fixed Android menu button, but with that gone you have to rely on these contextual menu buttons to bring up additional actions. I'm honestly pleased with the move because all too often I'd forget to tap the menu button to see whether or not there were additional options in Gingerbread. ICS makes it very obvious when there's more you can do.
The Task Switcher
A cornerstone of any good operating system is a good task switcher. I still believe that webOS dealt with the concept of individual apps and switching between them better than any other mobile OS, but it looks like that platform is pretty much dead with little chance of making it into the top three mobile OSes.
Google and iOS haven't traditionally focused much on task switching, although both have provided support for it. In Gingerbread, you'd switch between apps by holding down the home button, which brought up a list of up to eight of your most recently used apps. Ice Cream Sandwich implements a drawer-style app switcher menu, first introduced in Honeycomb, activated by hitting the dedicated task switcher button:
|Gingerbread vs. Ice Cream Sandwich|
|Gingerbread||Ice Cream Sandwich|
The Gingerbread method of switching may be quicker, but it's definitely not as useful as what ICS offers. For starters you can switch between more than just six apps in ICS. The most recent apps are located at the bottom of the list, the oldest at the top. You can also quit apps using the switcher by sliding them to the left or right. Doing so immediately frees up any memory the app was using, even if it was suspended.
Scrolling through the list of recent apps, like scrolling pretty much anywhere in ICS, is extremely smooth. The only real complaint I have here is that the task switcher takes far too long to draw initially. As I alluded to before, this is something that may get better with a faster SoC, particularly one with a faster GPU.
The Shade & Notifications
Notifications in ICS are still handled via the status bar at the very top of the screen and a pull down notification shade. The shade in ICS is partially transparent by default and once again, very smoothly animated. The network carrier string is included at the bottom of the shade rather than in the status bar at the top. You can clear notifications individually or hit the X to clear all of them.
I am surprised Google didn't borrow the quick settings options its partners usually like to stick in the shade, but there is a link to the system settings panel at the top.
Android 4.x also finally enables the ability to take screenshots from within the OS. There's no necessity for OEMs to bake-in their own screenshot functionality and key press combination, no need to connect using USB and fire up ddms, and no need to root and install some application to make it work. Traditionally, those three have been the exclusive way to get screenshots taken on Android.
To take a screenshot in Android 4.x, simply hold volume down and the power/lock button at the same time. An animation plays, you get a notification, and the screenshot is saved (with a timestamped name in PNG format) in /pictures/screenshots as shown above.
I can't emphasize enough how important being able to take screenshots is for a platform in general. Without screenshots, users can only vicariously share a given OS when they're in direct contact with someone else. Being able to take screenshots without all the nonsense I've outlined above is part of what has made iOS so ubiquitous online - browse Reddit and count how many screenshots of SMS conversations (trite as they all are) are clearly from iOS versus Android. It's clear to me that Matias Duarte understands this, since webOS and even the Danger Hiptop since day 1 had the ability to take screenshots. Now Android 4.x finally joins the fray.
The stock Gingerbread keyboard was a significant step forward, but the ICS keyboard is really good. I don't know that there's much that's truly groundbreaking about the ICS keyboard, but it's at the point where short of Swype for those users who care about it, I would be very disappointed to see any third party keyboard replacements from HTC, Motorola or Samsung.
The basic layout hasn't changed from Gingerbread, although there are a few subtle differences. You get the same standard four row keyboard with two alternate modes (numerics and symbols). Where the Gingerbread/ICS keyboards differed from the standard iOS or Windows Phone keyboard is there's a fifth row of punctuation keys by default above the rest of the keyboard. This fifth (or first, depending on how you look at it) row actively changes into a list of predicted words. The word in the center is what the autocorrect engine believes you're typing, while the words on the left/right are alternates. While Gingerbread allowed you to scroll horizontally on this row, the items are fixed in ICS. As a consolation, you can bring up additional autocorrect suggestions by tapping and holding on a word in the prediction row. Accented characters are available by pressing and holding on keys that can be accented. Popup menus also exist for punctuation and the smiley key.
Keypresses are still accompanied by a magnified duplicate of the key itself. Unlike in Gingerbread where the magnified key hovered unconnected, the ICS keyboard connects the magnified key to the key itself. In my opinion this makes the keyboard look less chaotic when you're typing very quickly. Rather than giving the impression of random letters flying around everywhere, the animation serves its intended purpose better: letting you know what you just hit.
There's also a hidden Android Keyboard debug settings pane with some different themes that can be selected.
|Gingerbread vs. Ice Cream Sandwich - Keyboard & Autocorrect|
|Gingerbread||Ice Cream Sandwich|
Android has historically offered multiple options to secure your phone or tablet. Ice Cream Sandwich continues the trend. You can choose a basic PIN with a minimum of four numbers and a maximum of 17. There's an alphanumeric password option, simple slide to unlock and no security at all. ICS adds a new option to the list: Face Unlock.
The feature is exactly what it sounds like. ICS can store a photo of your face and use it as authentication for unlocking your device. While you only need a single picture to start, Google recommends taking multiple photos in different lighting conditions, with/without glasses and with a clean vs. unshaven face if applicable. As a backup you have to provide ICS with a PIN in case it can't recognize your face (either due to lighting conditions or because of a recent tumble down some stairs).
Google warns that someone who looks like you would be able to unlock your device, making Face Unlock less secure than a long PIN, pattern or password. Admittedly a thief would have to either be really lucky or know what you look like to fool the technology, but it is a valid point.
The feature actually works surprisingly well in practice. With Face Unlock enabled the lock screen has a front facing camera live view window that you're supposed to use to center your face. With the exception of really bright (with the light shining into the camera) or really dim scenarios, Face Unlock worked for me almost every time. When it works perfectly using your face to unlock the phone is extremely quick. In the right conditions I've seen ICS unlock itself a split second after I even saw my face on the screen. On average though the process is slower than typing in a PIN or using any of the other unlock methods. Furthermore, if you use your phone a lot at night (especially in cars) you have to hit the power/lock button then tap the lock icon to circumvent Face Unlock and go directly to your PIN/password/pattern. Finally, don't try to use Face Unlock to unlock your phone while driving - that's a recipe for bad, or worse, death.
The browser in 4.x also includes essentially everything that made the browser in 3.x smooth as well. As opposed to the Android 2.x browser's immediate rendering system - which would redraw the page in its entirety as you zoomed and panned around and seem choppy as a result - Android 3.x/4.x now render tiles into a backing store for webpages. This is the same system that iOS, webOS, and Samsung's custom browsers use, and as a result panning and translating around is now just as smooth as it is in those platforms. To be totally honest, this is probably one of the single largest and most welcome improvements over Android 2.x because of how dramatic the difference is.
In Android 4.0 you can actually go inside the debug settings for the browser (enter about:debug into the address bar, enter, then a new settings pane emerges) and enable or disable OpenGL assisted rendering for the browser. With it off, it feels just like 2.x's choppy stock browser, and with it on, it feels buttery smooth like 3.x. The difference is beyond dramatic. This is actually a feature that was present in Android 3.x as well.
While companies like Motorola and Samsung backported parts of the Honeycomb browser to their own Gingerbread browsers, the stock Gingerbread browser needed work. ICS modernizes the Android web browser and finally removes the need for third party customizations, at least from a performance standpoint.
|Gingerbread vs. Ice Cream Sandwich|
|Gingerbread||Ice Cream Sandwich|
The ICS browser is still WebKit based and uses a much newer version of WebKit than what you'll find in Android 2.3.6. Compared to the latest Honeycomb browser however there's not all that much difference in version number. The ICS browser does still use an older version of WebKit than Mobile Safari in iOS 5.0.1:
|User Agent String Comparison|
|Device||OS||WebKit Version||UA String|
|Apple iPhone 4S||iOS 5.0.1||534.46||Mozilla/5.0 (iPhone; CPU iPhone OS 5_0_1 like Mac OS X) AppleWebKit/534.46 (KHTML, like Gecko) Version/5.1 Mobile/9A405 Safari/7534.48.3|
|Samsung Galaxy Nexus||Android 4.0.2||534.30||
Mozilla/5.0 (Linux; U; Android 4.0.2; en-us; Galaxy Nexus Build/ICL53F) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
|ASUS TF Prime||Android 3.2.1||534.13||
Mozilla/5.0 (Linux; U; Android 3.2.1; en-us; Transformer Prime TF201 Build HTK75) AppleWebKit/534.13 (KHTML, like Gecko) Version/4.0 Safari/534.13
|Google Nexus One||Android 2.3.6||533.1||Mozilla/5.0 (Linux; U; Android 2.3.6; en-us; Nexus One Build/GRK39F) AppleWebKit/533.1 (KHTML, like Gecko) Version/4.0 Mobile Safari/533.1|
HTML5 compatibility is fairly similar to Honeycomb, although a significant improvement compared to Gingerbread. If you haven't had any experience with Honeycomb tablets, the ICS browser will feel like like brand new technology.
|The HTML5 Test|
|Test||Apple iPhone 4S||Samsung Galaxy Nexus||Google Nexus One||ASUS Eee Pad Transformer||ASUS Eee Pad Transformer Prime|
|OS||iOS 5.0.1||Android 4.0.2||Android 2.3.6||Android 3.2.1||Android 3.2.1|
|Total Score||305 (and 9 bonus points)||256 (and 3 bonus points)||182 (and 1 bonus point)||222 (and 3 bonus points)||233 (and 3 bonus points)|
|Parsing rules||11 (2 bonus points)||11 (2 bonus points)||1/11||11 (2 bonus points)||11 (2 bonus points)|
|Video||21/31 (4 bonus points)||21/31||21/31||21/31||21/31|
|Audio||20 (3 bonus points)||20 (1 bonus point)||20 (1 bonus point)||20 (1 bonus point)||20 (1 bonus point)|
|History and navigation||5||5||5||0/5||0/5|
Performance and compatibility are obvious improvements, however there's much more to the ICS browser. For starters it implements tabbed browsing, a feature that has been available on Honeycomb but not in Gingerbread. Given the small screen size, tabs aren't immediately visible but are instead switched between after hitting the tabs button. The process makes sense and thanks to GPU accelerated drawing, scrolling through tabs is extremely smooth.
Google added quick user agent switching to ask for desktop versions of websites vs. mobile by default through a checkbox under settings. Enabling the option changes the browser's UA string from representing itself as a mobile Safari browser to Chrome 11. There's also a menu inside debug settings to change your user agent (UAString) to look like the desktop, iPhone, iPad, Nexus One with Froyo, or a Xoom with Honeycomb.
|User Agent String Comparison|
Mozilla/5.0 (Linux; U; Android 4.0.2; en-us; Galaxy Nexus Build/ICL53F) AppleWebKit/534.30 (KHTML, like Gecko) Version/4.0 Mobile Safari/534.30
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit 534.24 (KHTML, like Gecko) Chrome/11.0.696.34 Safari/534.24
Prior to ICS, the browser was a serious limitation of the Android platform on smartphones - it was choppy, and something OEMs continually replaced with their own (sometimes worse, sometimes better) browser. Granted you could always download and replace the browser with one of your own choosing, but for the mainstream user the Gingerbread browser was a problem. In ICS the browser is a blessing to use. It's very fast, smooth and compatible. We've had no problems using the Honeycomb browser and the same can be thankfully said about the evolution of it in ICS.
The standard Email app in ICS is an evolutionary improvement over what we saw in Gingerbread. The white text on a black background is now inverted to a much more modern looking black text on white background theme:
The UI and performance improvements give the email app a nice update, but there are some feature enhancements as well.
You can still select several emails at a time for starring, marking, moving or deleting. ICS no longer requires you to hit a menu button to bring up additional options or even to do something as simple as composing an email. All of the most commonly used functions are displayed at the bottom of the screen.
Deleting emails is still not as instantaneous as I'd like it. If you're deleting a small number of emails they'll all go at once after a bit of a delay, otherwise for long lists you'll see the emails slowly disappear.
In message view mode you can quickly reply to any message by tapping the reply arrow key, however to reply to all or forward a message you'll need to first hit the contextual menu button at the top of the screen (this is configurable, you can make reply to all the default action).
Quoted text in a reply is still neatly placed in a separate text box, which keeps your composition text box nice and clean. ICS adds support for quick replies, which are canned responses to emails that you define manually and can quickly insert.
Server side searching is finally supported, however it's fairly slow (slower than iOS at least). String matching in your search query also seems to be fairly strict so you'll have to make sure that the word(s) you're searching for are not immediately preceded/followed by other characters. You also can't specify where in the email (subject, address field, message text, etc...) you want to search, you just get a general search box.
Among the other first-party applications that are new in Android 4.0 is Gmail, which receives an overhaul that closely matches the client from 3.x. The update includes a dramatic makeover that minimizes use of the menu button for interaction. Instead, there’s a row of icons along the bottom for refreshing, composing, searching, and tagging Gmail conversations. If you make selections this row of buttons changes appropriately to mark read/unread and archive/trash items as well. At the very top is a drop down pane for selecting the current label or other inboxes.
On a smartphone sized device, Gmail now looks and feels a lot like the client from Android 3.x, except with menu and organizing befitting a smartphone. The improvement is dramatic and manages to leave the 2.x client feeling old and unintuitive. The only unfortunate thing is that in the message view, Gmail still lacks pinch to zoom functionality, making looking at emails composed with lots of HTML difficult. This is something that people have been vocal about since the Gmail in Android 2.x which surprisingly still is present.
Minor gripes aside, the Android Gmail application in 4.x yet again sets the bar for the best native Gmail implementation. I can’t go back to the 2.x client, and in comparison the iOS Gmail client seems like a cheap facsimile.
Android continues to offer configuration options within individual applications as well as centrally located system settings. Once again the lack of a dedicated, system-wide menu button forced Google to rely on a settings icon alone to get you to the system settings panel.
Although most of the configurable options remain unchanged from Gingerbread to Ice Cream Sandwich, Google completely reorganized the Android system settings page. What used to be a convoluted mess of items that weren't always placed logically has now turned into something far more sensible:
|Gingerbread vs. Ice Cream Sandwich|
|Gingerbread||Ice Cream Sandwich|
Location settings are now separate from security and there's now a dedicated backup & erase section. Subtle changes like these seem to make a lot more sense than the organization in Gingerbread. I find myself spending far less time staring blankly at the ICS settings menus than I did in Gingerbread. Let's hope Google's partners don't go in and shift things around too much.
ICS includes a complete set of cool developer options, above and beyond the ability to enable USB debugging. You can force GPU accelerated drawing system-wide, even in apps that don't explicitly request it. You can overlay CPU usage data on the screen, cause any part of the screen that has been redrawn to flash wildly and even mark up the screen with your last touch events:
Most of this isn't useful to an end user but for a developer or just someone who's curious, it's fun stuff. More generally applicable however is the ability to turn on a little circle that follows your finger around the touch screen similar to what's always used in touchscreen demo videos.
There's also official support for adjusting mouse pointer speed, an obvious inclusion for dockable tablets like the Transformer Prime.
Copying via MTP or PTP
With Honeycomb we saw Google treat tablets as Media Transfer Protocol (MTP) devices rather than traditional USB mass storage devices. For Windows users there was no difference as MTP is natively supported in Vista and 7. Mac users have to rely on third party support for MTP, which Google provided via its own free Android File Transfer application.
Given that Android exposes much of the file system to the end user, MTP is a safer bet for protecting against corruption from both Android and the connected Mac/PC modifying data on the NAND at the same time.
Business is as usual for Windows users as ICS based devices just appear as a drive letter thanks to native MTP support. If you want to access an ICS device as you would a camera (perhaps for a specific application), Google allows you to toggle between MTP and PTP (Picture Transfer Protocol).
The Galaxy Nexus - Hardware and Aesthetics
The evolution of Google’s Nexus line is an interesting one. Each year, Google choses both a silicon partner and an OEM to make a unique hardware archetype which it caters a specific build of Android to. We’ve now seen three Nexus handset designs from two OEMs and three silicon vendors - the Nexus One (HTC and Qualcomm’s QSD8x50), Nexus S (Samsung and Samsung’s S5PC110 ‘Hummingbird’), and today the Galaxy Nexus (Samsung and TI’s OMAP4460).
Looking at the hardware of those three handsets gives a great survey of the course the Android ecosystem has taken over the last couple of years. The Nexus One started things out with a 3.7” LCD, capacitive buttons, and hardware trackball. Nexus S then removed the trackball, added a curved 4.0” display, and ditched the microSD card slot. The Galaxy Nexus continues in that direction, increasing display size to 4.65” and resolution to 1280x720, and finally removing the capacitive buttons all together. Instead, the Galaxy Nexus uses a 96 x 720 region at the bottom of the display to visualize the navigational buttons, a move that has the consequence of also keeping the display interaction area aspect ratio close to that of WVGA.
It’s interesting to see how many of the design motifs set by the original Nexus One still have been thoughtfully preserved on the Galaxy Nexus. The notched chrome ring around the camera aperture has continued as a thread for three generations, as has the overall lightly rounded shape. The Galaxy Nexus also retains the chin from Nexus S backside where the speakerphone port and primary cellular antennas are located. In addition, the volume rocker, power/lock button, headphone jack, and primary microphone position from the Nexus S is unchanged.
The Galaxy Nexus’ backside is no longer the extremely slippery and scratch prone plastic that the Nexus S (and original Galaxy S) adorned, instead it’s a textured, lightly soft touch material. I’m always surprised by how much of a difference changing the backside texture makes on the overall in-hand feel impressions I come away with, and in this case it’s a major positive change. It’s clear that this is an evolution of Nexus more than a huge departure from what’s come before - if anything the Galaxy Nexus is like a larger, thinner, more refined Nexus S.
We’ve taken a look at both the CDMA/LTE (codename mysid/toro) and the GSM/UMTS (codename yakju/maguro) Galaxy Nexus variants.
The two differ beyond just the air interfaces they support slightly in the physical department as well, though the two share all the same other features (SoC, display, camera, etc.). The CDMA/LTE Galaxy Nexus is ever so slightly thicker than the GSM/UMTS Galaxy Nexus, though the difference is enough to be perceptible.
In addition, the two have the same exterior “titanium silver” color, no doubt the differences we saw earlier can be attributed to the difference between renders and the real deal. The other small detail is that the two use very different, non-interchangeable batteries - the GSM/UMTS variant uses a 6.48 Whr battery, the CDMA/LTE version gets a slightly larger 6.85 Whr battery. Both of these include the NFC antenna patterned the outside surface of the battery, just under the sticker.
Other than those subtle differences, Samsung has done a good job masking the challenges which underlie having two superficially similar phones with different cellular architectures. The two variants do feel different in the hand, but the difference isn't dramatic.
|Apple iPhone 4S||Samsung Galaxy S 2||Samsung Galaxy Nexus (CDMA/LTE)||Samsung Galaxy Nexus (GSM/UMTS)|
|Height||115.2 mm (4.5")||125.3 mm (4.93")||135.5 mm (5.33")||135.5 mm (5.33")|
|Width||58.6 mm (2.31")||66.1 mm (2.60")||67.94 mm (2.67)||67.94 mm (2.67)|
|Depth||9.3 mm ( 0.37")||8.49 mm (0.33")||9.47 mm (0.37")||8.94 mm (0.35")|
|Weight||140 g (4.9 oz)||115 g (4.06 oz)||150 g (5.3 oz)||135 g (4.8 oz)|
|CPU||Apple A5 @ ~800MHz Dual Core Cortex A9||1.2 GHz Exynos 4210 Dual Core Cortex A9||1.2 GHz Dual Core Cortex-A9 OMAP 4460||1.2 GHz Dual Core Cortex-A9 OMAP 4460|
|GPU||PowerVR SGX 543MP2||ARM Mali-400||PowerVR SGX 540||PowerVR SGX 540|
|RAM||512MB LPDDR2-800||1 GB LPDDR2||1 GB LPDDR2||1 GB LPDDR2|
|NAND||16GB, 32GB or 64GB integrated||16 GB NAND with up to 32 GB microSD||32 GB NAND||16/32 GB NAND|
|Camera||8 MP with LED Flash + Front Facing Camera||8 MP AF/LED flash, 2 MP front facing||5 MP with AF/LED Flash, 1080p30 video recording, 1.3 MP front facing||5 MP with AF/LED Flash, 1080p30 video recording, 1.3 MP front facing|
|Screen||3.5" 640 x 960 LED backlit LCD||4.27" 800 x 480 SAMOLED+||4.65" 1280x720 SAMOLED HD||4.65" 1280x720 SAMOLED HD|
|Battery||Internal 5.3 Whr||Removable 6.11 Whr||Removable 6.85 Whr||Removable 6.48 Whr|
The SoC: TI's OMAP 4460
The launch platform for Ice Cream Sandwich was TI's OMAP 4460. Unlike previous Android releases however, it seems that other SoCs will see their ICS ports done in a much quicker manner. It took a very long time for Honeycomb to be ported to other SoCs, whereas a number of companies have already demonstrated ICS running on their hardware (e.g. Intel, NVIDIA). If this is the case going forward, the launch vehicle for a new Android version may not mean what it used to.
The OMAP 4460 is a fairly standard, yet full featured dual-core ARM Cortex A9 SoC. You get two A9 cores complete with MPE (NEON support), behind a shared 1MB L2 cache. The SoC features two 32-bit LPDDR2 memory channels as well. The GPU is provided by Imagination Technologies in the form of a PowerVR SGX 540.
Max clocks for the OMAP 4460 are 1.5GHz for the CPUs and 384MHz for the GPU. As with all SoCs, all final clocks are OEM customizable to hit their desired point on the performance/battery life curve. Google and Samsung settled on 1.2GHz for the cores and 307MHz for the GPU, both exactly 80% of the OMAP 4460's max frequencies. Sprint recently announced its Galaxy Nexus would run at 1.5GHz. It's quite possible that we'll see a jump in GPU clocks there as well since the two may run in lockstep.
From a CPU standpoint the 4460 is competitive with pretty much everything else on the market (A5, Exynos, Tegra 2, Snapdragon S3). The 4460 does have more memory bandwidth than Tegra 2, Tegra 3 and Snapdragon, but it's comparable to Apple's A5 and Samsung's Exynos 4210. It's the GPU that's a bit dated at this point; the PowerVR SGX 540 typically delivers Tegra 2-class performance. A quick look at GLBenchmark and Basemark results echoes our findings:
At 720p, which happens to be the GN's native resolution, the OMAP 4460 is much faster than Tegra 2. It's also important to note just how much faster Tegra 3's GPU is by comparison.
I understand why Google didn't wait for a Krait based SoC, however I don't believe the OMAP 4460 was the best bet given the launch timeframe of the Galaxy Nexus. Based on performance alone, Google should have picked Tegra 3 as the launch platform for ICS. GPU performance is much better than the SGX 540 and there's comparable CPU performance. It's possible that Google needed the memory bandwidth offered by OMAP 4, but we'll find out for sure soon enough as the first Tegra 3 device (ASUS' TF Prime) is slated to get ICS this week.
I'm also less concerned about power consumption being an issue since NVIDIA added full power gating to all of the cores in Tegra 3. With a conservative enough power profile Google could have guaranteed battery life similar to OMAP 4460 out of Tegra 3.
I get the feeling that Google wasn't very pleased with NVIDIA after Honeycomb and chose to work with TI this time around for reasons other than absolute performance. If it weren't for the fact that Tegra 3 and other SoCs appear to be getting ICS in fairly short form I'd be more upset over this decision. To be honest, the choice of SoC simply hurts the Galaxy Nexus as a phone. If I were you, I'd wait for a Krait based device.
Camera - Stills and Video
For whatever reason, the Nexus line has never been synonymous with good camera quality. The Nexus One, Nexus S, and now Galaxy Nexus have shipped with 5 MP rear facing cameras, and though quality has increased with each generation, optical quality has never really been cutting edge. The Galaxy Nexus again sports a 1.3 MP front facing camera and 5 MP rear facing camera with an LED flash.
When I learned that TI had been selected as the silicon partner for Android 4.x, one of the first things that struck me was that it was highly likely they’d turn around the stigma that Nexus doesn’t care about camera quality. TI has traditionally had great ISP in their SoCs, and we’ve seen good things out of OMAP4 in the past. The fruits of that collaboration manifest themselves in a few places on the Galaxy Nexus, but the most obvious is the device’s instantaneous capture functionality.
The feature is simple - tap the camera button and you capture a full size 5 MP image of the 960x720 preview frame being displayed. No doubt, ISP is simply capturing a buffer of images constantly, and when you tap on the capture button you grab the current one. It works extremely well in practice, you can mash the button pretty fast. I recorded and measured a capture speed of ~2.7 FPS, which is pretty darn impressive for a smartphone.
There’s no preview after capture, though you can now tap the small thumbnail and get a full screen preview of the last captured image without leaving the camera app.
There are also options to quickly send the image off to some social services based on their own intents.
It’s worth talking about the sweeping positive changes that have been made to the entire Android camera UI as well. If you played the audio sample above, you’ll notice that the guillotine-sounding capture sound from Android 2.x has now been replaced with a much better tone. The rest of the UI now looks and feels accordingly less hokey. Iconography rotates immediately based on orientation, and all the menus feel fluid.
Under settings for still capture are options for flash mode, white balance, manual exposure, some shooting modes, and inside the expanded menu picture size (5MP, 3MP, 2MP, 1.3MP, VGA, QVGA) and an option for whether or not to store geolocation information. On the front facing camera you get auto white balance, exposure, scenes, and shooting sizes of 1.3 MP, VGA, and QVGA.
The capture preview also fully implements tap to focus and expose, and tracks faces around if in the scene. I noted a small change between 4.0.1 (no doubt the result of what was noted in some other reviews) - pressing and holding the capture button no longer toggles an AF/AE run, instead still image capture runs continuous auto focus just like video. To actually verify focus, your only option is tapping to focus. I feel like this does make some sense if you interpret instant capture liberally - obviously you still need to focus - but it does break the capture button paradigm that’s been established for a super long time. Just make sure you’re focused before tapping the capture button.
The other cool new feature is a panorama mode, which is now directly incorporated into the Android camera UI. Switch into this mode, and the preview window becomes smaller, but now enables you to shoot panoramas. Hit capture, and you can pan to create an image up to 3936 pixels wide by about 700 pixels tall. I created two and tossed them in our miscellaneous gallery. In this shooting mode there aren’t any options at all, but the functionality produces some pretty impressive looking results.
I mentioned that TI clearly worked with Google on developing both the instant capture and other ISP related features, and after a bit of poking figured out how. We’ve talked about OMAP4 before, and its dual Cortex-M3 subsystem. In OMAP4, these Cortex M3s are used for ISP related functionality (TI calls this its Imaging SubSystem - ISS), and by default both run a realtime operating system of their own that works together for still image compensation, ISP, and display subsystem control. Inside /system/vendor/firmware is a 4.5 MB file named “ducati-m3.bin” which contains many camera related references, including the names and types of what I believe are the two Samsung CMOS sensors used in the Galaxy Nexus. Regardless, this file no doubt contains the realtime OS which runs on both Cortex M3s.
core0: 1.00.09.44xdctools_3_22_01_21ipc_1_23_01_26bios_6_32_01_38TI_CGT_TMS470_4.9.0core1: TI-MM-DUCATI_RLS.02.00.00.00-818-ga636360xdctools_3_22_01_21codec_engine_3_21_00_13_engipc_1_23_01_26osal_1_21_00_05_engbios_6_32_01_38TI_CGT_TMS470_4.9.0xdais_7_21_00_01_engframework_components_3_21_00_17_eng
And much later on, we have endless references to what can only be the two CMOS sensors used in the Galaxy Nexus - the rear facing 5 MP Samsung S5K4E1G and front facing 1.3 MP S5K6A1G. The rear facing S5K4E1G is a 1/4” front side illuminated sensor with 1.4µm pixels and a capture size of 2608 x 1960, and the front facing S5K6A1G is a 1/6” front side illuminated sensor with 1.75µm pixels and a capture size of 1280x1024. I’m pretty certain that the rear camera also is a 4P (4 plastic elements) system with a focal length of 3.37 mm, F/# of 2.8, and a diagonal field of view of 68 degrees.
Update: ChipWorks has put the Galaxy Nexus CMOS under their x-ray machine and seen S5K4E5 markings, which is the equivalent (same specs) backside-illuminated counterpart to the S5K4E1 I outlined above. Our findings were from decompiling 'ducati-m3.bin' which contains references to S5K4E1 and no references to S5K4E5, however. Given the similarities it's possible the two share the same driver platform, and hence we see this behavior inside the ISS code.
Unfortunately with specs like those it’s very apparent that having a high-end sensor and optical system wasn’t the highest of priorities. That said, the Galaxy Nexus does have some great ISP and camera features, it’s just curious that there isn’t a better 8 MP module or at least a BSI 5 MP module in the current one’s place.
So what does still image quality end up looking like? To evaluate the Galaxy Nexus’ camera, we turned to our lightbox tests with the lights on and off, outdoor testing at our test locations, and the new semi-revamped camera tests with the ISO12233, distortion, and color checker charts.
In the lightbox tests with the lights on the Galaxy Nexus honestly surprised me with very sharp high frequency features, good dynamic range, and decent white balance/saturation. There’s some sensor noise even in this well lit scene, but nothing too crazy. Though the 5 MP sensor is FSI, it does include all the CMOS features (like correlated double sampling) that are a huge part of reducing noise. For a 5 MP shooter the Galaxy Neuxs looks shockingly good in our lightbox test with the lights on.
With the lights off the Galaxy Nexus (and Android 4.0’s camera application) correctly preflash and illuminate the scene for autofocus. We get a nicely focused and exposed image in the complete dark here, though noise reduction is clearly turned all the way up and there’s some obvious blurring from noise-mitigation, but overall again not bad at all. I’m also impressed with how even the illumination is - Samsung put a nice diffuser/fresnel lens on their single LED flash.
In the more controlled testing, I think we get a sense for how good the ISP is. The GMB color checker card looks pretty decent, and in the distortion plot we see minimal distortion (though that’s really nothing special for an F/2.8 system). In the ISO 12233 chart I can see up to the 13 line in the tangential and saggital direction, and find that thankfully Google/TI didn’t subject themselves to the sharpening kernel that Samsung usually implements. On 8 MP shooters, we can obviously recover more spatial frequencies (up to the 17 line) but the Galaxy Nexus doesn’t do all that bad here.
Next up are our outdoor smartphone camera test locations, of which 3-7 remain available and refreshed each time we get a new device. Note that although I spend a lot of time trying to make sure lighting is roughly the same, seasons do change and there’s going to be some variance in here purely due to it being outside.
Performance in locations 3, 6, and 7 looks very good. In 4 and 5 I can’t shake the feeling that the Galaxy Nexus produced very undersaturated and lifeless looking images, however. There aren’t any problems with sharpness at all in any of the images, though we’re talking about a shooting environment with ample daylight lighting the scene.
I also took many miscellaneous photos with the Galaxy Nexus (both variants) and tossed them into a gallery below. In real world shooting I encountered many more poorly lit indoor environments where you can really see the noise (and noise mitigation features) kick into overdrive. The burger photo with and without flash is particularly telling, as I took this in the same position with flash on and off.
The Galaxy Nexus’ camera is definitely not the best around, but if you do a lot of outdoor shooting in good lighting environments, the Galaxy Nexus is competent enough to get the job done. It’s really only in low light scenarios indoors or at night where its CMOS sensor really shows its age and can struggle, especially if you shoot without flash. It is very confusing why the Galaxy Nexus includes such a lower-end CMOS sensor considering the device's positioning as a super high end smartphone.
That said, what is awesome are the improvements that Google has made to the AOSP camera application, which show a phenomenal amount of polish and careful thought. The new UI is a huge jump forward from the camera application in 2.x, which never felt quite right. New features like instant capture and a much better organized UI really help the shooting experience feel awesome on the Galaxy Nexus, even if it isn’t driven by the most expensive sensor in the world.
How the Galaxy Nexus captures video is the next important thing, and there are a few more awesome features here that are part of ICS.
First off, the Galaxy Nexus captures H.264 video in 1080p24 at 9.6 Mbps baseline with 1 reference frame. 720p video is captured at 30 FPS H.264 at 8 Mbps baseline. Audio is single channel AAC at 96 kbps and 48 kHz. It’s a bit odd and disappointing to see video being captured at just 24 FPS, baseline, and such a comparatively low bitrate to boot (other devices are shipping with 15-18 Mbps High Profile or 24 Mbps baseline). To date I haven’t seen any smartphone cameras capture at anything but 30 FPS, as well.
What’s puzzling is that OMAP4460’s encoder is capable of much more than these settings. I feel like yet again we have a Nexus that isn’t quite at parity with the video encoder quality of other devices, though this time around the device does shoot 1080p at the very least.
To gauge quality we took videos at our smartphone bench video location and shot some videos. I originally shot all my bench videos on the GSM/UMTS Galaxy Nexus running 4.0.1, and noticed some interesting behavior in the resulting video. Those are all still live, though I shot another video to highlight exactly what this behavior is and have seen some other end users note it and question what’s going on. It appears to be some overly aggressive electronic image stabilization or perhaps a rolling shutter correction firmware bug, but either way this behavior has been fixed in Android 4.0.2 and above. The videos below have been re-shot running Android 4.0.2 accordingly.
1080p24 Video Sample
720p30 Video Sample
720p30 Front Facing Video Sample
In addition, the videos have been uploaded in their original form in a big zip (136 MB) if you want to watch without YouTube’s transcode.
The 1080p video quality is decent, though you can see some encode artifacts from the lower bitrate, and honestly 24 FPS looks pretty jittery. Sharpness is decent, but the 720p sample at 30 FPS just looks better to me, and is probably the preset I’d use with the Galaxy Nexus most often as a result.
The other neat feature in video mode is of course the ability to shoot time lapse videos right in the camera UI. This is under video, not stills because the photos get merged together into a video. You can specify intervals of anywhere between 1 and 10 seconds in a few steps. In conjunction with a mount of some kind and a scene with some temporal variance, the results are actually pretty awesome.
I set up the Galaxy Nexus in a smartphone tripod mount and shot two time lapse videos - one on 10 second interval (for a sunset) and another on 1.5 second interval.
The rest of the video shooting UI is pretty similar to the one for still photography - flash settings, auto white balance, some shooting effects, video quality, and the location geotagging toggle.
I'm glad that Google fixed the annoying rolling shutter / image stabilization settings for video captured on the rear camera with 4.0.2 and above. That said, the Galaxy Nexus is still not quite up to the level of other devices with the video it's shooting on the rear side. OMAP4460 can encode 1080p video with much better efficiency and higher profile H.264 features than what it's set for right now, and I'm very puzzled why Google hasn't enabled these encode parameters which would help bump up quality.
Another huge axis of improvement lately has been the mobile display category. It’s an ironic turn of events which has led to the mobile side being where all the improvement is taking place for displays in general. On one side of the industry we have the PC display market, which is currently locked in a dramatic race to the bottom (1080p 27" displays, decline of the 16:10 aspect ratio, etc.), and on the other side we have mobile displays where OEMs are rushing to outdo each other every major product cycle. In fact, 2012 might go down as the year when mobile display resolution eclipses the desktop.
Back on topic however is the Galaxy Nexus display - it’s a 4.65" diagonal, Super AMOLED HD 1280x720 affair. If you’ve followed Samsung’s AMOLED naming scheme, you can pretty much tell everything that there is to superficially know about the display just from the name. Super connotes an optical bonding (read: no air gaps or their pesky 4% Fresnel reflections) of the display and the entire stack above it, consisting of capacitive layer and top glass.
HD connotes, well, 720p HD, and finally the absence of Plus connotes the presence of PenTile RGBG. On that last note, we made a prediction that PenTile would be very hard to see on the Galaxy Nexus based on some pixel pitch calculations, and this turns out to be the case.
For me at least, the Galaxy Nexus display exceeds my visual acuity - I cannot pick out subpixels at all on the Galaxy Nexus. Quite literally, the RGBG subpixel stripe is now small enough that it is beyond visual acuity at standard viewing distance (1 foot).
If 2011 was the year where OEMs countered the iPhone’s retina display with qHD panels, 2012 is the year where they finally start to exceed that 330 ppi number. It seems as though 1280x720 WXGA will be the new WVGA or qHD for 2012, and already there are a bunch of 720p devices arriving on the market - phones like the HTC Rezound, LG Nitro HD, Galaxy Note.
Last time we compared pixels and subpixels per inch in the diagonal on a few phones. Many people pointed out alternative ways to compute everything, but in the end the aim was to set expectations for how visible PenTile would be, and the conclusion was: not very. This time, I think it makes sense to compare the actual angular subtense of the subpixels so we can appreciate whether they’re visible or not, rather than deal with another back and forth about whether measuring along the diagonal is valid or not anymore. It's easy to be lazy and just do things entirely wrong, but the actual angular subtense of a subpixel should be the canonical measure we use to determine whether you can see pixels or not, since that's the annoyance after all. Visual acuity for the average human eye is 1 arcminute (something drilled into my head from endless optical engineering classes), and perfect human vision is just below that at around 0.7 arcminutes. I have 20/15 which puts me around 0.75 arcminutes, and I can't see subpixels on the Galaxy Nexus unless I really, really try.
It’s actually a challenging thing to codify whether or not you’ll be able to see PenTile, since color (wavelength) makes a huge difference. Further, visual acuity is itself a hard thing to qualify - for example, consider how much resolution is enough to identify versus detect something, and then how human vernier acuity (aligning something) is very good, and all of this is a function of the light's wavelength. For example, the on-off pattern when looking at solid green is just about the worst case possible - it’s a square wave (100% modulation) in the green right where the eye is most sensitive. In the past, it struck me that other members of the tech press were perhaps unconsciously taking photos of the green battery indicator to show the presence of PenTile or not since that's where subpixels are most visible. As an aside, most of the UI is now blue in 4.x (including battery indicator) which the eye does not have very good sensitivity to - just try focusing on something entirely blue - is this a coincidence or conscious decision to mask bad displays? For comparison, when displaying white obviously subpixels largely disappear into a sea of light. If you look at a green solid region now, you’d be hard pressed to make out the individual subpixels, and the table explains why:
|Display Subpixel Angular Subtense lower is better, human eye ~1 arcmin)|
|Phone||X subpixel angular subtense at 12"||Y pixel angular subtense at 12"|
|LG Nitro HD||0.293||0.878|
|Motorola Atrix 2||0.373||1.118|
|Galaxy S II||0.440||1.320|
|Galaxy S / Nexus S||0.614||1.228|
The interesting thing about the table is that it very much backs up my subjective impressions of just how visible subpixels were on previous phones. The Nexus S / Galaxy S had comparatively gigantic subpixels, and I can't stand looking at those displays to this day. Move up the line and you get increasingly better (I've sorted by x/horizontal angular subtense), with the HTC Rezound exceeding the iPhone 4S. Note that you have to consider the adjacent unlit subpixels as well to really arive at a conclusion for how visible things are going to be - on the PenTile RGBG displays, that means one adjacent unlit subpixel, and on RGB stripe, two unlit subpixels (assuming we're talking worst case 100% Green, 0% Blue, 0% Red).
While Samsung has been able thus far to increase its AMOLED pixel pitch considerably, it has come with one unintended effect. That effect is a bit of pixel inhomogeneity which results in a somewhat grainy look to the display under certain circumstances. While neither device we tested had it, others have reported lines or splotches. There’s a word for these inhomogeneities in display luminance, and it’s “mura.” The variance is no doubt very minor, but the eye is great at picking out these small changes, and it’s particular visible in certain contexts, like the grey loading screen on the Android Market. So far getting a good photo of this effect has eluded me, however, it looks like a light film grain. Stated another way, it's like a fixed pattern noise that exists at all times on the display, which seems particularly visible at some brightness levels. To be honest, it doesn’t annoy me any more than IPS display “grain” annoys me - you just get used to it after a while.
These inhomogeneities also sometimes manifest themselves as visible strips of different luminance. I haven't seen any on either of the Galaxy Nexi we have, but if you do get hardware with annoying inhomogeneities, I recommend just swapping. Again, getting photographs of the grain has proven challenging.
The display’s surface is curved, though the radius of curvature is nowhere near as curved as some of the early teaser photos would’ve had you believe. Total sag ends up being around 1.5 mm, giving a radius of curvature around 1.5 m - needless to say, it’s a very gentle curve. The other noteworthy thing about the Galaxy Nexus is Samsung’s choice of glass. Lots of people have noted that the Galaxy Nexus isn’t adorned with Corning’s popular Gorilla Glass, though it’s still a kind of fortified (and no doubt alkali-aluminosilicate) glass. It’s impossible to tell exactly what kind of glass is on the Galaxy Nexus without destructive testing on either Samsung’s or Google’s review unit. That said, if anyone breaks a display, send me the broken top glass and I’ll be able to do some compositional analysis. As an aside, compositional analysis of the top glass from different phones is something I’ve wanted to do for a while now, but requires sourcing broken glass.
We’ve also done all the usual measurements on the Galaxy Nexus - luminance and color temperature at different brightnesses selected in settings, and a run through HCFR using Francois’ excellent Screen Test Patterns app.
First off are the display charts taken at a number of different brightness settings by dragging the slider around in settings. Traditionally AMOLED has struggled to keep a flat white point. Here the Galaxy Nexus isn't bad at all, hovering just below 6500K.
The Galaxy Nexus manages to stay reasonably close to 6500K even as brightness changes across its full range. The brightness curve is also nice and linear, though it tops out at just over 200 nits at maximum brightness.
The HCFR plot and color.chc file tell an even more interesting story. The CIE chart shows how AMOLED continues to have a gamut much larger than sRGB (which is the inner triangle). It’s awesome to have more spectrum, but bad when mapping sRGB to this color space without more management, and leads to AMOLED’s oversaturation stigma.
There are more interesting things inside, too. Color temperature at 100% brightness and displaying different shades of Gray stays pretty close to 6500K as well. Gamma ends up almost all over the place, unfortunately.
The nice thing about ICS on the Galaxy Nexus is also increased color depth in many places. Previously Android’s gallery many times appeared in RGB 565, leading to visible banding. This is now almost entirely gone as well.
Viewing angles on the Galaxy Nexus, like other AMOLED devices, is superb as well. There’s practically no shift in either horizontal or vertical angles. Outdoor viewing has gotten better on AMOLED with a bunch of improvements - better AR coatings, no more air gaps, and other coatings. Out in the brightest of sunlight it can still be hard to read, however.
From a cellular perspective there really are two entirely different Galaxy Nexii, as noted before. The GSM/UMTS (maguro) version which is slightly thinner, and the CDMA/LTE (toro) version which is on sale on Verizon at present and no doubt also Sprint later on when their LTE network is fired up. To accommodate those different combinations of air interfaces, Samsung made two very different phones.
GSM/UMTS Galaxy Nexus
|Galaxy Nexus (GSM/UMTS) - Network Support|
|GSM/EDGE Support||850 / 900 / 1800 / 1900 MHz|
|WCDMA Support||850 / 900 / 1700 / 1900 / 2100 MHz|
|HSPA Speeds||HSDPA 21.1 (Cat.14) / HSUPA 5.76 (Cat.6)|
|Baseband Hardware||Intel/Infineon X-Gold 626 w/I5712 transciever and RFMD RF6260 PA|
Cellular connectivity on the GSM/UMTS Galaxy Nexus is courtesy of an Infineon/Intel X-Gold 626 (XMM6260). This is the same baseband as what shipped in the GT-I9100 SGS2, which isn’t much of a surprise at all. That means HSPA+ with HSDPA 21.1 (64QAM) and HSUPA 5.76. From a cellular perspective, the Galaxy Nexus is actually virtually identical to the GT-I9100 SGS2, and includes the exact same Infineon Smarti UE2 RF transceiver marked 5712, and the RFMD RF6260 quad-band multi mode (GSM/EDGE and WCDMA) power amp which works between 1710 and 1980 MHz, and 824–915 MHz, supplanting the need for individual power amps for each band. Of course, the 2100 MHz band has its own power amp elsewhere. The GSM/UMTS Galaxy Nexus also takes a regular size Mini SIM (not microSIM). In addition, though XMM6260 supports it, the Galaxy Nexus doesn’t include Rx diversity, and instead just locates its single cellular antenna at the very bottom of the device in one module, and the WLAN antenna off to the side.
Intel X-Gold 626 circled in black above - Image courtesy iFixit
When the Nexus One (and later Nexus S) originally came out, I was puzzled by why Google hadn’t asked its OEM to include pentaband WCDMA support. Back in the Nexus One days, Google was making its big push to try and reshape the way smartphone shoppers buy phones in the US (and make things more like how the rest of the world does it). At the same time however, the hardware launched effectively only with the WCDMA band support for T-Mobile in the US. Third time is a charm, and the GSM/UMTS Galaxy Nexus is now both the first Nexus phone with pentaband WCDMA support, and, moreover, the only Android phone with pentaband WCDMA. The result is a new level of freedom - fully carrier-unlocked and hardware-unlocked hardware that is finally completely carrier agnostic (at least in GSM/UMTS land).
We tested the GSM/UMTS Galaxy Nexus on T-Mobile’s HSPA+ network and burned through the 2 GB of data on Google’s SIM before burning through another couple of GBs on our own T-Mobile SIM. All in all we ran over 200 tests and generated the histograms that normally grace our smartphone reviews.
Downstream Stats (Mbps) Avg: 3.522; Max: 8.689; Min: 0.029, StDev: 2.022
Upstream Stats (Mbps) Avg: 1.192; Max: 3.259; Min: 0.025, StDev: 0.814
Latency Stats (ms) Avg: 196.93; Max: 500; Min: 105, StDev: 57.122
Number of Tests Run: 244
T-Mobile can be fast when it wants to, hitting 8 Mbps down at one point, and 3.2 Mbps up at another. Obviously the Galaxy Nexus is where it should be considering its HSPA+ category. I also tested the GSM/UMTS Galaxy Nexus on AT&T but didn’t run enough tests to generate the most meaningful histograms. I couldn’t get the Galaxy Nexus to go quite as fast as I’d expect it to on AT&T HSPA+ for some reason, even using the “phone” APN.
Downstream Stats (Mbps) Avg: 2.114; Max: 4.396; Min: 0.083, StDev: 0.979
Upstream Stats (Mbps) Avg: 1.201; Max: 1.681; Min: 0.043, StDev: 0.449
Latency Stats (ms) Avg: 280.479; Max: 951; Min: 107, StDev: 281.045
Number of Tests Run: 71
Oh, and needless to say, the Galaxy Nexus doesn’t suffer from any deathgrip or related signal propagation issues that I can identify.
CDMA/LTE Galaxy Nexus
When I caught wind of the fact that Verizon had also been selected as a launch carrier for the Galaxy Nexus, I speculated that Samsung would reuse the same cellular architecture it used in the Droid Charge. In that review, I talked about how the device used a combination of Samsung CMC220 for LTE, and VIA Telecom’s CBP 7.1 platform for CDMA2000 1x/EVDO. It’s a rather unique combination that also shipped in the Samsung Stratosphere.
|Galaxy Nexus (CDMA/LTE) - Network Support|
|CDMA2000 1x/EVDO Support||EVDO Rev.A (800 / 1900 MHz)|
|CDMA Baseband Hardware||VIA Telecom CBP7.1 with FCI FC7780|
|LTE-FDD Support||UE Category 3 - 700 MHz Band 13|
|LTE Baseband Hardware||Samsung CMC221 with FCI FC7851|
It makes sense for Samsung to reuse what work it has invested in making both Android’s Radio Interface Layer (RIL) and hardware work together for the Galaxy Nexus, and this turned out to be a pretty good educated guess. It turned out mostly correct - the CDMA/LTE Galaxy Nexus is based on a combination of Samsung CMC221 and VIA Telecom CBP 7.1.
Samsung CMC221 and VIA Telecom CBP7.1 - Courtesy ZDnet/TechRepublic
So what’s different between CMC220 and CMC221? No doubt, CMC221 simply is a revision of CMC220 which improves connection stability and handover performance, as one of my few complaints with CMC220 were the prevalence of paused connections in some environments.
Beyond that, it’s hard to know exactly what’s changed, but suffice it to say CMC221 shares the properties with CMC220 that we care most about. It’s a UE Category 3 part - which is the current maximum for devices right now - it’s no doubt 3GPP Rel.8, and it supports 2x2 MIMO on the downlink. The CDMA/LTE Galaxy Nexus right now only operates on Verizon’s 10 MHz FDD LTE network, though Sprint is slated to get a CDMA/LTE Galaxy Nexus of their very own that will undoubtably be tailored to the 1900 MHz PCS block it deploys in. For now however, we’re just talking about the variant on Verizon 4G LTE.
I ran a bunch of tests on the CDMA/LTE Galaxy Nexus on Verizon 4G LTE and 3G EVDO networks. I tested 4G LTE in my Tucson, AZ market and honestly found using a UE Category 3 device quite refreshing after a long wave of UE Category 2 Motorola Wrigley. There is absolutely a difference in the kind of speeds you can see between devices, and I definitely consider the LTE Galaxy Nexus’s performance above average. I saw a maximum of 58 Mbps on the LTE Galaxy Nexus, though I didn't grab a screenshot. I did of one at 56 Mbps down, however.
Verizon Wireless 4G LTE
Downstream Stats (Mbps) Avg: 19.715; Max: 58.294; Min: 0.089, StDev: 11.744
Upstream Stats (Mbps) Avg: 7.437; Max: 19.711; Min: 0.242, StDev: 3.699
Latency Stats (ms) Avg: 87.312; Max: 188; Min: 63, StDev: 21.285
Number of Tests Run: 342
Again, I consider the 4G LTE performance of the Galaxy Nexus quite good, and I saw speeds in my market that I haven’t been able to achieve with other devices. The 58 Mbps test is pretty good, although I know a few other people I talk to have been able to hit over 71 Mbps on the Galaxy Nexus, and likewise consider its RF performance above average on LTE.
We also talked about the perceived LTE signal issue with the Galaxy Nexus at some length. Without revisiting the whole thing, the issue is with the way Android 4.0.2 paints signal bars as a function of signal strength. The Galaxy Nexus as of 4.0.2 does this in a way that isn’t in line with the other Verizon 4G LTE devices, and coupled with the fact that getting to LTE signal strength (and not 1x or EVDO RSSI) is difficult, misled many into thinking there was an issue when there really wasn’t one. I’ve continued comparing LTE RSRP (Reference Signal Received Power) between the Galaxy Nexus and other phones that report it, and have yet to see a significant difference. In addition, other LTE devices reported RSSI instead of RSRP - again it’s good that people are using numerics instead of bars (which are not standardized), however caution must be taken to compare the same parameters properly.
Of course, that’s really not all there is to talk about - what about 1x and EVDO performance on the VIA CBP7.1? My initial investigation only looked at 4G LTE, and since then I’ve had countless people email or otherwise notify me that EVDO also needs a good looking at.
I believe I’ve nailed down why there’s a perception that something is wrong with the Galaxy Nexus’ EVDO connectivity. Interestingly enough, the reason is again a nuance in the way that the device reports signal, but on EVDO. In particular, I noticed something in common with the Droid Charge that is no doubt unique to CBP 7.1. Namely, the baseband reports signal level in a quantized fashion at a few different levels in dBm. Ordinarily I see signal level quantized to just integer values, however on the CBP 7.1 based devices I’ve seen (like the Droid Charge and CDMA Galaxy Nexus) that quantization takes it to a few different levels. That means the values below are the only ones shown when connected to EVDO. You could be in an area with -51 dBm EVDO RSRP, but the maximum you’ll ever see reported is -75. There’s some hysteresis as well and the device doesn’t switch between levels that often.
-120 (0 signal)
I have a sneaking suspicion that these values originally were designed to correspond to some decent cutoffs for signal bars (eg a 5 bar system with -120 being 0 bars), though I’m not entirely certain. The result of this quantization again is that you can be misled into thinking signal is worse or better than it really is depending on conditions, and I wager that this is what leads many to report that things are different than shown on other devices. I also compared EVDO signal strength between the CDMA/LTE Galaxy Nexus and a Droid Bionic, and quantization issues notwithstanding I saw very similar measures.
The caveat is that no doubt CBP 7.1 + FC7780 has different performance than the MDM6600 that has been ubiquitous for CDMA connectivity, so the fact that phones might perform differently in the same location doesn’t surprise me. That said, I’ve yet to see anything dramatic at all.
Nevertheless, I ran a ton of tests on EVDO (eHRPD is EVDO anchored through the PDN-Gateway) to test performance.
Verizon Wireless 3G EVDO Rev.A
Downstream Stats (Mbps) Avg: 0.891; Max: 2.525; Min: 0.07, StDev: 0.560
Upstream Stats (Mbps) Avg: 0.851; Max: 1.534; Min: 0.149, StDev: 0.254
Latency Stats (ms) Avg: 145.036; Max: 800; Min: 103, StDev: 97.1341
Number of Tests Run: 139
Honestly I can find nothing wrong with EVDO performance on the Galaxy Nexus. In fact, if you go back to the Droid 3 review, you’ll see that the Galaxy Nexus numbers are slightly higher in the upstream department and pretty similar (though differently grouped) on downstream.
I don’t usually include call quality measures in this section, but it also bears talking about since we’re dealing with some reports of things varying from what they’ve seen before on the CDMA/LTE Galaxy Nexus. Call quality on the GSM/UMTS Galaxy Nexus on T-Mobile is pretty par for T-Mobile 3G voice (AMR).
CDMA voice on the Galaxy Nexus does sound a bit different from other devices, however. Compare to the RAZR below which is again based on MDM6600 and its own vocoder.
It isn’t a huge difference, but enough to account for why many people have reported that voice sounds different on the CDMA/LTE Galaxy Nexus. Again, there are bound to be subtle differences between implementations, and I wager Qualcomm’s CDMA market domination in the US accounts for why the difference is something so many have talked about. It’s interesting to me that none of these nuances attracted as much attention with the Droid Charge, but then again I doubt as many people made a switch at that point.
That said, I’ve been using the CDMA/LTE Galaxy Nexus for almost all my calls, and did encounter one circumstance where voice continually cut in and out inexplicably. I haven’t experienced that behavior since.
When it comes to ambient noise suppression, both the CDMA/LTE Galaxy Nexus and GSM/UMTS Galaxy Nexus have a second microphone for common mode noise rejection. The microphone is right near where the battery cover makes contact with the top, slightly offset to the right. It’s a small port but easy enough to pick out.
I don’t know what solution is at play inside the Galaxy Nexus, but it honestly does a mediocre job suppressing noise, we’ve seen other phones definitely do better.
The Galaxy Nexus uses Broadcom’s BCM4330, which is starting to pick up steam and become just as ubiquitous as the BCM4329 it replaced. The Galaxy Nexus’ BCM4330 includes both 2.4 and 5 GHz WLAN connectivity, just like the SGS2 in fact. What’s particularly notable is that Android 4.0.x now includes the proper prioritization for each WiFi band, and also includes the ability to set preference for one band for the other. By default, when faced with the same SSID on both 2.4 and 5 GHz, the Galaxy Nexus correctly chooses the 5 GHz AP if the signal is favorable, then falls over to 2.4 GHz when its link quality on that band would be better. Other than this notable change, the remainder of the WiFi settings panes are unchanged. The WiFi sleep preferences and the main scan and connect page does get a minor facelift and change, however.
The Galaxy Nexus latched onto my 802.11n APs on both 2.4 and 5 GHz and used 20 MHz long guard interval rates at 65 Mbps the same as other BCM4330 based devices. Throughput is unsurprisingly very good on the Galaxy Nexus in our WiFi test, which consists of downloading a 100 MB PDF hosted locally over WiFi. Of course, since we can now control and choose which band the device uses, I tested on both 2.4 GHz and 5 GHz, both with a negotiated link rate of 65 Mbps.
WiFi range on the Galaxy Nexus is good as well, I can make it to the same place before hopping off my network as other devices. I have gotten a few emails and read reports about power-save mode incompatibility with some APs that causes it to drop off when on standby mode. Since we've seen BCM4330 work just fine on other devices, I have no doubt this is a software issue which will be fixed soon.
As usual I also measured speakerphone volume on both variants of the Galaxy Nexus using a sound datalogger. There is apparently a difference between the two models, possibly from different acoustical chambers in the vibration unit and antenna. Also there’s possibly still a difference as a result of the different voice coders in use, and the different dynamic range.
Either way, the two test differently, and subjectively my experience backs those measurements up. I found the GSM/UMTS Galaxy Nexus a bit too quiet while using Google Navigation, and the CDMA/LTE Galaxy Nexus on the quieter side but totally useable for Navigation.
Just like the SGS2, the Galaxy Nexus uses a SiRFStarIV GSD4t for GPS. Subjectively the Galaxy Nexus GPS doesn’t lock quite as fast as some of the other GNSS solutions that are integrated into the cellular basebands in phones, but it does get the job done pretty fast. I see a time to first fix of between 4-7 seconds depending on visible sky swath presented to the handset.
I did receive a few emails from readers with reports of some Galaxy Nexuses shipping with GPS issues or taking too long to lock. One of my friends with a CDMA/LTE Galaxy Nexus also reported that he couldn’t get a GPS lock at all for Google Navigation. I’m not entirely sure what the deal is here since I never was able to encounter this behavior, although manually downloading the A-GPS data (ephemeris) using a tool like GPS Status seems to in general helps mitigate those problems when they do happen. This just manually re-downloads the xtra.bin file from http://xtra1.gpsonextra.net/xtra.bin as configured in gps.conf. I have to admit that I didn’t encounter any GPS issues in my time with the Google Nexus (CDMA/LTE or GSM/UMTS version) so far.
We’re going to do a more in-depth audio analysis with the Galaxy Nexus when we have our testing suite more fleshed out, and possibly bring you Francois Simond’s thoughts once more. For now however, we have some RMAA runs I talked about a while ago in another review, and my own impressions with Galaxy Nexus sound after using the device for a while now as my primary music player with some Shure SE535s.
First off, the Galaxy Nexus out of the box is pretty decent subjectively. The Galaxy Nexus uses TI’s TWL6040 low power audio codec for its DAC and other audio responsibilities, alongside the vibrator actuator. We’ve seen some other TI audio codecs (like AIC3254 in the HTC Sensation) but this our first time seeing TWL6040. Almost immediately I noticed that there isn’t any constant high frequency whine present like I’ve heard on so many phones lately (Bionic, SGS2, others), and it’s hard to hear any noise when the DAC turns on and off after music stops playing. Even plugged into USB power, the device also doesn’t pick up any more noise or change at all. There’s also almost no CPU noise, though if you listen very carefully you can indeed hear some state changes, but it’s very minimal and very difficult to pick out.
Though the frequency response isn’t entirely flat as shown, the Galaxy Nexus doesn’t sound bad subjectively. Our testing here is just a RMAA run from line out on the devices to line in on an ASUS Xonar Xense sound card. In addition, testing is done at 44100/16 bit on the devices - Android will downsample anything more than this.
From 20 Hz to 20 kHz: +0.10, -0.62 (dB)
Noise on the Galaxy Nexus also isn’t bad, definitely better than the RAZR we tested earlier.
Noise Level: -96.2 (dB, A weight)
Dynamic range shows the difference in level between the maximum output and minimum output on the smartphone. This is limited by voltage swing and system noise. Galaxy Nexus again here looks pretty good, minus a few spikes.
Dynamic range: 96.0 (dB, A weight)
The two total harmonic distortion charts are next, which are the summation of integer multiples of the test frequency and expressed as a ratio of the input signal (in this case at 1 kHz). THD+Noise gives all frequencies except the input signal. The Galaxy Nexus is pretty good here, but still has some spikes at a few noteworthy integer multiples, plus some odd spikes at high frequencies.
THD %: 0.0088
Intermodulation distortion is similar to total harmonic distortion, however it applies two input signals and then measures the signal at all frequencies except the two inputs. In this case, the two signals are on opposite sides of the spectrum. Galaxy Nexus ends up not looking too bad here although there are disconcerting spikes above 1 kHz that I can’t explain.
IMD + Noise %: 0.013
Finally stereo crosstalk is pretty flat on the Galaxy Nexus.
Stereo Crosstalk: -87.4 dB
Again, this isn’t meant to be a totally comprehensive analysis of the Galaxy Nexus’ sound characteristics, just some educated impressions. Subjectively the Galaxy Nexus sounds nice and clean, and is absent of the annoyingly audible background noise and whine that’s present on some of the other noteworthy phones we’ve tried as of late. Francois (supercurio) has expressed a few times that the Galaxy Nexus has good audio potential, and that alone should tell you something.
Battery life remains the other big axis on which smartphones are judged, and here we've turned to our regular 2011 suite of battery life tests to see how the Galaxy Nexus shakes out. Our battery life testing consists of a page loading suite which loads through a few dozen pages endlessly on both WiFi and cellular data until the phone dies, with the display set at 200 nits. For the cellular tests, we're always careful to test in cellular environments with decent signal (at least -75 dBm or higher) as well, since that's a factor. Next is a simple call test where we play music at both ends of a call until the device under test dies, and our final test is a WiFi hotspot workload which consists of four page loading tabs and a 128 kbps streaming MP3 station that runs until the phone dies.
First up are the web browsing tests over cellular 3G; this means EVDO Rev.A for the CDMA/LTE version, and WCDMA T-Mobile for the GSM/UMTS device.
The Galaxy Nexii both do surprisingly well. I'm actually very impressed with how long the devices lasted subjectively on 3G and this definitely backs that up. Of course, both devices include beefy batteries, but Samsung has done a nice job thus far including big batteries without making devices bulky or heavy.
Next up is the same test, but on 4G LTE for the CDMA/LTE variant.
The Galaxy Nexus doesn't post numbers very far in front, but manages to come in the top of the pack on 4G LTE at just under 4 hours. This is a pretty impressive result, honestly, considering that CMC221 is likely made on the same 45nm manufacturing process as CMC220. Again, I'm impressed with the Galaxy Nexus' longevity even on 4G LTE.
Surprisingly, the Galaxy Nexus can't break past that 6 hour mark even on WiFi, however, which does lead me to think we might be constrained by driving that display.
If you ever wanted to see how much difference having a different cellular architecture makes, see above. The GSM/UMTS Galaxy Nexus lasts impressively long on a voice call, at over 11 hours, yet its CDMA/LTE brother lasts just over half that.
WiFi hotspot on 3G tells the same story - I'm not sure what Via Telecom's CBP7.1 draws in its active state for EVDO or 1x voice, but it seems to eat up more power than the XMM 6260 (X-Gold 626) in the GSM/UMTS Galaxy Nexus.
As a 4G LTE WiFi hotspot, the Galaxy Nexus loses its edge over the Revolution, but does come in just ahead of the rest of the 4G LTE herd.
The story of battery life on the Galaxy Nexus unsurprisingly depends on which variant you're talking about. For a phone with a 4.65" display, I'd say I'm impressed with the battery life on both devices - remember that the area that needs to get lit up goes as r^2 - increasing that and not killing the battery is a big feat. In addition, I'd wager that using the OpenGL ES renderpath (and accelerated browser in 4.0) definitely helped both Galaxy Nexus devices post impressive scores. As for the two variants, the GSM/UMTS device has impressively long battery life pretty much across the board. Playing with that phone, I was rarely wanting for more on my regular use schedule (I charge at night on my nightstand). We've seen XMM6260 before in numerous devices where it seems to be a pretty good citizen.
The CDMA/LTE variant, on the other hand, depends strongly on what air interface you end up using most - on 4G LTE the device comes in at the front of the pack usually, and its 3G web browsing test is above average. However, if you make a lot of voice calls, the phone might not cut it. Unsurprisingly the CDMA/LTE Galaxy Nexus does nothing to dramatically change 4G LTE battery life - for that we're still waiting for upcoming 28nm LTE basebands.
For Google, one of the major points of Nexus has always been to provide a stable piece of reference hardware for it to cater a major OS release to. Each device has married a major revision of the Android platform to the latest stable hardware. That isn't to say that the hardware choices are always bleeding edge, but rather modern and logical next steps for the platform. I often read that Android as a platform is plagued by rapid hardware releases and product cycles that leave endless variants of the same hardware for each carrier, and that preloads and skins fragment the experience. While there's some truth to this, it isn't necessarily Google's fault - the software is open source after all. In the case of Android 4.0, this release is about consolidating the tablet and smartphone form factors under one version of Android and negating some talk of the platform's fragmentation.
For Google, each Nexus launch is analogous to Apple's iPhone launch - it's the one time that Google gets to dictate exactly what hardware is coming out, and exactly what software makes it onto that hardware. It is no less significant for Google's platform, either. Thus far there's been one Nexus device released per year, and that hardware gets updates from Google directly - at least until the hardware precludes support.
While the Verizon CDMA/LTE Galaxy Nexus is a bit unique, there's no indication thus far about how long carrier approval will take. The Galaxy Nexus line itself is very interesting - on one side, we have the GSM/UMTS device with pentaband WCDMA support that finally fully detaches the hardware from needing carrier specific versions for each region or carrier on GSM/UMTS networks. This is a dramatic step toward reducing carrier power, turning the networks into dumb pipes, and changing the way US customers shop for devices - exactly what the point was when Google launched the Nexus One. On the other, we have the Verizon CDMA/LTE version which thus far marks the furthest carrier incursion into otherwise untouched Nexus-land.
At this point, the Galaxy Nexus is awesome because of its marriage of Android 4.0 and a number of unique hardware features. I'd go so far to say that the Galaxy Nexus is without question the current best Android device, and with the improvements made in Android 4.0, first party applications and browser are now nearly as smooth as their counterparts in iOS. If OS smoothness was the thing holding you back from Android, 4.0 does a lot to change that. The Galaxy Nexus display is excellent, pentaband WCDMA on the GSM/UMTS model is exclusive only to that device, battery life isn't half bad, instant capture works well, and it has Samsung's newest LTE modem. The downsides are pretty much obvious - the camera is far from awesome, the GSM/UMTS variant has a quiet speakerphone, Samsung is using OMAP4460 at 80% of its maximum clocks, and some Galaxy Nexus displays have more more inhomogeneities than others. There's also the matter of newer 32 and 28nm SoCs that are just over the horizon.
The Galaxy Nexus is so important again because it's the only time Google gets to dictate everything - the hardware, the software, and update timing. There's also the element of freedom, with unlockable hardware out of the box. I find myself wishing that Google had begun its adventure sticking it to the carriers with pentaband WCDMA support like this phone finally has, as that would've been much more successful than the practice of releasing a few different Nexus variants with different bands.
As far as Ice Cream Sandwich is concerned, it really is Android perfected. Everything is smoother, faster and nearly all of our issues with the OS have been addressed. ICS brings Android into 2012 and gives Google a great platform to begin to introduce new features going forward. Android is now very close to UI performance parity with iOS, which eliminates a major tradeoff you had to make in the past. If you were hoping for ICS to be iOS with a Google logo on it, you'll be sorely disappointed. However if you're a fan of Android and just wished it were smoother and more polished, Ice Cream Sandwich is what you've been waiting for.