Is Google a good OEM? This famous developer thinks so

Google’s way of handling the Nexus program was an interesting one. Manufacturers would bring their ideas to the table, only to let the Search Giant select the right partner each year. Google worked with HTC, Samsung, LG, Motorola, HUAWEI, and ASUS to make some of the most desirable smartphones and tablets this industry has seen.

Things changed once the Mountain View tech giant decided to flip the table over and take charge of things. Now they run both the software and hardware sides of the spectrum. Needless to say Google Pixel devices have been outstanding, but how good is Google as an OEM, really? Can they meet the expectations set by experienced manufacturers?

Popular developer Francisco Franco believes so, for a few reasons. Francisco has worked as an independent developer, mostly with custom kernels for Nexus devices, collaborations, and his very own applications. Due to his background, he can give us a much more in depth and refined explanation of what Google is doing right. Let’s take a look at his explanation as to why “things are looking hot for Google as a phone OEM.”

Development and optimizing performance

There is a clear commitment from Google as an OEM to get every last bit of performance and the continued improvement of security. Things like disabling build flags from the Kernel config to reduce overhead, improve boot up time, produce smaller Kernel binary size and reduce the attack surface are a big focus and they were rare when they had the Nexus program, specially after the devices were out for production. Development on the Pixel phones haven’t slowed down one bit since release, contrarily to what happened with Nexuses.

It is arguably believe by many Android  a fans that Nexus devices were the best when it came to software (at least within the Android world). These devices offered the pure Android experience, not to mention the fact that they were the first to get updates. It is also true most of us have not taken a look at the kernel. There are differences in the code most of us would not catch, and Francisco’s highlights are only some examples of that.

Battery life optimizations

More often than not Google is concerned about battery life and merges some interesting patches to reduce power drain, two patches actually made it to the nougat-mr2 release (7.1.2) which are related to nanohub (it’s microchip processor in charge of sensors) and WiFi.

Once you buy a device and test its battery performance, the next step is to settle with results and learn to adapt to the experienced battery life. If anything changes, it’s usually for the worse, as battery life tends to deteriorate with time and use. It’s refreshing to see Google improving things in the long run.

Improving the kernel binder

Google is “wasting” A LOT OF TIME on the Kernel binder driver. If you don’t know Binder is like the referee for IPC (Inter-process comunication) allowing Remote Procedure Calls. It’s very complex, very old, and it’s been mildly patched since Android 1.0. This time Google seems to want to really fix it. A lot of performance issues originate from it using a global lock and it introduces jank when there’s a lot of contention. I don’t know the whole history, but with O (and they’ve been working on this for a while) there will be more than one Binder. We now know of Binder, HWBinder and VndBinder. I asked around and I couldn’t get much info about this and that all will make sense soon – I didn’t insist much, don’t wanna bother the guy. My guess is that with O Android will parallelize things a bit by separting several Binder instances for several pieces of the system. Binder maybe for apps, HWBinder for software that deals with hardware (display? gpu?), VndBinder maybe for vendor firmware? I don’t really know. But it makes sense to separate Binder through several instances to reduce contention. This going forward (and assuming I’m correct) is/will be one of the most important change on Android. Probably similar to the importance of ART’s introduction. Don’t quote me on my guessland theory, but it’s a fact that Google is heavily invested on improving Binder. Check the o-preview-1 marlin/sailfish Kernel repo and you’ll see the crazy investment on that area.

Now, here is where things get a little more confusing… I will leave it at that. Those who get it, get it.

What do you think?

Plenty of factors come into making a good smartphone, and though Google’s Pixel devices haven’t been perfect, they get pretty darn close to it. The Pixel XL got an 8.9 review from us, which is pretty high. In fact, our only complaints are regarding the design (which is subjective), the lack of OIS (which many of you don’t mind) and the high price tag.

Other than that, we say Google has done a great job building this handset, and it seems they continue doing a good job improving it. Is Google looking like a great OEM? That’s for sure.

Have you noticed any improvements since Google stepped up and started making its own devices? What do you see in the Pixel that was uncommon with the Nexus line-up.