Drama over: Google posts images and binaries for 2013 Nexus 7

The software's fate was uncertain just a couple of days ago.

Google has released factory images and binaries for the 2013 Nexus 7 (left) to go along with the 2012 version's (right).

Andrew Cunningham

Android modders who want to get to work supporting the 2013 Nexus 7 can breathe a sigh of relief: Google has released a factory image and driver binaries for the tablet, just as it has done for nearly all of its other Nexus phones and tablets. This news comes a couple of days after former Android Open Source Project technical lead Jean-Baptiste Queru said that he didn't know whether they would be released at all.

Queru strongly implied that legal issues were preventing these files from being distributed, specifically the software needed to support the tablet's Qualcomm-made GPU. Frustrated by the hold-up (which he took great pains to anticipate), Queru quit AOSP not long after making his initial complaints.

It's unclear whether the release of these files has anything to do with Queru's departure or the news coverage that his implications prompted. In any event, the story has a mostly happy ending for anyone waiting to get their hands on support software for Google's latest tablet.

27 Reader Comments

Proprietary Binaries have long been a hot issue for users of hardware and Linux. For the longest time, the only way to get WiFi drivers was to sideload windows binaries. Hopefully as time goes on these proprietary binaries will simply disappear.

Proprietary Binaries have long been a hot issue for users of hardware and Linux. For the longest time, the only way to get WiFi drivers was to sideload windows binaries. Hopefully as time goes on these proprietary binaries will simply disappear.

BLOBs will never disappear, in my opinion, because somebody will always be more concerned with protecting their IP than supporting what amounts to a small market segment.

I strongly suspect someone realized they were about to get egg on their face, and decided they could play ball after all...

I doubt Qualcomm cares about how they look to the tiny subset of the overall population that cares about things like this, but it wouldn't surprise me if Google basically said to them, "Look, there are other companies out there making tablet and smartphone GPUs..."

I really don't have any use for one of these (especially with a 5.5" phone), but they're practically at the impulse-purchase level price-wise... I love how it has the same resolution as my 24" monitor ha ha...

Proprietary Binaries have long been a hot issue for users of hardware and Linux. For the longest time, the only way to get WiFi drivers was to sideload windows binaries. Hopefully as time goes on these proprietary binaries will simply disappear.

BLOBs will never disappear, in my opinion, because somebody will always be more concerned with protecting their IP than supporting what amounts to a small market segment.

What if the software they want to use in their product has licence terms requiring the release of the source code of derivative works?

Proprietary Binaries have long been a hot issue for users of hardware and Linux. For the longest time, the only way to get WiFi drivers was to sideload windows binaries. Hopefully as time goes on these proprietary binaries will simply disappear.

BLOBs will never disappear, in my opinion, because somebody will always be more concerned with protecting their IP than supporting what amounts to a small market segment.

What if the software they want to use in their product has licence terms requiring the release of the source code of derivative works?

Then they won't use it? That's not the problem with binary blobs. The problem is that the software you want to use (the blob) in your open source product requires that the source not be disclosed.

I strongly suspect someone realized they were about to get egg on their face, and decided they could play ball after all...

I doubt Qualcomm cares about how they look to the tiny subset of the overall population that cares about things like this, but it wouldn't surprise me if Google basically said to them, "Look, there are other companies out there making tablet and smartphone GPUs..."

I really don't have any use for one of these (especially with a 5.5" phone), but they're practically at the impulse-purchase level price-wise... I love how it has the same resolution as my 24" monitor ha ha...

I don't think Qualcomm worries about that section of the market either - but they might worry about the section of the market impacted when CEO's start reading headlines like 'Google Says Qualcomm Prevented Release'. The fact that the CEO wouldn't understand the article actually works against Qualcomm at that point...

Good, hopefully Qualcomm got their asses seared by Google to get this done. Hold the line!

Yeah great and they only had to lose one of their best known developers for it! If that's how it's going to work from now, google will have to get rid of several high profile devs every year.. oh now that's going to work great for them.

Then they won't use it? That's not the problem with binary blobs. The problem is that the software you want to use (the blob) in your open source product requires that the source not be disclosed.

Or has ridiculously onerous redistribution restrictions like "you can only distribute the driver on the device itself, you can't distribute it independently of the device." Such restrictions are overbearing and pointless but the SoC vendors impose them anyway. I know Imagination Technologies (PowerVR) do the same damn thing - it requires a lot of negotiation to get around that requirement, and it appears Google somehow managed to do so and only after device release.

The other thing about proprietary binaries that makes things a mess is if there's any bugs/crashes in a driver, you're effectively trying to look into a black box and hope the bug isn't in that blob, cause if it is... You're SOL to fix it without the vendor. And if it is an older blob, the chances of vendor support drop at a high rate.

Qualcom imediatly start to use kernel driver developed for Freedreno drivers (for GPU's in Qualcom SoC's), as their own code is crap.

Qualcom decide to support Freedreno in documentation, and with code, so that binary drivers are not needed anymore.

Without that we just have same gray status quo. Bad code in kernel (basic code that run everything else on your Android powered device), and not so good GPU driver (if one person can develop comparable driver without any documentation or help from Qualcom, on his own spare time, what is say about GPU driver made by team of full time engeneres with acces to docs, and symulators, and hw?).

I don't think binary drivers really are a big problem in Linux or Android. Maybe they're irritating ideologically to open-source purists but they exist for a reason. Hardware is a very competitive business and the hardware companies don't want to share any information on their products they don't have to.

As long as the drivers are stable, they don't bother me and your average user likely doesn't even know that Android devices use drivers because they never need to see them. I imagine the percentage of users who understand that Android is open source and even what that means isn't very high.

I think this is the sort of thing that only matters to the open-source software community and it seems, based on what's happened so far that the companies that finance the open-source community don't really care what the community wants.

Not sure why you guys are talking about blobs vs open source as the stock firmware images discussed here contain blobs, not sourcecode. People could extract those same blobs from their nexus7s, so Qualcomm isn't actually giving up anything at all-- they were previously acting entirely unreasonably. Now they aren't.

Good, hopefully Qualcomm got their asses seared by Google to get this done. Hold the line!

Yeah great and they only had to lose one of their best known developers for it! If that's how it's going to work from now, google will have to get rid of several high profile devs every year.. oh now that's going to work great for them.

This is a pyrrhic victory at best.

JBQ only quit maintaining the AOSP. He's still at Google. It is a major loss for the community, but his work on android will continue. Whether or not his AOSP work was more important is, of course, quite up for debate.

Not sure why you guys are talking about blobs vs open source as the stock firmware images discussed here contain blobs, not sourcecode. People could extract those same blobs from their nexus7s, so Qualcomm isn't actually giving up anything at all-- they were previously acting entirely unreasonably. Now they aren't.

This is the right answer, and most likely how Google was finally able to pressure them into letting them release them. The hubbub likely helped their case, but people were just going to pirate the blobs from working tablets anyway, just like they do for all the other phones and tablets with qualcomm chipsets that qualcomm won't release blobs for.

Good, hopefully Qualcomm got their asses seared by Google to get this done. Hold the line!

Yeah great and they only had to lose one of their best known developers for it! If that's how it's going to work from now, google will have to get rid of several high profile devs every year.. oh now that's going to work great for them.

This is a pyrrhic victory at best.

I'd say overall loss... JBQ was one of the few out there and interacting with the hacking community... sure, we got then blobs... but we lost a dev....

I don't think binary drivers really are a big problem in Linux or Android. Maybe they're irritating ideologically to open-source purists but they exist for a reason. Hardware is a very competitive business and the hardware companies don't want to share any information on their products they don't have to.

As long as the drivers are stable, they don't bother me and your average user likely doesn't even know that Android devices use drivers because they never need to see them. I imagine the percentage of users who understand that Android is open source and even what that means isn't very high.

I think this is the sort of thing that only matters to the open-source software community and it seems, based on what's happened so far that the companies that finance the open-source community don't really care what the community wants.

Binary drivers aren't. Not being allowed to redistribute them is. Nvidia on desktop Linux is fine with me: its a stable, full-featured driver that works fine and can be distributed in official repos if you don't mind blobs in your distro (I use Arch). And yet, over here, QCom was flat out not allowing that...

JBQ acted like a child over this incident, his postings on twitter and G+ weren't at all professional. This is exactly what happened with the N4. A few days later, images were posted.

Spend 6months on a project and get shafted every single day by lawyers and management and then come back and tell me that with a straight face. Engineers aren't PR people. Engineers don't deal with measured responses. Engineers don't air dirty laundry this publicly. Engineers are very patient on projects they care about. And then engineers snap, lash out at everything and everyone and give up, defeated by bureaucracy, and leave.

I won't be surprised if I see JBQ jump ship to a startup or competitor, nor will I be if he just kills off his public profiles, and I strongly doubt he'll return to the AOSP scene either

JBQ only quit maintaining the AOSP. He's still at Google. It is a major loss for the community, but his work on android will continue. Whether or not his AOSP work was more important is, of course, quite up for debate.

Hopefully as time goes on these proprietary binaries will simply disappear.

Yeah, corporations will happily spill the beans, aka open source, their OpenGL, WiFi etc implementations they paid millions in R&D to develop, just to keep the minority who cares about these things happy. Not.

The realistic thing to hope for is the corps exposing the "glue" code that binds the driver to the OS while keeping the imlementation hidden (like Broadcomm did the RaspPi chip), or at least promise to give out the binaries to AOSP the same day the upgrade is rolled out.

Spend 6months on a project and get shafted every single day by lawyers and management and then come back and tell me that with a straight face. Engineers aren't PR people. Engineers don't deal with measured responses. Engineers don't air dirty laundry this publicly. Engineers are very patient on projects they care about. And then engineers snap, lash out at everything and everyone and give up, defeated by bureaucracy, and leave.

I'm an engineer, and am constantly stymied by politics. As are most other engineers I know. But I've never quit over challenges that exist in pretty much every job.

In the end, he quit over something that ended up being resolved, just like it was with the Nexus 4.

I don't think binary drivers really are a big problem in Linux or Android.

Actually they often are. Particularly when they're built only for Android and work with nothing else, necessitating the creation of things like libhybris - or worse they're built for a single kernel and thus forever lock you to that kernel.

Quote:

Maybe they're irritating ideologically to open-source purists but they exist for a reason.

Mostly inertia and a Microsoft-instilled mindset.

Quote:

Hardware is a very competitive business and the hardware companies don't want to share any information on their products they don't have to.

Yet a great many vendors produce completely open source drivers that are integrated into the kernel. Vendors like Intel have end-to-end open driver stacks.

Quote:

As long as the drivers are stable

And this is very often not the case. Or worse yet, they're only somewhat stable but feature other grievous flaws that kill performance or battery life and can't be fixed.

Quote:

your average user likely doesn't even know that Android devices use drivers because they never need to see them. I imagine the percentage of users who understand that Android is open source and even what that means isn't very high.

Ignorance as a justification is really the saddest of all.

Quote:

I think this is the sort of thing that only matters to the open-source software community and it seems, based on what's happened so far that the companies that finance the open-source community don't really care what the community wants.

No, they don't care. That's why you get Android handsets abandoned within a year of release and it takes so long for devices to get updated to the next OS release (even ignoring the carriers.)

Hopefully as time goes on these proprietary binaries will simply disappear.

Yeah, corporations will happily spill the beans, aka open source, their OpenGL, WiFi etc implementations they paid millions in R&D to develop, just to keep the minority who cares about these things happy. Not.

Virtually all of the value lies in the chip, not the drivers used to interface with the hardware.

I don't think Qualcomm worries about that section of the market either - but they might worry about the section of the market impacted when CEO's start reading headlines like 'Google Says Qualcomm Prevented Release'. The fact that the CEO wouldn't understand the article actually works against Qualcomm at that point...

I won't apologize for manuf's refusing to release source, but I will point out that more often than not, the "trade secret" is what is done in hardware, and what's done in software to keep system costs down and competitive. This is especially true in specialized things like graphics, and why Nvidia doesn't do open source drivers. You don't hand your (probably unpatentable) secrets to your competitors.

Andrew Cunningham / Andrew has a B.A. in Classics from Kenyon College and has over five years of experience in IT. His work has appeared on Charge Shot!!! and AnandTech, and he records a weekly book podcast called Overdue.