4 ms·

Google modifies Android SDK [terms] to battle fragmentation

50 points by fpgeek 14y ago

adaml_623 14y ago
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 14y ago
  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 14y ago
    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.
- Someone 14y ago
  "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." I think Google would not be happy with that, either, but there is little they can do about that (they probably can forbid you the use of the Android name, but AFAIK, that's it). Luckily for Google, that also is much more work than extending the existing API with proprietary extensions. So, they do the best they can: make it as hard as possible to create an SDK for a slightly (or less slightly) incompatible API.
- msh 14y ago
  And People complain about unclear licenses from apple! This is just as unclear.
  - Zigurd 14y ago
    It is unclear relative to both the text, and Google's intent in choosing the Apache license, which is a "liberal" open source license in the sense that it is nonrestrictive. You can fork, keep your source code unpublished, etc. Google choose the Apache license to give their OEM and carrier partners as much freedom of action as possible, while making Android an open source system.
andyjohnson0 14y ago
...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"?
throwaway64 14y ago
this ends android as an open source project frankly, open source means freedom to fork, end of story.
- CookWithMe 14y ago
  No, but it's complicated. You can fork the android source which is under the Apache 2 license: http://source.android.com/source/licenses.html http://source.android.com/source/licenses.html If you want to use the Android SDK (this includes additionally Google APIs), you have to agree to this license: http://developer.android.com/sdk/terms.html http://developer.android.com/sdk/terms.html This is also needed to release your App in the Play store. Someone has argued source.android.com should be given a different name, similar to chromium and chrome. I think that would clear things up, too.
- esolyt 14y ago
  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 14y ago
    A fork means that you offer an incompatible SDK. What Amazon does is not forking the SDK, but using it.
esolyt 14y ago
This isn't really about the kind of fragmentation most people are talking about.
- rbanffy 14y ago
  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 14y ago
    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.
capo 14y ago
It's about this sort of fragmentation (vendor incompatibility): http://officialandroid.blogspot.com/2012/09/the-benefits-importance-of-compatibility.html http://officialandroid.blogspot.com/2012/09/the-benefits-imp...
- jre 14y ago
  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.
pumpernickel 14y ago
"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?
needle0 14y ago
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.
zedwill 14y ago
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-android-of-china-7000003937/ http://www.zdnet.com/cn/alibabas-aliyun-os-hopes-to-be-andro... http://news.cnet.com/8301-1035_3-57513559-94/google-alibabas-os-is-an-incompatible-version-of-android/ http://news.cnet.com/8301-1035_3-57513559-94/google-alibabas... Just my two cents
sauravc 14y ago
This is a step in the right direction.
Zigurd 14y ago
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.

50 points by fpgeek 14y ago

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 14y ago
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 14y ago
  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.
Someone 14y ago
"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." I think Google would not be happy with that, either, but there is little they can do about that (they probably can forbid you the use of the Android name, but AFAIK, that's it). Luckily for Google, that also is much more work than extending the existing API with proprietary extensions. So, they do the best they can: make it as hard as possible to create an SDK for a slightly (or less slightly) incompatible API.
msh 14y ago
And People complain about unclear licenses from apple! This is just as unclear.
- Zigurd 14y ago
  It is unclear relative to both the text, and Google's intent in choosing the Apache license, which is a "liberal" open source license in the sense that it is nonrestrictive. You can fork, keep your source code unpublished, etc. Google choose the Apache license to give their OEM and carrier partners as much freedom of action as possible, while making Android an open source system.

andyjohnson0 14y ago

...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"?

throwaway64 14y ago

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

CookWithMe 14y ago
No, but it's complicated. You can fork the android source which is under the Apache 2 license: http://source.android.com/source/licenses.html http://source.android.com/source/licenses.html If you want to use the Android SDK (this includes additionally Google APIs), you have to agree to this license: http://developer.android.com/sdk/terms.html http://developer.android.com/sdk/terms.html This is also needed to release your App in the Play store. Someone has argued source.android.com should be given a different name, similar to chromium and chrome. I think that would clear things up, too.
esolyt 14y ago
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 14y ago
  A fork means that you offer an incompatible SDK. What Amazon does is not forking the SDK, but using it.

esolyt 14y ago

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

rbanffy 14y ago
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 14y ago
  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.

capo 14y ago

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

jre 14y ago
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.

pumpernickel 14y ago

"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?

needle0 14y ago

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.

zedwill 14y ago

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-android-of-china-7000003937/ http://www.zdnet.com/cn/alibabas-aliyun-os-hopes-to-be-andro... http://news.cnet.com/8301-1035_3-57513559-94/google-alibabas-os-is-an-incompatible-version-of-android/ http://news.cnet.com/8301-1035_3-57513559-94/google-alibabas... Just my two cents

sauravc 14y ago

This is a step in the right direction.

Zigurd 14y ago

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.