Slashdot Mirror
Google's Android Cellphone SDK Released
AchiIIe writes "The android SDK has been released to the wild. As expected it features the Linux Kernel, low level libraries such as FreeType, OpenGL, SQL Lite, WebKit (as a web browser), a custom Java Bytecode interpreter that is highly specialized for the CPU. A common java API is provided. A video has been posted with an the overview of the API." SM: Several readers have also written to mention the Android Developer Challenge offering $10 million in prizes for cool mobile apps.
What hardware platform does it run on?
"a custom Java Bytecode interpreter that is highly specialized for the CPU" - Kind of hard to do that in an emulator on a PC. What CPU is this optimized for? (Guessing ARM... Still, to evaluate performance you need real hardware.)
retrorocket.o not found, launch anyway?
I'm assuming (need to confirm) that Android is primarily developed using native ARM code, it just happens to include a Java VM for all those legacy MIDlets running around out there.
It would be suicide (see Palm as an example) for Google to make developing using native code difficult. (For those not in the know, even though PalmOS has run on ARM CPUs for years, normal apps are still emulated m68k code, with the option of "ARMlets" to allow snippets of native code on PalmOS 5. Writing an ARMlet is an UNHOLY NIGHTMARE. I attempted to speed up a program by replacing some code with native ARM code and gave up.)
retrorocket.o not found, launch anyway?
Can someone tell me how Google will make money off this open source platform? Individual phone companies will create their own apps and port them to the phones. How will Google cash in? May be via ads but suppose the phone companies refuse.
Holy crap, they bundled WebKit? I somehow missed that in all the hoopla.
That means that the gPhone web browser has the same rendering engine as the iPhone web browser, the one that's shared by Safari (and OmniWeb) on the desktop. It's going to get less and less safe for web developers to ignore that rendering engine...
You know who you are, the ones that said Ballmer had a point last week when he called Android a press-release. Well, here is the SDK, as promised. On time.
So will all those slashdotter who doubted eat crow now? Or will the MS fanboys just pretend this never happened, or now move on to, "all google has is a press-release, and a sdk, and an alliance".
Come on, we need some amusement here. Spin this one!
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
To me the most interesting aspect of the announcement was the inclusion of WebKit as the HTML rendering solution. This is a huge boon for the WebKit project, and should make many of the new iPhone web apps compatible with the new system. I'm not an expert on this, but isn't any one else surprised by the decision? Isn't Google traditionally associated with the Mozilla engine? By going with the WebKit, developers now have a target browser for Windows, Mac, the iPhone, Nokia, and now gPhone. (and there seem to be several linux projects building on it). Not to mention that the KDE group is now working to merge back in with WebKit. Sounds like a pretty strong platform for me. And an open standard that will benefit a great deal from the powerful groups working with it.
Be kind, for everyone you meet is fighting a difficult battle. - Plato
Some responses to your points:
(1) It's Java.
Java is the entrenched standard for mobile development. Google isn't pushing Java here, they're trying to maximize their reach to existing mobile developers.
(2) It's eclipse-centric.
As mentioned on their site, Google's developers use a mix of Eclipse, IntelliJ, and NetBeans for development, which is pretty much the standard in Java development. They've probably released an Eclipse plugin first because it had the broadest reach and perhaps it was the easiest environment to create a plugin for. I doubt this means that Google is pushing Eclipse, however, I would expect tutorials and documentation (if not additional plugins) to be released for the other environments soon enough.
(3) Code layout.
Code layout in package directories is pretty much a Java thing, again pretty standard.
(4) I have an iPhone.
iPhone is a single phone. Android will support a whole platform of upcoming phones. This is a big enough difference to be interested in the Android SDK at the very least, if not both. Plus, you can check out the Android SDK now while you'll have to wait until February for teh iPhone SDK.
(5) It appears to come with an emulator, which is very cool!
Yeah, it is very cool! This is also pretty standard for wireless toolkits (WTK), since development on the devices themselves is usually difficult and time-consuming. My company's suite of game development tools includes a similar universal emulator, which I love using. It's pretty much a must for mobile development.
I'm also looking very forward to playing around with the SDK. Hope some great things can come from these developments in the mobile world.
-Will
This is looking decidedly un-exciting so far. It looks like an API to make more of the exact same kind of garbage that has been produced by phone makers so far.
What phones desperately need is much, much better interface design. That's not solved by a new OS, and it's certainly not solved by one whose emulator has eleven funcion keys above the keypad.
Apple is breaking new ground, but this seems planted squarely in the past.
I could be wrong, I hope I am wrong, but I don't see it yet.
The documentation isn't quite clear, but it looks like I was wrong and unfortunately Android apps are indeed intended to be written in Java. (as opposed to, say, something like a C/C++ toolkit with bindings for other languages, such as TrollTech's mobile Qt variant.)
I just lost a lot of interest in Android, if it pigeonholes developers into a single language and makes compiling native code with an efficient language difficult. Java utterly failed in the "Write once, run everywhere" arena, and it's an ugly horse-designed-by-committe language that universally leads to bloat. (See, for example, the memory usage and UI responsiveness of uTorrent when compared with Azureus.) There's a big focus on mobile devices towards multimedia applications (video, audio), and smooth video playback on a phone takes even natively compiled code to its limits.
retrorocket.o not found, launch anyway?
Personally I'd prefer webkit to support Canvas3D and to have a fast ES4 implementation. Google are not using Suns hotspot VM so I think typed ES4 on a fast VM would be competitive (and run in standard web browser)!
I see this release as a hurried and premature foot in the door; an uncomfortable mishmash.
Not to be the rationalist when you're clearly poking fun of Mr Nervous (Ballmer), but at the time he said that (in a press conference last Thursday in Tokyo) he was right - there really wasn't much info out there, and a lot of the speculation was wrong. Today was the first release of any hard info and SDK, but they still haven't released any performance numbers and it still doesn't run on any existing handset (at least publicly).
Google does have a strong corporate backing, however, including companies that are currently customers of Microsoft and Symbian, so from their standpoint, they need to bash it and promote their own solutions. Expect a lot more to come.
Hoo boy. We get to get into this argument again.
If these languages are interpreted, then I might see your 10-30% slowdown. But these days, they're compiled at run-time, and programmers will find that they can run as fast or faster than C/C++, often just for the fact that they use garbage collectors (because GC allocations tend to be faster than C allocations).
Note that I say "can," and not "will," because it all depends on what the program does and how well it uses the features of its language. If you're doing purely mathematical stuff, for example, I don't see any reason Java or C# should run any slower than C.