I believe Chromium also excludes Google's software update functionality.

Slightly off-topic, but am I the only one that thinks the word "cyber" is a silly 90's throwback?

Okay, so TimSort.rangeCheck() was allegedly copied from java.util.Arrays.

Aside from the obviousness issues, this fact would make it slightly more sensible to use rangeCheck() for a copyright infringement case, except for the fact that java.util.Arrays was provided by Sun under the GPL v2. The GPL was written to encourage copying and modification.

The worst I could say about Google allegedly copying this code is that they re-licensed the GPL rangeCheck() method to Apache 2.0, which you can't really do; the combination of GPL code and non-GPL code would be a GPL end product. Regardless, I still don't see a billion dollar damage claim.

Wow, you're right, that's completely insane. Look at the revision history of TimSort.

How can Oracle claim copyright damages on a file in Java's source code that is Copyrighted in 2009 by Google?
Why hasn't Google tried to nullify the copyright claim on this file on the grounds they they wrote the code and that they themselves own the copyright?
Why would Oracle make an issue of this file if the case for infringement is so weak?

None of this makes any sense to me whatsoever. I feel like I'm missing something; Oracle can't be this outrageous and Google's lawyers can't be this dumb. Can someone clarify?

What's amusing is that the 9 lines in question don't even implement the algorithm; they perform a quick sanity check before the real computation starts. Is this really the best they have? Couldn't they have found more creative lines of code to be infringing on a copyright?

Anyway I've been looking some stuff up. TimSort was originally written into Python by Tim Peters in 2002 (BSD-style license). If I'm not mistaken, that would mean that Sun wrote a trivial check as part their own re-implementation of someone else's work, and are claiming massive copyright damages on it. If Oracle wins that, that's one hell of a precedent.

I presume the 9 lines in question refer to TimSort.rangeCheck().

Have you ever looked at it? If I had to implement that method, I probably would have done it the exact same way.

Maybe it's not a right, but it's what AT&T agreed to sell these people.

Unlimited, def:
1. not limited; unrestricted; unconfined: unlimited trade.
2. boundless; infinite; vast: the unlimited skies.
3. without any qualification or exception; unconditional.

If it has a limit, tier, cap, or threshold, it's not unlimited. Unlimited is not newspeak for limited.

It's not a real fork. It's more like regular Android with a Amazon's home screen app and their other apps\services pre-installed. Same open OS, same API, just with some closed source apps facing the user.

If they went around changing the API and the OS behavior, breaking compatibility, then we'd be in fork territory. I don't see a good reason for them to do that; it's in their best interests to be compatible with existing and future Android apps. If they wanted to make such a fork they would have.

Well, if it's an Android tablet you could just create an app that acts as a replacement home screen. Just implement the appropriate intent and display a browser control to the user.

It's also a really thin book. Burn.

This is the link he meant to post.

If a developer decides to require Android 4.0 when all they really needed was 1.6, they're doing it wrong and it's their own fault that their market share suffers.

For apps where this would matter for performance, Android has an NDK for writing C\C++ that compiles to native code instead of Java (Dalvik) bytecode. It's usually used for games and heavy data processing but it's overkill for typical small apps that don't do much heavy lifting. You can mix and match Java and NDK code where needed, so a developer might code the processor intensive stuff in C\C++ while coding the rest in regular easy to use Java.

That all makes sense, but in this context platforms matter much more than the actual devices running them. That is because developers are writing apps for the platforms, not for the devices themselves. I'd agree your frame if apps had to be re-written for each and every Android device. But that's not the situation we're living with; developers are writing apps that run on Android devices that they might not have even heard of, and it typically "just works".

This is a myth. Android releases have always been backwards compatible. That is, Apps written for Android 1.0 will work just fine in Android 1.1 and any later release in the future. If you're writing an app that requires, say, Android 2.1, such as a Live Wallpaper, then any Android running version 2.1 and higher will work fine. Devices that don't meet the requirement simply won't see the app in the Market.

If appropriate, developers can mark that support as optional, so your app will include that feature if the device supports it, and if it doesn't the feature will be disabled and the rest of the app will work regardless.