Android's "Non-Fragmentation Agreement"

superglaze writes "The biggest doubt cast over Android (whose SDK was released yesterday) has been the fact that much of it is licensed under Apache. There have been worries that manufacturers might fork the code road in a non-interoperable kind of way. I.e., they would have no obligation to feed back code to the wider Open Handset Alliance, or even tell the other members what alterations have been made. However, it turns out that Google made all the members sign a 'non-fragmentation agreement' to make sure everything works with everything. In theory at least. 'All of the partners have signed a non-fragmentation agreement saying they won't modify [the code] in non-compatible ways ... That is not to say that a company that is not part of the OHA could not do so.' Google's spokesperson highlighted the historical dangers of working with Java, the programming language that lies at the heart of Android. 'One of the current problems with mobile Java development is that Java has fragmented ... Java virtual machines have fragmented, but all the members of the OHA have agreed to use one virtual machine that can run script in Java'"

Re:Oh, FORK!!!

[ajs]

Sounds to me like they don't want anyone forking it.

Read it again. The members can't fork the development. Non-members can. They're just trying to prevent the situation where, 5 years down the line, NTT says "thanks for all the hard work Google, but now that we've achieved brand loyalty, we're going to stop working on our competitor's OS." The idea is to make the cell phone OS a commodity and let cell phone makers focus on higher level features that will work on any phone.

Re:Pretty cool start

[FinestLittleSpace]

You have a valid point, however Google /have/ been running Android on mobile handsets. You can see videos of them in action on the main site.

Re:GPL solves these problems

[domatic]

What? The GPL does NOT prohibit forking. There are dynamics associated with it that tend to discourage forking but it certainly is not prohibited.

Re:Java is simple to decompile

[AKAImBatman]

it would be incredibly easy to decompile the bytecode back to Java source.

#1 Who cares? Only young'uns with little experience with how the industry works actually care about someone "stealing" their (incredibly boilerplate, easy to duplicate, hard to integrate into my own project) source code. Did you know that it's easy to "decompile" your HTML, Javascript, Actionscript, PERL, Python, Ruby, Shell scripts, and even Assembler too?

Oh noes! Do not want!

#2 The "Java" that runs on the phone isn't Java at all. Java is used as a development language, and is actually compiled down to Google's Dalvik VM instead. Thus while it will still be decompilable (there's no such thing as code that can't be decompiled) it might be made more difficult by the non-standard bytecode.

Re:Revisionism?

[Anonymous Coward]

but J2ME phones all run the same code and the same APIs. Issues between phones almost always come down to working around JVM implementation bugs

This is just plain wrong. Once you start looking at graphics, audio, keyboard input, bluetooth, gps, network, photo or video capture or anything beyond very basic apps, you reach the murky world of JSRs, which are bits of java that may or may not be included in a particular j2me installation. If they are included, many of them have lots left up to the implementation to decide, for example MMAPI leaves it up to the implementation whether to support MIDI sound, whether to support playing audio directly from code rather than from a file, whether to support recording, what file formats to support etc. You can't even reliably play audio files across platforms, let alone do interesting things like get at the camera, get video frames etc.

Nokia phones for example, most will let you grab a single frame from the camera, some won't, but you can't grab multiple video frames without a 1/4 second delay per frame, whereas motorola phones, many will not let you at the camera at all, but those that will, will let you record multiple frames properly, except for a few which will only let you take single frames.

Re:Google versus Apache

[Danny Rathjens]

But it seems like they're going to be way more open than anyone else, and possibly as open as they can be while still getting FCC approval for the device.

How can you possibly say that when http://openmoko.org/ [openmoko.org] exists?
And I don't think openmoko had any problems with FCC approval and are truly open. "free software" is not all that relevant the type of "locked-down chunks" you are talking about - like 911 location service - since they are "locked down" in the hardware chips (by simply not having certain things controllable via serial interface) and not by any software.