This is correct. Just check the "unknown sources" option under settings and you can install apps from pretty much anywhere (web, email, etc) -- the system will show what permissions the app needs and obtain permission to install it (or not) from the user.
The biggest advantage here is that if the "top side" interfaces change, or something needs to change with how the library is compiled (say against glibc for a stock linux platform vs bionic for android), that's pretty trivial to resolve compared with getting a handful or
That's my hope. My issue with the purists is that it's not obviously clear why they want to see the microcode running on a proprietary RISC core inside the GPU, but not for example the Verilog. Stallman is one of the few people who has a self-consistent model of what he wants to be able to see, arguing that code which is "equivalent to a circuit" (i.e. in ROM) need not be made visible. Now we don't meet this criterion as our microcode lives on the SD card, but that's largely a cost and flexibility issue and we may yet go there to get the FSF endorsement.
I consider "ability to redistribute the firmware for use on the hardware it belongs to" totally reasonable, but I definitely fall into the more pragmatic camp.
From one point of view the cost to Broadcom to making this open source is not nearly the same as for the other GPU vendors -- I suspect this RPC glue is not among the crown jewels of Broadcom's IP
I should have kept some of my notes from those meetings
I'm sure they were highly entertaining. Once upon a time I was involved in arguing with a SoC vendor's lawyers over the ability to open source *GPIO* driver support... progress in these areas can be amazingly hard to achieve...
Yup. It's a common solution for video codec blocks, camera pipelines, etc, on ARM SoCs (open driver/library, closed firmware for the peripheral) -- less common for GPUs. I'm personally not at all offended by the "open drivers/libraries on host, closed firmware on peripheral" model -- it's a reasonable tradeoff and, as you point out, lets the vendors keep control over their secret sauce while still allowing for completely open software stacks on the host/AP side of the world. Apart from purists who want to have source for every programmable block on the SoC, everybody wins.
From one point of view the cost to Broadcom to making this open source is not nearly the same as for the other GPU vendors -- I suspect this RPC glue is not among the crown jewels of Broadcom's IP -- but from the viewpoint of someone who doesn't want to have to muck with closed binaries on the host side that are hard to debug, keep supported, adapt to changing APIs/ABIs, none of that matters -- the important bit is you get all the host side source.
Does this (or will this) support future / higher end parts using the same VideoCore architecture? It definitely increases my interest in the BCM SoC family if so...
To be fair, "open drivers / libraries plus proprietary firmware binary to download to hw block" is a better model than "closed userspace libraries/drivers" -- at least you have control/ownership over all the software running on the host side in this model.
Haven't had a chance to wade through all the code here, but it looks an awful lot like it's basically rpc stubs and glue (allocator, buffer management, etc) to remote the OGLES calls to the media processor, which presumably handles all the actual translation of OGLES API to whatever the internal architecture of the GPU looks like. Which is a perfectly reasonable approach, just not necessarily 1:1 with the other SoCs (which don't have a GPU block capable of speaking remoted OGLES, thus requiring knowledge of the underlying hardware "secret sauce" in the GL libraries or drivers on the host side).
Awesome that they're releasing this as open source rather than insisting on keeping it closed -- much easier to work with this way.
We've worked hard to never ship binary blob kernel drivers or any nonsense like that in Nexus devices, but yeah, proprietary userspace libraries are still needed for some peripherals against our best efforts. For wifi/bt it's generally just firmware that's downloaded to the device and not actual code that runs on the Linux side of the world. For the GPU all the vendors we've worked with on Nexus devices have provided GPL'd drivers for the kernel (resource management, etc), but provide closed opengl userspace libraries. Camera stacks vary -- the Nexus S didn't require any proprietary camera library goop in userspace iirc. I think we've been steadily improving the situation, but it's an uphill battle and I don't see a fully-open and also adequately performant GPU/opengl solution on the horizon yet.
Nope. The Nexus 7 has an unlockable bootloader (via fastboot oem unlock), like the Galaxy Nexus, and the Nexus S. Happy Hacking!
By Google? Highly unlikely that we'd ever do that. We're pretty heavily invested in the Linux kernel and it's been working well for us in Android.
By some other entity? Could happen, but the mid and lower layers of the Android stack depend pretty heavily on running on a Linux kernel. It'd be a bunch of work for questionable gain.
Non-carrier-operated app store? Danger Hiptop, 2003. Been there, done that, got (more than one) t-shirt.
Well, it wasn't easy to develop for until about year after launch, since they had no SDK at launch. Excellent spit and polish though on the software and hardware. Apple always nails that last 10%.
Yes, the ICS tree that will be released to AOSP is the same code used to do the build for Galaxy Nexus (among other products).
Instructions on building for Galaxy Nexus will likely end up here (alongside Nexus S):
http://source.android.com/source/building-devices.html
The handful of closed source userspace pieces necessary (some firmware, the hardware opengl libraries, samsung radio library, etc) will end up here:
http://code.google.com/android/nexus/drivers.html
(please disregard the unfortunate use of "drivers" here -- all the kernel drivers are GPLv2, none are closed source)
What's not included is the Google Mobile Apps (gmail, gcalendar, gtalk, maps, etc). These are proprietary Google applications, not part of the core Android platform (which consists of the lower level libraries, dalvik vm, framework libraries, services, core apps like phone, contacts, launcher, settings, etc, etc).
The closed bits on Galaxy Nexus are pretty similar to Nexus S (though the orientation sensor no longer requires a closed library -- one is provided that "adds extra value" but the system works fine without it).
There are remarkably few binary blobs in Android lead devices (some OEMs add more proprietary goop to their own phones though).
http://source.android.com/source/building-devices.html
Nexus S, for example, requires these pieces above and beyond the available open source userspace and kernel code:
- opengl userspace libraries (ImaginationTech)
- radio interface library (Samsung) -- glue between the Android Telephony stack and the Radio
- firmware for bt/wifi chip (Broadcom)
- GPS userspace library (Broadcom)
- NFC firmware / loader library (NXP)
- auto-calibration library for orientation sensor (AKM)
The closed pieces are available here, under a license that allows you to use them in your own builds, and even to redistribute (non-commercially) entire flashable OS images including them.
We continue to work to reduce the number of closed binaries needed on the lead Android devices. We have *never* shipped a lead device that includes any non-gpl/bsd kernel code.
Seems pretty absurd to me. They just launched an Android-based platform with Amazon-customized UI, their apps already run on Android devices (of which there are quite a few out there), and they have their shiny new cloud-assisted browser, built on Android and EC2. What do they need WebOS for? How are they a "fitting home" for it?
"Show business is just like high school, except you get paid." - Martin Mull
