Albeit no ARM, it seems valleyview SoC might be the first android runing SoC to have a GPU suported by OSS drivers. Being owner of a motorola atrix, i have learned my lesson, my next phone must have proper oss drivers.
Since you develop android roms, can you tell if there is any other SoC component besides the GPU which requires closed drivers?
Can you also kindly explain why does each device needs its own kernel?
Last edited by Figueiredo; 10-22-2012 at 11:54 AM.
I can't understand why can't google require that in order to use the android brand, device manufacturers would have to mainline any code required in a google branch so that the updates come from google instead of these lazy greedy oems. This should probably make getting the newer android version working easier for the AOSP than it is right now right? And anything helping the android fragmentation should be good for google right? What is it that I'm missing?
Last edited by Figueiredo; 10-22-2012 at 01:02 PM.
I would buy the new chromebook if I had proper gfx driver for it
just saying samsung
Monthly releases are "for-absolutely-fucking-ever?" Over 2.5 million people use CyanogenMod. Do you honestly think they "break almost everything"?
You say CyanogenMod "bastardizes" AOSP, but it is really fairly close to AOSP. There are some added options to allow users to customize their device but they keep it down to a reasonable and usable amount. Beyond this, the primary changes to AOSP are for compatibility of the 100+ devices that CyanogenMod supports. CyanogenMod supports almost every major SoC architecture in one code base and it honestly does it very well, this is something that neither Google or the major OEMs do.
It is great that you build AOSP for your devices but don't act like CyanogenMod and others do nothing of value for the community.
Back to what was originally brought up about CyanogenMod, I don't think Samsung is releasing more source code *just* because of CyanogenMod or other 3rd party distributions of Android. That said, I do think Samsung at least cares about that community to some degree because they made this announcement at a small Android enthusiast conference made up largely of AOSP hackers. In addition, Samsung has also been making a concerted effort to reach out to AOSP hackers through forums and other means. At the end of the day Samsung is really just getting up to the standard of what TI and Qualcomm do with OMAPZoom and Code Aurora respectively.
I could definitely see this being useful in a hypothetical Chromebook CM10/11, and if Android on netbooks turns out to make sense, enthusiasts can get another taste of the future (much like the Nook Color + CM7 hinted at the Nexus 7, i.e. an affordable real android tablet, a year later)
The upside of 'fragmentation' is that such avenues can be explored... unlike, say, being completely unable to port Windows on ARM to one of those little Chinese stick computers. A $100-150 one with Windows and Office might've just saved the Windows desktop from seeming irrelevant, but we'll probably never know.
Because ARM CPUs aren't standardized like x86 is. Each requires a different initialization routine to boot. There's been some recent work in the linux kernel to allow consolidating all these different ARM architectures together, but it is brand new and hasn't migrated over into android yet.