
Google modifies Android SDK [terms] to battle fragmentation - fpgeek
http://news.cnet.com/8301-1023_3-57550824-93/google-modifies-android-sdk-to-battle-platform-fragmentation/
======
adaml_623
_3.4 You agree that you will not take any actions that may cause or result in
the fragmentation of Android, including but not limited to distributing,
participating in the creation of, or promoting in any way a software
development kit derived from the SDK._

I don't actually know what _fragmentation of Android_ means. I'm unsure that a
court would know it either. Theoretically a new SDK derived from the Google
SDK would actually be less of a fragmentation than an SDK for Android that was
engineered totally from new.

Google really don't take open development seriously sometimes.

~~~
CookWithMe
I don't really get it either. I'm not even sure how I, as a developer, can do
anything to create fragmentation. If I use the official Android API, than my
app (or SDK) should be forward-compatible.

If my app or SDK uses undocumented APIs, then it may not work in newer
versions - but I'm not supposed to do that anyway. Maybe this is just a fancy
way of saying "use only the documented API, because we guarantee it is
stable".

Maybe carriers / handheld makers really just copied the source of the Google
SDK, used or changed whatever they felt fit as if everything was an official
API and with the next update all their changes were broken... so deriving of
the SDK had to be addressed in a special way.

IANAL, but "participating in the creation of" ... "a software development kit
derived from the SDK" sound like it contains creating a patch for the SDK.
Very unfortunate wording, I wish they would have sticked to "don't use
undocumented APIs".

~~~
simonh
I suspect this is intended to address the case where someone creates a
platform derived from the Android OS, and then modifies the SDK to use it for
development on that platform, or for dual use to develop software for Android
and NewForkedOS.

Edit: This may be an issue for Amazon. They have forked the OS, which is fine,
but they also use the (separately licensed) SDK and now this is apparently not
OK.

------
zedwill
They have recently made a lot of noise about incompatible Android derived OS
in China.

Like the Alibaba OS Aliyun. The name election is interesting. Yun is mandarin
for cloud, which according to the news it is a main feature of this android
bastard child, saving your data to the cloud like iCloud for iOS

[http://www.zdnet.com/cn/alibabas-aliyun-os-hopes-to-be-
andro...](http://www.zdnet.com/cn/alibabas-aliyun-os-hopes-to-be-android-of-
china-7000003937/)

[http://news.cnet.com/8301-1035_3-57513559-94/google-
alibabas...](http://news.cnet.com/8301-1035_3-57513559-94/google-alibabas-os-
is-an-incompatible-version-of-android/)

Just my two cents

------
esolyt
This isn't really about the kind of fragmentation most people are talking
about.

~~~
rbanffy
Indeed. And I never felt the fragmentation people worry about is much of a
problem. We have been doing resizable interfaces since the first windowing
systems arrived.

~~~
czhiddy
Android fragmentation was never really about the resolution differences. As
stated by the various Nexus 7/10 reviews out there, many Android apps on
tablets are just badly resized phone UIs, but they're still functional. Badly
coded apps might crash at unexpected resolutions, but most decent developers
avoid those mistakes.

The fragmentation comes from the woeful OS update situation (API
fragmentation) and there being a ton of different manufacturers each producing
something slightly different (hardware fragmentation).

Older iPhones don't support all the features a 5 does (panorama, Siri, etc),
but they support the latest APIs. Want to use a ICS TextureView for fast GL
rendering to a view? 70% of the userbase won't have support.

Writing an image processing app that depends on the GL_OES_texture_float
extension on the GPU? Phones from with GPU X will have the extension, phones
with GPU Y won't. Need a gyroscope for some fancy UI widget? What about NEON
intrinsics? What about an app that relies on all three? Having so many more
combinations of hardware is a blessing and a curse, and testing against all
the possibilities is a real hassle. Every platform has hardware fragmentation
- Android just has it the worst.

------
andyjohnson0
_...distributing, participating in the creation of, or promoting in any way a
software development kit derived from the SDK._

I don't understand what Google is trying to prevent with this change. Is a
"derived" SDK one that provides an alternative api to the official SDK, or
extends it? Are there any derived SDKs in existence or being proposed?

Also, does any one have any thoughts about if/how this affects mono for
android? As far as I am aware, MFA is an api layered on top of the the SDK.
Does that count as "derived"?

------
needle0
I'm assuming they made this change to combat forks that do little more than
redirect the flow of data and money to themselves, eg. OPhone, Aliyun, Kindle
Fire. I have little respect for them.

But I'm more concerned with forks that do more than that - namely, ones that
take Android and adapts it for formfactors and usage models beyond what it was
designed for. WIMM takes Android into a wristwatch; Ouya, into a gaming
console; Vuzix M100, into wearable computing. Each of them have their own
specific SDKs and would amount to "fragmenting" Android, but for good reasons.
(Hell, Google themselves are probably creating an incompatible Android fork
with Project Glass!)

I sure hope Google doesn't mess with those folks, as IMO they are the ones
truly putting the openness of Android to good use.

------
Zigurd
The good part: Android has really good API-level compatibility across official
and AOSP-derived Android systems. Even Kindle Fire is highly compatible. These
terms appear to be aimed at maintaining that level of compatibility. Also,
these terms do not prohibit SDK extensions or plugins. So, if you have an API
you want Android developers to use, you are fine.

The bad part: The terms are vague and could readily be used for evil,
arbitrary, witch-hunts. "Fragmentation" is undefined. And Google has a history
of wielding agreements, such as the "Anti-fragmentation Agreement" some OEMs
have entered into in arbitrary inconsistent ways.

The worst part: It makes Google look paranoid, like Sun and Oracle. Android is
conquering the planet. Chill.

------
throwaway64
this ends android as an open source project frankly, open source means freedom
to fork, end of story.

~~~
esolyt
Not at all. This isn't about forking Android.

People who fork Android wouldn't really benefit from offering a separate SDK
anyway. They would want to take advantage of the existing app ecosystem and
preserve compatibility, just like Amazon is doing with Kindle Fire.

~~~
bookwormAT
A fork means that you offer an incompatible SDK. What Amazon does is not
forking the SDK, but using it.

------
pumpernickel
"history repeats itself"

like when sun was worried that googles dalvik might fragment the
installationbase vor javaME-based stuff

only that they remained quiet and let them proceed because in the end it might
result in smth. good?

------
sauravc
This is a step in the right direction.

------
capo
It's about this sort of fragmentation (vendor incompatibility):
[http://officialandroid.blogspot.com/2012/09/the-benefits-
imp...](http://officialandroid.blogspot.com/2012/09/the-benefits-importance-
of-compatibility.html)

~~~
jre
It looks like this is about the name. If you want to call your thing Android,
you have to respect the Android API (the example they give with SystemClock
makes sense).

The android source being under an Apache License, you can still fork the
project, but you'll have to change the name.

This reminds me of the Firefox/Iceweasel story.

