Google Nexus 4 Review - Google's new Flagship
by Brian Klug on November 13, 2012 8:45 AM EST- Posted in
- Smartphones
- LG
- Android
- Mobile
- APQ8064
- Nexus 4
- Android 4.2
- MDM9215
I usually take apart smartphones I’m sampled just because I like knowing what’s inside, even if I already know the majority of component choices through other purely software means. In the case of the Nexus 4 this was also motivated by my desire to find out whether it would be possible to replace the battery easily and also to get a look at some of the RF components for cellular.
Taking apart the Nexus 4 is surprisingly simple, so much so that I’ve taken my Nexus 4 review unit apart fully, twice. There are two Torx T–4 screws at the bottom which come out, after which the back cage pulls off after you use a plastic separator tool to get past some clips holding it on. If you’re interested in replacing the battery you can pretty much stop here, there are two screws holding the battery connector onto the mainboard, and the battery is held in place with a square outline of double sided tape. The back side of the case has many gold pads for antennas, NFC, and the inductive charging coils.
Further disassembly involves removing the plastic covering the PCB, then a few screws and the mainboard lifts out. Construction here is very standard fare for smartphones lately, with an L shaped mainboard and battery sitting in the cavity next to it.
After you get the PCB out things are very easy to identify. I popped the EMI cans off wherever possible as well.
First off on the backside we can see the DRAM PoP atop APQ8064, which in this case is Samsung 2x32-bit LPDDR2–1066, 2GB courtesy of 4 x 512MB die at 1.2V. Below that is the Qualcomm MDM9215 baseband, to the left we can see the baseband PMIC (PM8821), and to the left of that the PMIC for APQ8064, PM8921.
On the long underside of the mainboard we can see the TI BQ51051b wireless power Li-Ion charger receiver I mentioned earlier, and above it Qualcomm’s WCD9310 Audio codec in a sea of epoxy. Inbetween those two is a BCM20793 NFC controller instead of the ubiquitous NXP PN544 part.
My main goal when taking apart the Nexus 4 was nailing down what power amplifiers and RF architecture the phone had, and under the EMI cans on this side are a few relevant parts.
There are three Avago power amplifiers, and an RFMD switch at left. We can see Avago A5505 (Band 5 - UMTS), A5704 (Band 4 - LTE/UMTS), A5702 (Band 2 - LTE/UMTS), and at far left an RFMD 1156 single pole 5 throw switch hiding under a lip of the EMI can.
Flipping the PCB over and removing the other large EMI can reveals more parts of the puzzle. I can identify an Avago ACPM–7251 (Band 1, 5, Quad band GSM/EGE) power amplifier, and another package near it marked “GFD49” which is probably another switch just next to the antenna feed for the bottom transmit antenna.
Nexus 4 also has the latest and greatest Qualcomm transceiver onboard, WTR1605L, which we’re going to talk at length about in another piece. It’s actually somewhat surprising to see the latest and greatest here considering the Nexus 4 doesn’t include LTE support, even though it does have the hardware for it on bands 4, 2, and 1 in theory.
Also under this can is the SlimPort ANX7808 which enables HDMI, VGA, DVI, or DisplayPort out on the Nexus 4 instead of the USB-MHL that we’ve been seeing getting adoption pretty rapidly. This is actually an interesting choice for the Nexus 4 considering again the relative ubiquity of MHL. I don’t have any SlimPort cables or dongles so I can’t test it first hand, but there’s the transmit package on the PCB that enables it.
I can also identify an InvenSense MPU–6050 six axis gyro and accelerometer at the very top of the PCB.
I couldn’t get the can off of what appears to be the eMMC (the only remaining large package), we’ll have to see if anyone else wants to do some destructive digging to get that one. Finally the Nexus 4 also has a linear actuator vibrator which you can see in the FCC teardown photos.
Facebook
Twitter
RSS
188 Comments
View All Comments
zeroidea - Wednesday, November 14, 2012 - link
It's Tucson, AZ!They must have been taken a few weeks ago (a lot of the streetcar construction downtown has been completed)
DukeN - Tuesday, November 13, 2012 - link
Brian, are you able to verify if the material is actually rubber? This would be a serious issue for many users, including some in my family with severe latex allergies.PeteH - Tuesday, November 13, 2012 - link
Wow, that didn't even occur to me, but it could be a real problem. It's not like latex is an uncommon allergy either, so hopefully Google or LG thought about that and used something other than rubber.Rits - Tuesday, November 13, 2012 - link
Its rubberised plastic. Shouldn't be a problem at all to latex-allergic folks.PeteH - Tuesday, November 13, 2012 - link
Not doubting you, but do you have a source?Rits - Tuesday, November 13, 2012 - link
Previous LG devices that had the same material were latex-free. There is no reason this one would deviate. But, you could always email LG/Google for an official confirmation.MadMan007 - Tuesday, November 13, 2012 - link
Should have used a dual core CPU with a decent GPU. Quad core is a waste in phones because overall it hurts battery life more than it helps certain usage models, and if there's so much throttling what's the point.Does Android do thread parking? Do these CPUs have per-core power gating?
JohnnyL53 - Tuesday, November 13, 2012 - link
Throttling may not be an issue in the real world in terms of a noticeable affect and may just show up in benchmarks. In other words, who cares what the benchmark performance is if its at such a high level it's not perceptible? What I never see explained is how far apart do you need to get before you can distinguish one device's performance from another. Granted on most of the tests the iPhone far outpaces any other phone, but is it even noticeable? Are we just talking bragging rights, future proofing, etc?name99 - Tuesday, November 13, 2012 - link
The value of a faster CPU on a phone, for normal people, right now, is that the phone feels snappier. So, for example, an iPhone5 feels perceptibly faster than an iPhone 4S not because computational tasks take 1 minute instead of 2 minutes, but because a dozen small things take .1 second instead of .2 seconds.From this point of view
(a) thermal throttling is no big deal, and I personally have no problem with it. It was a good idea when Intel started it years ago (to the accompaniment of a massive chorus of whining) and it would be a fine idea to have it as built into an ever wider selection of phone chips.
(b) quad-core remains a solution in search of a problem. Maybe one day it will have value; maybe it has value for games (which I don't care about). But for the way I and my crowd use phones, it has no value yet.
(c) the present collection of benchmarks are largely useless because they do NOT track this essence of snappiness which is what most people mean when they say a phone is "fast". Yes, if you're a developer writing demanding code you care about very particular aspects of the phone --- perhaps you care about the memory bandwidth, or the FLOPs, or the random flash write performance. But for most people, what matters is the snappiness. Existing benchmarks are a poor proxy for that feeling, and I do wish the serious blogs could do better.
Right now all we have is this lame sniping like 12 yr olds: "My Nokia feels fast", "Oh yeah, well my Samsung feels even faster", "Well my iPhone feels fastest of all". And regardless of your feelings about Apple, if you support Team Android or Team Windows, you should be pushing for snappiness benchmarks because that is one of Apple's great strengths --- they don't care about, and don't optimize for benchmark numbers, they optimize for snappiness, and buyers do appear to be aware of and notice this. As long as the non-Apple market is forced to compete on these "overt" benchmarks as ways for each vendor to differentiate themselves and show their technical superiority, what will be optimized for are benchmark numbers, NOT user feel and snappiness.
Zink - Tuesday, November 13, 2012 - link
I think with a DSLR at 60 FPS and editing to synchronize individually recorded videos it would be possible to do accurate side by side comparison of app responsiveness and web page loads. With a bit of video analysis, graphs could be made comparing performance down to the frame and FPS in animations measured.You could even do this on the go for a real world performance comparison. A normal day of use could be simulated by walking/commuting around your city and setting up a tripod in an apartment, on the sidewalk, inside an office building, at the bar etc. Then run several tests on each phone where you get the phone out of your pocket like normal and open a web page, post a comment, take a photo etc. all while the screen is on camera. Several similar tasks could be averaged into a single category score for a bit better repeatability.
With proper analysis of the resulting video a pretty damn accurate comparison of the whole cellular, hardware and software system could be made. Basically the ultimate benchmark measuring user phone performance. I've seen some well done side by side comparisons but never in depth or with good numbers along with the video.