Google announced that they would be holding back with regards to releasing the latest version of the Android operating system. The release in question, Android 3.0 aka Honeycomb aka the version for tablets. The reasoning for this they say is two fold: 1) the code isn’t ready to be released to the public, and 2) they don’t want manufacturers attempting to put Honeycomb on smaller form factor devices (read “mobile phones”).
Then Google announced yesterday that they were going to tighten the requirements on releasing Android based products. More specifically they were going to enforce the clause in their licensing agreement (the one that allows companies to use the “with Google” tag on their devices like the recently released Motorola Xoom) that the devices must meet certain standards and certain objectives must be met.
I want to look at both of these things in this article, because they kind of go hand in hand.
Open Sourcing Code
If you are not familiar with the term “open source” to simplify things (because trust me that term is a can of worms), it basically means that the source code, or rather the application code for a computer program is available to the public to download, modify, and even re-release, if they adhere to the license under which the code was released.
The base Android operating system is open sourced. If you want, you can follow the instructions and download the Android Open Source Project (AOSP) to your computer, modify the code, compile it, and (if brave enough) put it on your device. As newer versions of Android are released on devices, the source code is then placed into the AOSP source code repository. What Google recently announced is that they would be holding back releasing Honeycomb source to the AOSP repository. Lets look at their reasons, and my thoughts on them as well.
But before going further I want to make one thing clear. Google never stated that they would never release the Honeycomb source code. Not once. They just said they weren’t going to release it “rignt now”. There’s a huge difference.
The Code Isn’t Ready for Release
If you’ve followed the Android story, you know that recently Google hired one of the primary user interface (UI) designers from Palm. He was (obviously) tasked with bringing a nicer user experience to Android (something that many people have long complained about). Honeycomb is the first release of this new UI (you could say Android 2.3 was, but really that was nothing more than a new skin, Honeycomb’s UI changes go deep).
When it comes to Honeycomb, the turnaround time on the new tablet version of Android was pretty quick (say around 9 months). And if anyone knows anything about writing code, they probably know that this means the code is hacked together is probably held together with little more than scotch tape. In other words, this isn’t Google’s finest work and so they’re not really wanting to put it out on display to the public just yet.
Also, it was announced (before this announcment, oh how quickly the internet forgets), that much of the user interface changes in Honeycomb would be merged into “Ice Cream” (the next version of the phone OS), and that Google plans to bring all of Android back under a single version again, eliminating the need for two different versions of the OS for different kinds of devices. So when I read this announcement, this was my first thought.
“Of course” I said to myself, “why not wait to release the code when you’re back to a single codebase.”
It makes sense to first clean up the code, and then bring it back in line with the rest of the code so that you can return to a single code base when it’s released.
Non-Tablet Devices
The first Android tablets to hit the market all ran Android 2.2 (ie Frozen Yogurt, aka Froyo). Google advised companies to not do this, stating that Froyo wasn’t designed with tablets in mind. When they made that public statement they also announced that they were in fact working on a version for tablets, and pleaded with manufacturers to hold off on releasing Android based tablets.
Those manufacturers didn’t listen.
So Google is learning from their mistakes. They know they’re going to merge the 2 form factor code bases back into a single code base, they’ve announced as such. They do not want manufacturers putting Honeycomb on phone size devices (the opposite of what was done with the tablets).
This goes back to Google probably wanting to wait until they’re back onto a single code base for all device types before releasing the source code to AOSP.
Google Tightens Their Grip
When Android was first announced, they went to great lengths to push the open source angle. What this open sourcing of Android meant was that manufacturers had a base operating system to build off of. It gave them a fighting edge in the fight against the now (out of the blue) popular Apple iPhone. Really, the iPhone came out and caught every cell phone manufacturer off guard, they didn’t have a plan to compete, Android helped. There was a base OS that they could build on, and many did. Phone makers HTC, Samsung, and Motorola all released devices using Android with their own user interface.
These interfaces (some of them) improve on the user interface of Android. The SenseUI from HTC being fairly popular. But they cause delays when it comes to getting newer versions of Android onto mobile phones because the manufacturers have to make deep modifcations to have the new version of Android work with their third party user interfaces. This in turn leads to what many people have begun calling “fragmentation” and means that there are, at any given moment, a number of different Android versions on phones in the market.
Google also has some language in their license for Android that sets certain requirements for the devices if they want to use the “with Google” branding and install the Google applications suite (Gmail, Android Market, etc). What Google has actually announced is that they will be more strictly enforcing this clause. The end goal, limiting fragmentation. Limiting the number of different versions of Android in the wild at any given moment.
Conclusion
I don’t view either one of these decisions as Google going back on the “Android is open source” mantra. One is just ensuring their best work is in the public repository, and the other is taking just a little more control over the operating system which really just means good things down the road with regards to OS updates and other things related to Android specifically. To me the idea is to bring things more in line to a single way of doing things rather than having a bunch of divergent paths for the Android operating system. The end result being less fragmentation, a single code base, and an overall better experience on Android.
Like this:
Like Loading...
Related
Michael Koby 
Google, Android, and Open Source
Then Google announced yesterday that they were going to tighten the requirements on releasing Android based products. More specifically they were going to enforce the clause in their licensing agreement (the one that allows companies to use the “with Google” tag on their devices like the recently released Motorola Xoom) that the devices must meet certain standards and certain objectives must be met.
I want to look at both of these things in this article, because they kind of go hand in hand.
Open Sourcing Code
If you are not familiar with the term “open source” to simplify things (because trust me that term is a can of worms), it basically means that the source code, or rather the application code for a computer program is available to the public to download, modify, and even re-release, if they adhere to the license under which the code was released.
The base Android operating system is open sourced. If you want, you can follow the instructions and download the Android Open Source Project (AOSP) to your computer, modify the code, compile it, and (if brave enough) put it on your device. As newer versions of Android are released on devices, the source code is then placed into the AOSP source code repository. What Google recently announced is that they would be holding back releasing Honeycomb source to the AOSP repository. Lets look at their reasons, and my thoughts on them as well.
But before going further I want to make one thing clear. Google never stated that they would never release the Honeycomb source code. Not once. They just said they weren’t going to release it “rignt now”. There’s a huge difference.
The Code Isn’t Ready for Release
If you’ve followed the Android story, you know that recently Google hired one of the primary user interface (UI) designers from Palm. He was (obviously) tasked with bringing a nicer user experience to Android (something that many people have long complained about). Honeycomb is the first release of this new UI (you could say Android 2.3 was, but really that was nothing more than a new skin, Honeycomb’s UI changes go deep).
When it comes to Honeycomb, the turnaround time on the new tablet version of Android was pretty quick (say around 9 months). And if anyone knows anything about writing code, they probably know that this means the code is hacked together is probably held together with little more than scotch tape. In other words, this isn’t Google’s finest work and so they’re not really wanting to put it out on display to the public just yet.
Also, it was announced (before this announcment, oh how quickly the internet forgets), that much of the user interface changes in Honeycomb would be merged into “Ice Cream” (the next version of the phone OS), and that Google plans to bring all of Android back under a single version again, eliminating the need for two different versions of the OS for different kinds of devices. So when I read this announcement, this was my first thought.
“Of course” I said to myself, “why not wait to release the code when you’re back to a single codebase.”
It makes sense to first clean up the code, and then bring it back in line with the rest of the code so that you can return to a single code base when it’s released.
Non-Tablet Devices
The first Android tablets to hit the market all ran Android 2.2 (ie Frozen Yogurt, aka Froyo). Google advised companies to not do this, stating that Froyo wasn’t designed with tablets in mind. When they made that public statement they also announced that they were in fact working on a version for tablets, and pleaded with manufacturers to hold off on releasing Android based tablets.
Those manufacturers didn’t listen.
So Google is learning from their mistakes. They know they’re going to merge the 2 form factor code bases back into a single code base, they’ve announced as such. They do not want manufacturers putting Honeycomb on phone size devices (the opposite of what was done with the tablets).
This goes back to Google probably wanting to wait until they’re back onto a single code base for all device types before releasing the source code to AOSP.
Google Tightens Their Grip
When Android was first announced, they went to great lengths to push the open source angle. What this open sourcing of Android meant was that manufacturers had a base operating system to build off of. It gave them a fighting edge in the fight against the now (out of the blue) popular Apple iPhone. Really, the iPhone came out and caught every cell phone manufacturer off guard, they didn’t have a plan to compete, Android helped. There was a base OS that they could build on, and many did. Phone makers HTC, Samsung, and Motorola all released devices using Android with their own user interface.
These interfaces (some of them) improve on the user interface of Android. The SenseUI from HTC being fairly popular. But they cause delays when it comes to getting newer versions of Android onto mobile phones because the manufacturers have to make deep modifcations to have the new version of Android work with their third party user interfaces. This in turn leads to what many people have begun calling “fragmentation” and means that there are, at any given moment, a number of different Android versions on phones in the market.
Google also has some language in their license for Android that sets certain requirements for the devices if they want to use the “with Google” branding and install the Google applications suite (Gmail, Android Market, etc). What Google has actually announced is that they will be more strictly enforcing this clause. The end goal, limiting fragmentation. Limiting the number of different versions of Android in the wild at any given moment.
Conclusion
I don’t view either one of these decisions as Google going back on the “Android is open source” mantra. One is just ensuring their best work is in the public repository, and the other is taking just a little more control over the operating system which really just means good things down the road with regards to OS updates and other things related to Android specifically. To me the idea is to bring things more in line to a single way of doing things rather than having a bunch of divergent paths for the Android operating system. The end result being less fragmentation, a single code base, and an overall better experience on Android.
Share this:
Like this:
Related