AOSP project on the verge of death? - General Questions and Answers

In case you want to see the source, here it is, but it's in Spanish (though if you're good with google translate...):
http://www.celularis.com/opinion/aosp-android-muere/
Basically it says Android as open source project is being terminated by Google with it's latest decisions and Android releases, at the same time of an even greater increasing dependence on Google. Each time less parts of Android's source code are free since they're now Google services-related. Default basic applications such as a media player, virtual keyboard and messaging now are Google's. Even Jean-Baptiste Querú, main responsible of AOSP, resigned from Google.
The news were indeed disgusting for me. How will this affect CyanogenMod development, for example, or other projects? Will upcoming Android smartphones become just Google smartphones, becoming virtually the same as an iPhone?

???????????

Related

Official statement from Google regarding the Cyanogen controvery

I have no idea where this needs to be posted. There are a number of different threads regarding this topic, and I know at least one of them are locked. So mods, feel free to move, delete or merge this as you see fit.
Google, via the Android Developers Blog, issued a statement a short while back. Here it is ...
A Note on Google Apps for Android
Posted by Dan Morrill on 25 September 2009 at 2:31 PM
Lately we've been busy bees in Mountain View, as you can see from the recent release of Android 1.6 to the open-source tree, not to mention some devices we're working on with partners that we think you'll really like. Of course, the community isn't sitting around either, and we've been seeing some really cool and impressive things, such as the custom Android builds that are popular with many enthusiasts. Recently there's been some discussion about an exchange we had with the developer of one of those builds, and I've noticed some confusion around what is and isn't part of Android's open source code. I want to take a few moments to clear up some of those misconceptions, and explain how Google's apps for Android fit in.
Everyone knows that mobile is a big deal, but for a long time it was hard to be a mobile app developer. Competing interests and the slow pace of platform innovation made it hard to create innovative apps. For our part, Google offers a lot of services — such as Google Search, Google Maps, and so on — and we found delivering those services to users' phones to be a very frustrating experience. But we also found that we weren't alone, so we formed the Open Handset Alliance, a group of like-minded partners, and created Android to be the platform that we all wished we had. To encourage broad adoption, we arranged for Android to be open-source. Google also created and operates Android Market as a service for developers to distribute their apps to Android users. In other words, we created Android because the industry needed an injection of openness. Today, we're thrilled to see all the enthusiasm that developers, users, and others in the mobile industry have shown toward Android.
With a high-quality open platform in hand, we then returned to our goal of making our services available on users' phones. That's why we developed Android apps for many of our services like YouTube, Gmail, Google Voice, and so on. These apps are Google's way of benefiting from Android in the same way that any other developer can, but the apps are not part of the Android platform itself. We make some of these apps available to users of any Android-powered device via Android Market, and others are pre-installed on some phones through business deals. Either way, these apps aren't open source, and that's why they aren't included in the Android source code repository. Unauthorized distribution of this software harms us just like it would any other business, even if it's done with the best of intentions.
I hope that clears up some of the confusion around Google's apps for Android. We always love seeing novel uses of Android, including custom Android builds from developers who see a need. I look forward to seeing what comes next!
Click to expand...
Click to collapse
Source:
http://android-developers.blogspot.com/2009/09/note-on-google-apps-for-android.html
Yep, it's over.
We're still asking for community access to these applications that are almost essential to the current Android experience. I really doubt it's hurting their bottom line substantially enough to justify the killing of their distribution.
In other words, Mr. Morrill's post was pretty much a sugarcoated attempt to gain some of the PR they lost.
We always love seeing novel uses of Android, including custom Android builds from developers who see a need.
Click to expand...
Click to collapse
A "novel" use from a developer who "sees a need" is quite a way to describe a substantially improved version of your OS.
So what is the conclusion? A lot of the things could be replaced, but as mentioned before, the sync tools and so forth are tricky to get around. What is the next step from here?
cyanogen said:
Yep, it's over.
Click to expand...
Click to collapse
How so? What would be wrong with releasing the ROM without the google apps, but have a script or something that runs on first boot that installs the missing apps?
cyanogen said:
Yep, it's over.
Click to expand...
Click to collapse
So no more ROMs? Or no more ROMs with close-source apps?
AquaVita said:
How so? What would be wrong with releasing the ROM without the google apps, but have a script or something that runs on first boot that installs the missing apps?
Click to expand...
Click to collapse
It's still illegal. A clever trick to walk around the legal fine print. But in essence, it's illegal...
AquaVita said:
How so? What would be wrong with releasing the ROM without the google apps, but have a script or something that runs on first boot that installs the missing apps?
Click to expand...
Click to collapse
Without the basic function to sign into the device using your Google credentials, the ROM is useless. You can't just grab them from another build (as far as I know) because of the way they are tied in at compiling to the framework. So you would have to pull the ROM, grab the proprietary pieces from somewhere else, and compile the source yourself.
Right?
To touch on this in another way, what would it take for Cyanogen to become a licensed distributor of Google's Apps for Android? If there are really 30,000 users, couldn't legal fees be gathered from them? And, couldn't the business license be set up as a Not-For-Profit? Like the Association of Cyanogen Followers? If it were, wouldn't the required fees to license the distribution rights of the software be tax-free and operating expenses for the association? Meaning, any costs for running the business could be taken out of membership dues and donations? With the rest being tax write-offs?
Just a thought, as I would love to see this made legit, 4.0.4 is great, but I don't want this to stop here.... selfish I know, but it's the truth.
AquaVita said:
How so? What would be wrong with releasing the ROM without the google apps, but have a script or something that runs on first boot that installs the missing apps?
Click to expand...
Click to collapse
I guees thats no way. What if you have a wipe? No APNs or anything else? You cant dowmload "Market" als a single-app directly from google (as i know).
daveid said:
Without the basic function to sign into the device using your Google credentials, the ROM is useless. You can't just grab them from another build (as far as I know) because of the way they are tied in at compiling to the framework. So you would have to pull the ROM, grab the proprietary pieces from somewhere else, and compile the source yourself.
Right?
Click to expand...
Click to collapse
Then what the hell is google talking about "encouraging other ROM releases"? If that isn't possible without some pieces of Google software, then is it literally impossible to develop a custom ROM for android?
Thoughts, Cyanogen?
As soon as my contract is I am Too! I can predict a mass exit from android and google!
daveid said:
Without the basic function to sign into the device using your Google credentials, the ROM is useless. You can't just grab them from another build (as far as I know) because of the way they are tied in at compiling to the framework. So you would have to pull the ROM, grab the proprietary pieces from somewhere else, and compile the source yourself.
Right?
Click to expand...
Click to collapse
Is this true? If its proprietary how did CY compile them in the first place? In order to compile don't you need access to the source?
So just come up with replacements for those apps that are closed source and not available on the market...
Devs WILL find a way... I guarantee you
But yeah, Google SUCKS on this...They could have just given him limited licensing...
Without a doubt the most foolish decision I've seen Google make in terms of Android so far. This puts a major damper on a community that was helping make Android better in very real ways.
The only explanation I can come up with is that the closed apps use 3rd party licensed code that Google can't redistribute. Otherwise this is just completely boneheaded.
Google said:
With a high-quality open platform in hand, we then returned to our goal of making our services available on users' phones. That's why we developed Android apps for many of our services like YouTube, Gmail, Google Voice, and so on. These apps are Google's way of benefiting from Android in the same way that any other developer can, but the apps are not part of the Android platform itself. We make some of these apps available to users of any Android-powered device via Android Market, and others are pre-installed on some phones through business deals. Either way, these apps aren't open source, and that's why they aren't included in the Android source code repository. Unauthorized distribution of this software harms us just like it would any other business, even if it's done with the best of intentions.
Click to expand...
Click to collapse
They claim these apps (YouTube, Gmail, etc) are Googles way to benefiting from Android, but they are not distributed with all android phones? I understand that companies license these applications from Google, but how does it hurt them if they are installed on a device that would already have them?
Then they say "We make some of these apps available to users of any Android-powered device via Android Market", yet this entire thing came about because the Android Market is being distributed? How can any device get these if the market is one thing that can not be distributed?
I paid for the ADP1, which came with Gmail, YouTube and the other applications. The ADP1 feature was that I could flash any ROM I wanted to on the device, but now they are telling me that I can't put one on there if it contains their applications that my device had in the first place.
Hello Google, welcome to the the Dark side, so much for "Don't be evil"
I will help with anything I can on a project to replace the Google Products.
AquaVita said:
How so? What would be wrong with releasing the ROM without the google apps, but have a script or something that runs on first boot that installs the missing apps?
Click to expand...
Click to collapse
ya i was thinking the same .i mean if not ,how do we get gmail ,youtube,ect?do we have to download from market ? some are not in market like youtube.i use gmail all the time .
Do the current Roms have to pulled?
That shiny device with an Apple on it is looking mighty delicious
CyanogenMod officially done now:
http://twitter.com/cyanogen
"Sorry everyone, CyanogenMod in it's current state is done. I am violating Google's license by redistributing their applications."
dwang said:
Is this true? If its proprietary how did CY compile them in the first place? In order to compile don't you need access to the source?
Click to expand...
Click to collapse
I had assumed that they were "reverse-engineered" using something like baksmali, to gain access to the source.... I could be wrong.

READ ME: Clearing Misconceptions About CyanogenMod C&D

Lately a lot of threads have been popping up on this subforum and others with regard to the CyanogenMod C&D. A lot of these long threads seem to just be giant echo chambers filled with uninformed or ignorant end-users who don't understand the true nature of the situation. I am creating this thread to help clear up the misconceptions surrounding CyanogenMod, the AOSP, and Google's position in this matter.
Here are some common misconceptions and their clarifications:
"We should petition to keep Android open source!"
Click to expand...
Click to collapse
Google acquired Android, Inc. in 2005 and began investing time and manpower to develop the Android operating system into a fully fledged mobile operating system. The entire project was open sourced in October 2008 to coincide with the first public availability of the Dream hardware. Since then, the Android Open Source Project (which consists of all the source code required to build a working Android environment) has been completely open source. Period.
On top of the completely open source operating system, Google also bundled several useful applications into many stock builds of Android. These builds are commonly referred to as "Google Experience" builds, and the apps include things like the Market, GMail, Youtube, etc. These are NOT a part of the Android Open Source Project, they NEVER WERE a part, and it is unlikely that they ever will be. Many end users seem to have the misconception that these apps are and/or should be a part of the AOSP. They are not. Period.
"Google is trying to keep me from installing other ROMs [sic]!"
Click to expand...
Click to collapse
The C&D letter to Cyanogen was not meant to suppress users from using non-official builds ("ROMs"). The purpose of the cease and desist letter was to stop Cyanogen from continuing to redistribute without permission the proprietary Google-specific apps described above. This is completely within Google's right to do so.
Now to be fair, the work done on xda has often skirted the matter of unauthorized redistribution. In fact, without unauthorized redistribution, it would be difficult (but not impossible) to "cook ROMs". However, unauthorized redistribution has generally been viewed as an unspoken, ungranted privilege. If the company holding the rights to the related software issues a cease and desist letter, the community must respect that choice. To fail to do so would only serve to delegitimize what we do here and risk the survival of the os hacking community as a whole. Users with an overinflated sense of entitlement, you are not welcome here!
"I bought the phone, I should have a right to use the proprietary Google software however I like."
Click to expand...
Click to collapse
Generally, being legally licensed to run a software package does still impose limitations on your usage of it (e.g. you cannot make unauthorized copies or disassemble it). However, in this case, the violation is not in the end-user act of installing CyanogenMod, it is with Cyanogen distributing it. And by no means is this singling out Cyanogen; any "ROM cooker" that includes copyrighted proprietary software in the updater (which at this point is the majority of them) is potentially risking a legal letter.
"Google should not have waited until Cyanogen had worked so much to shut him down!"
Click to expand...
Click to collapse
As in #2, I have to emphasize that unauthorized redistribution is something of an unspoken tacit permission. "ROM cookers" therefore need to exercise good judgement. Back when builds were simply slightly modified versions of stock update.zip files, it was easy for Google to turn a blind eye. The latest CyanogenMod installer included a leaked pre-release version of the Android Market software. Now, I hope it's plainly obvious for even the most oblivious reader, but if you leak a company's unreleased proprietary software before their official release, chances are you will piss them off. Leaks like this have several potentially negative consequences for companies: 1) decreased perceived quality because the program had not been fully debugged, 2) ruining planned launch timelines, 3) causing server backend issues due to unrecognized clients logging in.
Bottom line is this: if you are a "ROM cooker" and you absolutely have to include proprietary copyrighted software in your build, DO NOT INCLUDE ANY UNRELEASED SOFTWARE. You will very likely get C&D'd.
"Google should appreciate Cyanogen's hard work!"
Click to expand...
Click to collapse
From the time you boot up your phone to when you run that first app, probably somewhere like only 1% of the code is written by the "ROM cook". The process of "cooking a ROM" is not, for the most part, programming.
If you want to give credit where credit is due, for the most part you would be thanking Linus Torvalds and the contributors of the Linux kernel, the Android Open Source Project team, and the folks who really did the groundbreaking work establishing root access on the Dream.
good post!
Agreed, very good post..
Maybe someone can clear something up for me (its been bugging me a little)
If i compile from source i need to add files that are pulled from my phone.
Does this mean that ALL roms are technically illegal, even if they dont include the google closed source programs.
Or are we ok to include these files as they are needed for the phone to work, so considered closed source but part of asop?
I have not seen this addressed and i am curious what the state of play is with these files.
Agreed ........ !
Thank you for taking the time to clear things up. Hopefully this will help folks gain some perspective and move toward productive directions.
If i compile from source i need to add files that are pulled from my phone.
Does this mean that ALL roms are technically illegal, even if they dont include the google closed source programs.
Or are we ok to include these files as they are needed for the phone to work, so considered closed source but part of aosp?
Click to expand...
Click to collapse
Good question. It certainly means the ROM is not purely open-source, at the least.
My sense is that those files are the property of HTC and we don't have a license to redistribute them.
Now I don't really expect HTC to serve anyone with a C&D anytime soon, for various reasons, but until a ROM cook gets a written license to redistribute those files from HTC, or until a fully open-source rewrite of those files is done, it's a gray area at the very least.
vixsandlee said:
Does this mean that ALL roms are technically illegal, even if they dont include the google closed source programs.
Click to expand...
Click to collapse
Speaking very technically: yes, because you do not have the express right to redistribute the binary drivers for things like the wifi module or the radio. In reality, these pieces of code are so tightly tied to the hardware that it is unlikely you will get a c&d for redistributing them. However, in the hardcore open source community, even these drivers will be left out, requiring the user to fetch them for him/herself. That would be the 100% license-compliant way.
I'm pleased to say though, there are already many people working on semi and full license compliance methods and "ROMs". Just take a look at the first two pages of this subforum.
vixsandlee said:
If i compile from source i need to add files that are pulled from my phone.
Does this mean that ALL roms are technically illegal, even if they dont include the google closed source programs.
Or are we ok to include these files as they are needed for the phone to work, so considered closed source but part of asop?
Click to expand...
Click to collapse
Read the post again. It's illegal to even copy the Google APKs files out of an original installation and import it into a custom ROM. The major issue was that all ROM creators were importing the Google Apps which are "closed-source" into their own legal open-source code.
I guess now, it'll be down to the individual to decide whether they want the Google Apps in their phone. That's why scripts have been created to give the user a choice on whether to do the illegal act of placing the Google Apps onto their phone.
Google are unlikely going to chase you the individual down rather than the ROM creator (like in Cyanogen's case with the C&D letter).
Hope this helps.
ok. so then all this is not because of the google propriatary crap, but because he released the market early, so google just USED this BS reason to stop that? in other words, had he not released it early, nothing would have happened?
if thats the case, i dont blame cyanogen, but i blame ALL those GREEDY users that MUST have EVERYTHING before everyone else because they feel they need to be the best. you greedy punks almost ruined it for everyone. from what i see cyanogen usually tries his best to do what the people want, had the people not wanted the market so early(its not even that great, just new colors "ooohhh wooow ive never seen colors before i must have that! and now!".. ridiculous.) then this wouldnt happen.
now from i see the latest and "greatest" usually comes in the experimental releases. i think, cyanogen should shut down the experimental releases, or only release them to certain people.. or make it a lot LESS public..that way he can keep testing the stuff till its good and then release it as stable when he sees fit. i mean come on, 4.0.4 is already awesome!! i love it! been using since forever. why couldnt everyone else just be happy with 4.0.4?
and like the post said, dont be stupid and release some leaked program. cause it doesnt just shut you down its gonna shut everyone down. unfortunately i see that soon some noob working on hero roms is gonna release something, and then HTC will be here next.
oh and add this in there:
My guess is that Google has known for some time what was going on, but probably thought 'best not to upset the apple cart' while Android was in its infancy, with only one or two devices from a single manufacturer available on a single carrier. Now that we are on the verge of Android devices being shipped from at least five hardware vendors with over half a dozen carriers, Google probably felt that they needed to get a handle on this. I sense they feared things getting out of control with modders doing willy-nilly ports of innovations from one vendor/carrier to another—e.g., Motoblur on HTC devices and HTC Sense on Motorola devices. I think Google's legal team had a strong part in what took place, and forced action.
Click to expand...
Click to collapse
and i just saw a rom that got some of the motoblur stuff mixed with hero and for the g1. how long do you think till motorola and HTC are here complaining about software on the g1 that isnt supposed to be?
Why don't Google offer these closed-source apps like they do for Google Maps? They could only benefit from more users having the 'Google Experience', even though their phones don't have them pre-installed.
TunsterX2 said:
I guess now, it'll be down to the individual to decide whether they want the Google Apps in their phone. That's why scripts have been created to give the user a choice on whether to do the illegal act of placing the Google Apps onto their phone.
Click to expand...
Click to collapse
If a user downloads a "ROM" without Google apps on it, downloads an official update.zip from google.com, and then copies the Google apps from the official update into the cooked "ROM", that completely mitigates the problem of unauthorized distribution and only leaves the much less sticky issue of unauthorized usage. Unauthorized usage is typically a lot less offensive to the interested companies and definitely a lot less enforceable. There are likely some EULAs somewhere governing the usage of the Google apps (GMail, Market, etc) and except for Market I would be surprised if they explicitly required the app to run on authorized distributions only. But again like I said, it would be difficult to detect, let alone enforce.
peshkata said:
Why don't Google offer these closed-source apps like they do for Google Maps? They could only benefit from more users having the 'Google Experience', even though their phones don't have them pre-installed.
Click to expand...
Click to collapse
That's a very good question, and one I sure would like the Android team at Google to answer. The only app I see being a problem would be Market, since it requires a secured app-private to function properly (which would not be guaranteed on a non-GE phone).
Your post nicely presents the legal aspects and rights of Google but IMHO misses the larger point. The open source community was believing in the ideals of open source and looking the other way at the control Google has over this platform. The pieces that Google controls are not easily (if ever practically) replaceable.
Google actions show that they are not that much different than Apple in trying to control the platform and the user experience. Don't be surprised to see Google behave more and more like Apple as the platform gets stronger and Google's need of an open community weakens.
The only bright spot is one that Google may have missed - that is their existing fight with Apple and AT&T regarding GoogleVoice. Their actions against Cyanogen gives Apple and AT&T ammunition in their arguments with the FCC, which is the last thing Google wants.
This is the only lever this community has over Google. Bring up the FCC and Google Voice case, and Google may back off.
For those who pray for Cyanogen to be hired by Google -- that is the last thing you want. We do not need Google having more control over him, but less.
For those who think that creating bypasses with clean roms and user-initiated backups will solve these problem -- these are short-term technical workarounds which Google could close too.
so with it being technically illegal its pointless (IMHO) being open source.
Its fine with taking from the community, but google seem unwilling to give anything back.
Roll on when full open source roms appear, It would be like a linux distro coming with everything but keyboard and mouse drivers.
This is all legally correct. But it misses the point of the uproar.
We did not expect Android to devolve into a squabble over closed source bits when the whole premise is open source. Goog has disappointed, plain and simple. Your sticky is an apologist's point of view since it doesn't address that fundamental issue.
edit: btw, if Goog was upset about the new Market app specifically, they could have blocked its access to the market using a client-check.
rbrahmson said:
This is the only lever this community has over Google. Bring up the FCC and Google Voice case, and Google may back off.QUOTE]
well think about it. where would google make more money, in allowing the deals it made with htc and motorola and stuff to fall apart because they allow none licensed people do distribute there apps, but keeping the community with them, and winning with google voice... OR in screw the community, keeping the deals on good grounds, and losing the google voice fight? seeing how apple is STILL WAY ahead of android in terms of users, its tough. because its basically, either google kills its own OS for phones, or starts letting go of the iphone ideas by starting with screwing the google voice. honestly, from what i can see, google is gonna come out losing either way lol
then again it is GOOGLE. they never loses anything =/ though with that BING thing growing.. the giant may go down some day. its getting attacked on all sides
Click to expand...
Click to collapse
vixsandlee said:
so with it being technically illegal its pointless (IMHO) being open source.
Click to expand...
Click to collapse
That depends on what your objective is. Open source has many benefits, and many of those are retained even if your distribution contains some closed-source elements. Another important aspect to remember is that while x86 PCs have had three decades to mature, smartphones have not had that same luxury. Given enough time, even hw drivers will become open sourced. So "pointless" is a bit hyperbolic.
Its fine with taking from the community, but google seem unwilling to give anything back.
Click to expand...
Click to collapse
The spirit of open source is the spirit of giving. In that vein, Google has invested considerable time building parts of the AOSP from scratch. To say that they are "unwilling to give anything back" is just a plain falsehood.
Roll on when full open source roms appear, It would be like a linux distro coming with everything but keyboard and mouse drivers.
Click to expand...
Click to collapse
Good luck finding an open source 3G radio driver.
If anyone has read any of the dialog between Steve (cyanogen) and some other Google employees about this issue (most notably JBQ), you would realize that the Google employees are trying to work with Steve.
There is dialog about making the AOSP able to be built and fully functional and distributable without infringing on anyone's rights. This includes investigating other avenues for users to acquire and legally install the Google applications.
The current belief is that Google's legal team sent the C&D letter to Steve, and that it was not done so at the request of the Android developers. They most likely would have liked to work with him quietly and amicably.
Also, please remember that the Market application is not a part of AOSP. The Market application is Google's proprietary code; it is not part of the Android base. Not all Android devices have Google's Market—that is why there are other markets and means of installing software.
I have no doubt that this "controversy" will ultimately be for the best. I believe that Steve, JBQ and the rest of Google/Android will find a middle ground that will work best for everyone. (JBQ has an excellent history of working with other developers and finding good solutions for all—I remember back when he was working at Be and how helpful he was to all of those writing applications for BeOS.)
ytj87 said:
We did not expect Android to devolve into a squabble over closed source bits when the whole premise is open source.
Click to expand...
Click to collapse
So what you're saying is you expected everything included in a Google Experience phone to be open source? I think the problem here is you (and the people you lump into "we") don't understand that Android isn't just built for users, it's also built for handset manufacturers. Quote from the OHA website:
Why did you pick the Apache v2 open source license?
Apache is a commercial-friendly open source license. The Apache license allows manufacturers and mobile operators to innovate using the platform without the requirement to contribute those innovations back to the open source community. Because these innovations and differentiated features can be kept proprietary, manufacturers and mobile operators are protected from the "viral infection" problem often associated with other licenses.
Click to expand...
Click to collapse
In light of that, I don't feel its necessary to dignify the rest of your post with a response.
peshkata said:
Why don't Google offer these closed-source apps like they do for Google Maps? They could only benefit from more users having the 'Google Experience', even though their phones don't have them pre-installed.
Click to expand...
Click to collapse
Because they charge companies like T-Mobile to offer the phone "With Google". If Google put them on the market, then, according to google, any android device would be able to get these applications. So why would T-Mobile pay to have them included. This how Google makes money off of android, this is why they bought it in the first place. They didn't develop android for the open source community, they are a publicly traded company, all their share holders want to know is "How is this going to make use money?". But it is great that the platform is open.
But that brings up Google's "response" where they state any android device can get applications via the Android Market. How can ANY android device get these applications from the market, if only "With Google" devices ship with the market...

【ROM 4.3.1【UN-OFFICIAL PURE AOSP】InsomniaAOSP【10/22/13 v.1.0】

【ROM 4.3.1【UN-OFFICIAL PURE AOSP】InsomniaAOSP【10/22/13 v.1.0】
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Open Source
What is the Android Open Source Project?
We use the phrase "Android Open Source Project" or "AOSP" to refer to the people, the processes, and the source code that make up Android.
The people oversee the project and develop the actual source code. The processes refer to the tools and procedures we use to manage the development of the software. The net result is the source code that you can use to build cell phone and other devices.
Why did we open the Android source code?
Google started the Android project in response to our own experiences launching mobile apps. We wanted to make sure that there would always be an open platform available for carriers, OEMs, and developers to use to make their innovative ideas a reality. We also wanted to make sure that there was no central point of failure, so that no single industry player could restrict or control the innovations of any other. The single most important goal of the Android Open-Source Project (AOSP) is to make sure that the open-source Android software is implemented as widely and compatibly as possible, to everyone's benefit.
You can find more information on this topic at our Project Philosophy page.
What kind of open-source project is Android?
Google oversees the development of the core Android open-source platform, and works to create robust developer and user communities. For the most part the Android source code is licensed under the permissive Apache Software License 2.0, rather than a "copyleft" license. The main reason for this is because our most important goal is widespread adoption of the software, and we believe that the ASL2.0 license best achieves that goal.
You can find more information on this topic at our Project Philosophy and Licensing pages.
Why is Google in charge of Android?
Launching a software platform is complex. Openness is vital to the long-term success of a platform, since openness is required to attract investment from developers and ensure a level playing field. However, the platform itself must also be a compelling product to end users.
That's why Google has committed the professional engineering resources necessary to ensure that Android is a fully competitive software platform. Google treats the Android project as a full-scale product development operation, and strikes the business deals necessary to make sure that great devices running Android actually make it to market.
By making sure that Android is a success with end users, we help ensure the vitality of Android as a platform, and as an open-source project. After all, who wants the source code to an unsuccessful product?
Google's goal is to ensure a successful ecosystem around Android, but no one is required to participate, of course. We opened the Android source code so anyone can modify and distribute the software to meet their own needs.
What is Google's overall strategy for Android product development?
We focus on releasing great devices into a competitive marketplace, and then incorporate the innovations and enhancements we made into the core platform, as the next version.
In practice, this means that the Android engineering team typically focuses on a small number of "flagship" devices, and develops the next version of the Android software to support those product launches. These flagship devices absorb much of the product risk and blaze a trail for the broad OEM community, who follow up with many more devices that take advantage of the new features. In this way, we make sure that the Android platform evolves according to the actual needs of real-world devices.
How is the Android software developed?
Each platform version of Android (such as 1.5, 1.6, and so on) has a corresponding branch in the open-source tree. At any given moment, the most recent such branch will be considered the "current stable" branch version. This current stable branch is the one that manufacturers port to their devices. This branch is kept suitable for release at all times.
Simultaneously, there is also a "current experimental" branch, which is where speculative contributions, such as large next-generation features, are developed. Bug fixes and other contributions can be included in the current stable branch from the experimental branch as appropriate.
Finally, Google works on the next version of the Android platform in tandem with developing a flagship device. This branch pulls in changes from the experimental and stable branches as appropriate.
You can find more information on this topic at our Branches and Releases.
Why are parts of Android developed in private?
It typically takes over a year to bring a device to market, but of course device manufacturers want to ship the latest software they can. Developers, meanwhile, don't want to have to constantly track new versions of the platform when writing apps. Both groups experience a tension between shipping products, and not wanting to fall behind.
To address this, some parts of the next version of Android including the core platform APIs are developed in a private branch. These APIs constitute the next version of Android. Our aim is to focus attention on the current stable version of the Android source code, while we create the next version of the platform as driven by flagship Android devices. This allows developers and OEMs to focus on a single version without having to track unfinished future work just to keep up. Other parts of the Android system that aren't related to application compatibility are developed in the open, however. It's our intention to move more of these parts to open development over time.
When are source code releases made?
When they are ready. Some parts of Android are developed in the open, so that source code is always available. Other parts are developed first in a private tree, and that source code is released when the next platform version is ready.
In some releases, core platform APIs will be ready far enough in advance that we can push the source code out for an early look in advance of the device's release; however in others, this isn't possible. In all cases, we release the platform source when we feel the version has stabilized enough, and when the development process permits. Releasing the source code is a fairly complex process.
What is involved in releasing the source code for a new Android version?
Releasing the source code for a new version of the Android platform is a significant process. First, the software gets built into a system image for a device, and put through various forms of certification, including government regulatory certification for the regions the phones will be deployed. It also goes through operator testing. This is an important phase of the process, since it helps shake out a lot of software bugs.
Once the release is approved by the regulators and operators, the manufacturer begins mass producing devices, and we turn to releasing the source code.
Simultaneous to mass production the Google team kicks off several efforts to prepare the open source release. These efforts include final API changes and documentation (to reflect any changes that were made during qualification testing, for example), preparing an SDK for the new version, and launching the platform compatibility information.
Also included is a final legal sign-off to release the code into open source. Just as open source contributors are required to sign a Contributors License Agreement attesting to their IP ownership of their contribution, Google too must verify that it is clear to make contributions.
Starting at the time mass production begins, the software release process usually takes around a month, which often roughly places source code releases around the same time that the devices reach users.
How does the AOSP relate to the Android Compatibility Program?
The Android Open-Source Project maintains the Android software, and develops new versions. Since it's open-source, this software can be used for any purpose, including to ship devices that are not compatible with other devices based on the same source.
The function of the Android Compatibility Program is to define a baseline implementation of Android that is compatible with third-party apps written by developers. Devices that are "Android compatible" may participate in the Android ecosystem, including Google Play; devices that don't meet the compatibility requirements exist outside that ecosystem.
In other words, the Android Compatibility Program is how we separate "Android compatible devices" from devices that merely run derivatives of the source code. We welcome all uses of the Android source code, but only Android compatible devices -- as defined and tested by the Android Compatibility Program -- may participate in the Android ecosystem.
How can I contribute to Android?
There are a number of ways you can contribute to Android. You can report bugs, write apps for Android, or contribute source code to the Android Open-Source Project.
There are some limits on the kinds of code contributions we are willing or able to accept. For instance, someone might want to contribute an alternative application API, such as a full C++-based environment. We would decline that contribution, since Android is focused on applications that run in the Dalvik VM. Alternatively, we won't accept contributions such as GPL or LGPL libraries that are incompatible with our licensing goals.
We encourage those interested in contributing source code to contact us via the AOSP Community page prior to beginning any work. You can find more information on this topic at the Getting Involved page.
How do I become an Android committer?
The Android Open Source Project doesn't really have a notion of a "committer". All contributions -- including those authored by Google employees -- go through a web-based system known as "gerrit" that's part of the Android engineering process. This system works in tandem with the git source code management system to cleanly manage source code contributions.
Once submitted, changes need to be accepted by a designated Approver. Approvers are typically Google employees, but the same approvers are responsible for all submissions, regardless of origin.
You can find more information on this topic at the Submitting Patches page.
Compatibility
What does "compatibility" mean?
We define an "Android compatible" device as one that can run any application written by third-party developers using the Android SDK and NDK. We use this as a filter to separate devices that can participate in the Android app ecosystem, and those that cannot. Devices that are properly compatible can seek approval to use the Android trademark. Devices that are not compatible are merely derived from the Android source code and may not use the Android trademark.
In other words, compatibility is a prerequisite to participate in the Android apps ecosystem. Anyone is welcome to use the Android source code, but if the device isn't compatible, it's not considered part of the Android ecosystem.
What is the role of Google Play in compatibility?
Devices that are Android compatible may seek to license the Google Play client software. This allows them to become part of the Android app ecosystem, by allowing users to download developers' apps from a catalog shared by all compatible devices. This option isn't available to devices that aren't compatible.
What kinds of devices can be Android compatible?
The Android software can be ported to a lot of different kinds of devices, including some on which third-party apps won't run properly. The Android Compatibility Definition Document (CDD) spells out the specific device configurations that will be considered compatible.
For example, though the Android source code could be ported to run on a phone that doesn't have a camera, the CDD requires that in order to be compatible, all phones must have a camera. This allows developers to rely on a consistent set of capabilities when writing their apps.
The CDD will evolve over time to reflect market realities. For instance, the 1.6 CDD only allows cell phones, but the 2.1 CDD allows devices to omit telephony hardware, allowing for non-phone devices such as tablet-style music players to be compatible. As we make these changes, we will also augment Google Play to allow developers to retain control over where their apps are available. To continue the telephony example, an app that manages SMS text messages would not be useful on a media player, so Google Play allows the developer to restrict that app exclusively to phone devices.
If my device is compatible, does it automatically have access to Google Play and branding?
Google Play is a service operated by Google. Achieving compatibility is a prerequisite for obtaining access to the Google Play software and branding. Device manufacturers should contact Google to obtain access to Google Play.
If I am not a manufacturer, how can I get Google Play?
Google Play is only licensed to handset manufacturers shipping devices. For questions about specific cases, contact [email protected].
How can I get access to the Google apps for Android, such as Maps?
The Google apps for Android, such as YouTube, Google Maps and Navigation, Gmail, and so on are Google properties that are not part of Android, and are licensed separately. Contact [email protected] for inquiries related to those apps.
Is compatibility mandatory?
No. The Android Compatibility Program is optional. Since the Android source code is open, anyone can use it to build any kind of device. However, if a manufacturer wishes to use the Android name with their product, or wants access to Google Play, they must first demonstrate that the device is compatible.
How much does compatibility certification cost?
There is no cost to obtain Android compatibility for a device. The Compatibility Test Suite is open-source and available to anyone to use to test a device.
How long does compatibility take?
The process is automated. The Compatibility Test Suite generates a report that can be provided to Google to verify compatibility. Eventually we intend to provide self-service tools to upload these reports to a public database.
Who determines what will be part of the compatibility definition?
Since Google is responsible for the overall direction of Android as a platform and product, Google maintains the Compatibility Definition Document for each release. We draft the CDD for a new Android version in consultation with a number of OEMs, who provide input on its contents.
How long will each Android version be supported for new devices?
Since Android's code is open-source, we can't prevent someone from using an old version to launch a device. Instead, Google chooses not to license the Google Play client software for use on versions that are considered obsolete. This allows anyone to continue to ship old versions of Android, but those devices won't use the Android name and will exist outside the Android apps ecosystem, just as if they were non-compatible.
Can a device have a different user interface and still be compatible?
The Android Compatibility Program focuses on whether a device can run third-party applications. The user interface components shipped with a device (such as home screen, dialer, color scheme, and so on) does not generally have much effect on third-party apps. As such, device builders are free to customize the user interface as much as they like. The Compatibility Definition Document does restrict the degree to which OEMs may alter the system user interface for areas that do impact third-party apps.
When are compatibility definitions released for new Android versions?
Our goal is to release new versions of Android Compatibility Definition Documents (CDDs) once the corresponding Android platform version has converged enough to permit it. While we can't release a final draft of a CDD for an Android software version before the first flagship device ships with that software, final CDDs will always be released after the first device. However, wherever practical we will make draft versions of CDDs available.
How are device manufacturers' compatibility claims validated?
There is no validation process for Android device compatibility. However, if the device is to include Google Play, Google will typically validate the device for compatibility before agreeing to license the Google Play client software.
What happens if a device that claims compatibility is later found to have compatibility problems?
Typically, Google's relationships with Google Play licensees allow us to ask them to release updated system images that fix the problems.
Compatibility Test Suite
What is the purpose of the CTS?
The Compatibility Test Suite is a tool used by device manufacturers to help ensure their devices are compatible, and to report test results for validations. The CTS is intended to be run frequently by OEMs throughout the engineering process to catch compatibility issues early.
What kinds of things does the CTS test?
The CTS currently tests that all of the supported Android strong-typed APIs are present and behave correctly. It also tests other non-API system behaviors such as application lifecycle and performance. We plan to add support in future CTS versions to test "soft" APIs such as Intents as well.
Will the CTS reports be made public?
Yes. While not currently implemented, Google intends to provide web-based self-service tools for OEMs to publish CTS reports so that they can be viewed by anyone. CTS reports can be shared as widely as manufacturers prefer.
How is the CTS licensed?
The CTS is licensed under the same Apache Software License 2.0 that the bulk of Android uses.
Does the CTS accept contributions?
Yes please! The Android Open-Source Project accepts contributions to improve the CTS in the same way as for any other component. In fact, improving the coverage and quality of the CTS test cases is one of the best ways to help out Android.
Can anyone use the CTS on existing devices?
The Compatibility Definition Document requires that compatible devices implement the 'adb' debugging utility. This means that any compatible device -- including ones available at retail -- must be able to run the CTS tests.
Click to expand...
Click to collapse
SOURCE
Click to expand...
Click to collapse
INITIAL RELEASE 10/22/2013 @ 5:54 am
Click to expand...
Click to collapse
InsomniaAOSP v1.0
Click to expand...
Click to collapse
Standard Core gapps
Click to expand...
Click to collapse
WORK IN PROGRESS ALL MAINTAINERS COLLABORATE IN GIVING CREDITS
Click to expand...
Click to collapse
Android Open Source Project
CodeKill13
Ubuntu
Linux Mint
Github
Flar
Peter Poelman
itsme
Stericson
JesusFreke
CyanogenMOD
AOKP
PacROM
Rootbox
Evervolv
ParanoidAndroid
slimroms
Team-Hydra -Device Trees-Kernel
Team Horizon
The mikmik
AndroidSpin
Android Police
VanirAOSP
CodefireXexperiment
albinoman887
TheMuppets
Htc
Samsung
TheBr0ken
snuzzo
T-Macgnolia
ljjehl
Saif Kotwal
pr0xy man1Ac
Djwuh
ammikam
!I am not responsible for anything that happens to you or your device as a result of flashing this rom. If you decide to install this rom then you've taken responsibility for any risks involved !!
reserrrrved
Nice to see another 4.3.1 rom for our sensation
Keep the good work, will flash it tommorow
Sent from my HTC Sensation using XDA Premium 4 mobile app
Looks good shall test in the morning , thanks
Sent from my HTCSensation using Tapatalk
Tried it already from DK's thread on other forum.
There are issues with languages, not everything is translated to russian for instance.
Also there are plenty of CM ringtones, why is that?
WiFi hotspot is not working, cannot even detect an access point.
Launcher has weird wallpaper alingment, that doesn't fit at very left or right...
All these are minor issues to polish in the future.
Oh, why there's a theme engine, is it a part of AOSP now or a bonus from CM?
I'm glad see another pure (or maybe not so much) AOSP ROM.
Since there's no new SuperXE ROMs we welcome the new effort with a big smile on our never well shaved faces.
Noobel said:
Tried it already from DK's thread on other forum.
There are issues with languages, not everything is translated to russian for instance.
Also there are plenty of CM ringtones, why is that?
WiFi hotspot is not working, cannot even detect an access point.
Launcher has weird wallpaper alingment, that doesn't fit at very left or right...
All these are minor issues to polish in the future.
Oh, why there's a theme engine, is it a part of AOSP now or a bonus from CM?
I'm glad see another pure (or maybe not so much) AOSP ROM.
Since there's no new SuperXE ROMs we welcome the new effort with a big smile on our never well shaved faces.
Click to expand...
Click to collapse
hahahah..I agree with this " our never well shaved faces".. New ROM to play with....Good job
Nice to see it's playing again. Don't let our Senny dead.
oooo another AOSP for my Sensation! Bring it on! Thank you!!
---------- Post added at 04:35 AM ---------- Previous post was at 04:34 AM ----------
Any listing of what is working and what is not?
Good work, i'll try it
anyone got any feedback on this one?
Sage said:
anyone got any feedback on this one?
Click to expand...
Click to collapse
Yes, +1, feedback is important for the rom cooker
Is this really pure AOSP without any mods?
I mean "stock" android 4.3.1 ?
Just for the record that I am not running this rom anymore and the bugs I noticed and know of are:
Quit hours not working
Clock Widget settings gives a FC
Setting the navigation bar in Insomnia setting will FC the system UI and can't be recovered and need a factory reset
Browser and the Mail-App have a screen glitches.
I saw this InsomniaAOSP purity test!

Multiple Suggestions

First of all I want to applaud the integrity of the team working on OmniRom and for standing for software freedom. As the only GPL ROM on the phone, I believe it will reach a certain prominence once critical mass of functionality is achieved. I have some suggestions that I was hoping to get feedback for from the Devs here.
1- What is the possibility for devising an in-place upgrade system that works across future OS version upgrades for major changes in AOSP? (something akin the upgrade systems of current GNU/Linux systems)
2- Incorporating apps from the guardianproject (.info) a privacy and security oriented group that make secure messaging apps and TOR for Android. That will be our anwser to the so called secure chat of CM.
3- Cooperation with the largest FOSS software repo F-Droid and perhaps including it as a default app repo option for OmniRom.
4- Now this is a big one, but as a distro that prizes Software Freedom and the GPL above all else you are in a unique position to be a demo showcase for incorporating the major app frameworks being ported to Android like Qt and Gnome. Arranging with the devs from KDE and Gnome to make this a reality would be a major milestone for the FOSS movement's efforts to bring free software in an environment that is being increasingly closed off like what Google is doing with their absorption of features in proprietary apps and the treachery of the CM turncloaks.
Casual observer here. I don't think it's accurate to call it a GPL ROM given how many non-free drivers are required to get working WiFi and so on. OmniROM encourages GPL as a way of keeping the community honest but I don't think it's set in stone.
1. upgrades on Android don't happen in same way as GNu/Linux: it's always a fresh install. CM already does this, or you can use recovery mode.
2. good idea! more generally, system wide proxy settings which would allow all traffic to go through Tor. Tor is one part of remaining anonymous, the browser needs to be locked down for example. Guardian Project say that their companion browser, Or web, doesn't work on Android 4.4, and they might stop developing it. There are other Android techniques for anonymity e.g. xprivacy.
3. F-Droid builds and signs apps, it's hard to see room for cooperation. It will soon have ability to install apps silently if part of a ROM. They dropped their Android.mk; looks like time to bring it back, maybe with package name change option.
4. Qt was announced on day one at the BBQ!

[Q] Google is moving AOSP default apps to closed-source Google's one on Nexus

Hi everyone,
I always thought that Nexus devices comes with a pure AOSP version with some little closed-source extras, like GApps (Google Mobile Services, Play Store, Gmail, YouTube, Maps...) or hardware drivers. And for a "librist" like me, it seems fine : OS and main userspace parts are opensourced, and Google services are closed-source. All was fine in my beautiful world.
But with some search, I discovered that every time that Google push an AOSP apps on the Play Store, it is actually a closed-clone of the AOSP one.
For example :
AOSP Keyboard is not Google Keyboard (=missing gesture)
Camera is not Google Camera (=missing Photosphere)
Launcher is not "Google Experience Launcher (GEL)" (=missing Google Now Integration, normal, but also transparency)
Music is not Play Music
Search is not Google Now
recently : Email (not Gmail)
etc.
I was not worried about "additionnal closed source services/app of Google in Android" as they are what they are : additionnal.
But the new politic of Google seems to be "we have our Touchwizz/Sense of our own, now".
The main problem is : as far as I can see on the GIT source and with Android Emulator, when Google begins to develop his "alternative closed source apps of an AOSP opensource apps", the AOSP apps seems to be abandonware.
You can compare the look of Google Search (and disable Google Now, to compare properly without Google closed services) and AOSP Search. AOSP Search seems to be from FroYo design... The same with Music player.
What's your point of this situation? Does Google try to make his own front-end interface to AOSP Android like Samsung Touchwiz or HTC Sense?
What devices comes with AOSP by default and not "Android by Google" now, if Nexus is no more the case?
BONUS : Jean-Baptiste Queru, head of AOSP, resigns from Google. I don't know what happens to replace him...
Note : I am French so, if my English is not easily-readable, please forgive me .
*bump*
Here is a point of view of an official Android developers from Google (source : arstechnica[DOT]com/information-technology/2014/02/neither-microsoft-nokia-nor-anyone-else-should-fork-android-its-unforkable/?comments=1&post=26199423)
There is a good discussion to be had about Microsoft using Android, and a lot of good reasons for them to not do so... which makes it especially unfortunate that instead this was turned into yet another article here of increasingly specious and misleading claims about the "open-sourceness" of Android and Google's hidden plan to Control Android And Then The World.
First, let's make a clear statement. If Android was to be in the same position as Windows is in the PC industry, we'd have a radically more open computing environment, where it is a lot easier for small players to compete against the dominant platform on a more level playing field. I don't think anyone can argue against this. When we were designing and implementing Android at Google, this was actually one of our goals -- to create a more level playing field for everyone -- and that design perspective hasn't significantly changed over the years.
So let’s start with the setup:
Quote:
Google has worked to make Android functionally unforkable, with no practical way to simultaneously fork the platform and take advantage of its related strengths: abundant developers, and abundant applications.
Already we see the clear bias that the article is going to take. There is however another way to state this: Google provides a lot of value on top of Android, with an ecosystem that is difficult to compete with, of cloud-based applications and services that are useful to users and developers. This is at least as true a way to describe as the quoted statement from the article, and I will argue it more accurately states the situation.
The arguments start out soft, but still misleading:
Quote:
The first is the Android Open Source Platform (AOSP) codebase. This provides the basic bones of a smartphone operating system: it includes Android's version of the Linux kernel, the Dalvik virtual machine, and portions of the basic user interface (settings app, notification panel, lock screen).
AOSP is far more than the basic bones of a smartphone operating system. It is a complete smartphone operating system. The examples you provide for what it includes are very misleading -- what about the launcher, contacts app, dialer and phone app, calendar app, camera and gallery and on? The fact is, if you build AOSP today and put it on a phone, you will have a pretty fully functioning platform.
The thing you don’t have is stuff related to cloud services, and this is not an evil secret plan of Google, but a simple fact we have been clear about from the initial design of the platform: Android as an open-source platform simply can’t provide any cloud services, because those don’t run on the device where the platform code runs. This is a key point that seems to be completely missed. If you want to understand what Android is, how it is designed, and how the pieces fit together, you must understand this point.
One of the things that is interesting about platforms today vs. the traditional desktop is that these cloud services are becoming increasingly central to the core platform experience. This presents a special challenge to an open-source platform, which can’t really provide such cloud services as part of the standard platform implementation. In Android our solution to this is to design the platform so that cloud services can plug-in and integrated with it in various ways. These may be stand-alone apps like Google Play Music, they may be plug-in services like the calendar and contacts sync providers, they may be Google proprietary APIs on top of the platform like Google Play services.
Note, however, that in all of these cases the platform has been designed to provide an open, flexible, and rich enough API that these Google services can be delivered using the same standard SDK that other app developers use. This is part of the goal of creating a more level playing field for everyone. (There are some exception where things are very difficult to safely expose to developers, but they are rare -- the Play Store’s privileges for managing your apps is one, and even there we do provide in the platform side-loading APIs so that other app stores can be implemented.)
So, GMS is Google’s proprietary code implemented on top of Android for interacting with Google’s services. There is nothing nefarious about it being proprietary -- it is interacting with Google’s proprietary back-end services, so of course it is proprietary.
Thus this makes perfect sense:
Quote:
The split between AOSP and GMS is not constant, either. Google has slowly been migrating more and more functionality to GMS. For example, in the latest Nexus 5, the core phone user interface—the thing that you use to launch apps and show icons—has been rolled into the GMS Search app.
What has happened here? Google now has their own launcher that integrates with Google’s back-end services. And what is wrong with this? Why is this worse than Facebook or Yahoo doing their own proprietary launcher? It is bizarre to complain about this, especially when Google has open-sourced everything else in their launcher except the parts that are specific to their proprietary services!
And this is the same thing:
Quote:
Similarly, APIs have made the move. AOSP contains a location API, but GMS contains a newer, better one, with additional features. Google encourages developers to use the GMS API, and the AOSP Location API mostly dates back to Android 1.0, and hasn't seen any substantial changes since Android 1.5.
First, it s very misleading to act like the platform’s location manager has been unmaintained since Android 1.5. Important features like passive providers and criteria-based updates were added much later than that; but, even ignoring verifiable facts, the Google Play services location APIs didn’t appear until last year, so what you are actually implying with this is that Google basically didn’t do any significant improvements to location from 2009 to 2013. Probably not true.
The reason for the introduction of Google’s location API, however, is again because of back-end services. Location has become increasingly dependent on cloud services: for a while now network-based location, but increasingly more things. We went for a long time with parts of the platform’s LocationManager basically not implemented because it couldn’t be, with the need for some proprietary thing to be dropped in on top of it to have a fully functioning API. As time went on this became an increasingly bad situation because we don’t want our platform to be defining APIs that it can’t also provide an implementation of, to serve as the basis for everyone to share and a reference for how it should work. So, the decision was made that Google should take responsibility of further evolution of that API since that evolution is increasingly tied to cloud services.
Quote:
Each new release increases the level of integration with Google's own services, and Google is moving more and more new functionality to GMS, leaving AOSP a barebones husk.
This is such an exaggeration that it is really hard to know how to address. AOSP is a barebones husk? Please. AOSP is far richer and more powerful today than it was in 1.0, 1.5, 2.0, or 3.0. And most importantly, one of the things we have been doing over the years is providing increasingly rich facilities for any cloud services provider to plug in to the platform. For example, in the most recent 4.4 release we have our very extensive new storage framework API, which Google uses to provide their Google Drive services to any application, and allows any other cloud storage provider to do the same thing, operating on equal footing with Google.
Quote:
That's not a small category, either, since features such as in-app purchasing are in GMS.
This gets emphasized as a significant point, but, honestly, how would you propose that in-app purchasing not go through GMS? Some general platform API to allow the app to do an in-app purchase with whoever wants to be a “purchase provider?” I can’t imagine this being a solution that people will be happy with.
Quote:
Technically, however, a company with sufficient development resources could provide its own GMS replacement. The overhead would be not insignificant, especially as—to ensure optimal compatibility—the replacement would have to replicate not just correct functioning, but any bugs or quirks of the GMS implementation.
Of course, the vast vast vast majority of the work here is implementing the back-end services in the cloud, not the proprietary glue code that runs on the device. Failing to address this is deeply missing about what is going on.
Quote:
There are also lots of little awkward aspects of the GMS API; it includes such capabilities as "share with Google+" which few companies have any real counterpart to.
In other words you don’t have your own social network, so you can’t implement Google’s API for sharing to its social network? Okay, then just have the API do nothing? Or heck, share to Facebook?
Quote:
Another example: there is an API for handling turn-based multiplayer gaming. A company could implement this API and have its own server infrastructure for managing the gaming sessions, but obviously these gaming sessions would be completely separate from Google's gaming sessions, fragmenting the player base in a way that game developers are unlikely to be keen on.
Now this could be taken as just a good argument for why Microsoft wouldn’t get as much of a competitive advantage by using AOSP, since they would still be competing with Google’s cloud services. But then it is immediately followed by:
Quote:
As an added bonus, should the ultimate resolution of Google's long-running legal battle with Oracle be that APIs are, in fact, copyrightable, this kind of wholesale reimplementation of GMS would become legally actionable. Google could, if it chose to, shut it down through the courts.
Where in the world did this come from? Google is the one fighting against that. Microsoft actually filed an amicus brief supporting Oracle. Yet you write this almost as if this case would serve part of Google’s evil plan to control Android?
Quote:
The second option—AOSP with a few extra custom extras—has the upside of providing an opportunity for Microsoft to integrate its own services… It would certainly mean omitting any high-profile title using in-app purchasing, so, say, Plants vs. Zombies 2 or the latest iteration of Angry Birds would be out.
It’s strange to focus on in-app purchasing here. The issue is that you don’t have the Google Play store, so you need to get app developers to publish their apps on your own store. In fact providing a compatible in-app purchasing API and otherwise making it easy for them to publish their app without changing it is probably the lesser problem.
Quote:
Google has pushed very significant pieces of functionality into GMS, including messaging and the Chrome browser. The AOSP counterparts are buggy, feature deprived, and by at least some accounts, barely maintained. If a company wants to use AOSP without GMS, it has a lot of work to do if it wants to produce a high quality experience. The open source parts just aren't good enough.
Again the exaggerations. Chrome is available open-source as Chromium (of course without the integration with Google’s back-end services, but why in the world would Microsoft want those?). What parts of AOSP are “buggy” compared to Google’s stuff? In fact a lot of Google’s proprietary apps are built on top of the corresponding AOSP app -- that includes Google’s Launcher, Calendar, Email, and even Gmail now. Messaging has diverged from Hangouts, but Hangouts is deeply integrated into Google services, and there is a similar situation with Music. It would be nice if some of these apps were better maintained, but (a) there are lots of equivalent apps (often based off the AOSP version) that people have written which you could license and use, and (b) implementing these apps is pretty small potatoes compared to all the cloud services Google provides.
Quote:
For Microsoft, the effort required to build a GMS workalike on top of AOSP is going to be comparable to the effort required to build the Windows Phone shell and APIs on top of Windows.
Again, the vast majority of work here is providing the back-end cloud services. Not, as keeps being implied, the proprietary bits that Google has running on Android.
Quote:
Moreover, it still implicitly gives Google control over the platform. Various aspects of how Android is used are determined by the underlying APIs: sharing between applications, for example, is done in a particular Android way. Any platform using Android in this way would have only a limited ability to take the platform in a different direction from the one Google chose.
Okay this is just weird. Yes, the Android platform has a well-defined sharing facility, and if you want to have an Android-compatible platform you will want it to work the same way. Just like, I don’t know, Ubuntu has a C library and you probably don’t want to change that. How in the world is this different from every other open-source platform in the world? How is Google being all controlling here?
Quote:
The fourth option—use AOSP with an entirely new software stack on top—gives freedom and flexibility, but to what end? The kernel isn't the important bit.
Wait, what? The only way I can figure out how to interpret this is to suggest that they use Linux (the kernel) but nothing above it. That can’t be what you mean, right? I honestly have no idea what this is supposed to be saying, except that it again seems to be implying Google is being all nefarious.
Quote:
If Android were an open platform in the way that Firefox OS or Ubuntu for smartphones were an open platform, the forking suggestion would make more sense.
I’ll admit I am not super-familiar with these two, so I have a question: what are the things that they have that are not in AOSP?
And finally we have further blanket statements about how Google’s goal is to make Android increasingly closed, AOSP isn’t real open source, etc, etc. I’ll just leave with the final sentence:
Quote:
Suggestions that Microsoft scrap its own operating system in favor of such a fork simply betray a lack of understanding of the way Google has built the Android platform.
Actually, I don’t think you have an understanding of how Google has built Android. I have been actively involved in designing and implementing Android since early on, and it was very much designed to be an open-source platform. Part of that design was to allow Google (or anyone) to build integrated cloud-based services on top of it, and that aspect of Android design has gotten richer as the years go on. What you are concerned about is not a design problem in Android, but the richness of Google’s cloud-based services.
At least Android creates a much more equal playing field for others to compete with Google’s services than is provided by the proprietary platforms it is competing with. I also think a good argument can be made that Android’s strategy for addressing today’s need to integrate cloud services into the base platform is an entirely appropriate model for a “real” open-source platform to take.
Click to expand...
Click to collapse

Categories

Resources