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?
The most common question I've heard is "What hardware is the Android platform running on?" Nobody outside of Google and possibly the Open Handset Alliance members has run it on hardware yet. If you're interested in trying to hack it, there is a board of people trying to get it on some phones: http://www.ohadev.com/forum/viewtopic.php?t=15 ------------ Cheers, Brian Jordan http://ohadev.com/ - Android SDK code samples, tutorials, discussion
a TODO list!! ;-)
Shouldn't this point to the official repository at http://code.google.com/android/ instead of http://code.google.com/p/android, which just looks like some ad-hoc mirror?
Android is fully based on Java.
Being a developer of an open source java database myself, I am absolutely thrilled.
This is the the single best possibe thing that could have happened for the success of Java on devices. This SDK will be decisive for how software will be written for the masses in the future: With Java. Don't forget: The number of mobile phone users without a PC will soon be an order of magnitude higher than the number of PC users.
db4o - open source object database for Java and
"The Android Developer Challenge is open to individuals, teams of individuals, and business entities. While we seek to make the Challenge open worldwide, we cannot open the Challenge to residents of Cuba, Iran, Syria, North Korea, Sudan, and Myanmar (Burma) because of U.S. laws. In addition, the Challenge is not open to residents of Italy or Quebec because of local restrictions."
Mama Mia! Tabernak!
Kevin Smith on Prince
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?
Real slow phones.
No. Most of the phones on the market today use Java for graphics and applications, including pretty much all of the popular cell phones in Japan that make any phones in the Western world look childish by comparison. The problem is that there is an impression among standard Windows developers that Java is necessarily slow, which is absolutely not true. Sure, the early PC JVMs, the Swing toolkit and the applet model were resource-hungry abominations, but Java on cellphones is lean, mean, and it's already pretty much everywhere.
I just downloaded the SDK, so will hopefully have some time to play around with it. It looks potentially very interesting, but here are a few quick thoughts:
.. it's on the side so it doesn't get in the way, but it's there if you want it).
.. it will be interesting to see how it compares. I really like Cocoa. It's really a great language/libraries for developing windowed systems. Interface Builder is the only GUI builder I think makes sense. I hate code generation, and I hate the weird quirks that come with many others (QT, Visual Studios, WxWidgets, GLADE++). IB just works.
(1) It's Java. Sometimes Java is the right tool for the job. Unfortunately, I've never been a big fan of the Java libraries. They always seemed overly complex and verbose to do simple things. I say this comparing it to both the STL/Boost for C++ and Cocoa. Granted, both of those libraries have their issues.
(2) It's eclipse-centric. It looks like they want you to use Eclipse. I'm sure you can do fine without using Eclipse. I'm not sure how dependent it is on creating interfaces etc. So you might do best to ignore this point. Eclipse does some things really well -- taking advantage of being a Java-based editor, it can use RTTI to help in the code-writing process.
That said, I would be very happy if I never had to use Eclipse again. The interface itself is extremely non-intuitive, gets in the way, and caused a great deal of swearing to occur. Nowadays I use either Emacs, Textmate, or XCode. XCode isn't perfect but it does a really good job of not getting in your way, and occasionally actually helping out (like the reference panel that automatically calls up info on the function your cursor is over
(3) Code layout. I'm not sure how much of it being a Java thing, or how much it is google, but the fact that I need to go 3-4 directories in just to get to the source code is very frustrating. I'm pretty sure there's better ways to do that.
(4) I have an iPhone. I'm waiting for the iPhone SDK to be released
(5) It appears to come with an emulator, which is very cool! That is a major win for fast development times.
Give all my complaints, I'm probably going to try writing an app or two for it ASAP. Code should be fun to write, which will be my major test for how good/bad the platform is. I also wonder how configurable it is. Did they come up with good conventions? If not, can you override them, or will all apps suffer the same?
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
You know, it may not take a whole lot of work to get an Android runtime up and running on the iPhone once they open up the iPhone SDK. I read through the Android dev docs, and apps are written in Java. You don't directly call native code, you just have a JVM with libraries available to it. So it may not be all that hard to get a compatible runtime into a much wider variety of devices.
That would mean that you could code for the gPhone and deploy on the iPhone (or even iPod Touch), either by loading the runtime onto the iPhone first (cf. "Cedega"), or by bundling a stripped-down runtime into the iPhone version of the app (cf. "Cider").
That'd rock. That'd rock hard. I'd become an Android developer if things work out that way.
No it hasn't. THAT'S IMPOSSIBLE! IT'S JUST VAPORWARE! IT'S JUST A PLAN ON PAPER! THERE'S NOTHING BEHIND IT, NO SPECS, NO DETAILS!
I'm 100% sure this is the case because Steve Ballmer said so. All claims to the contrary must therefore be lies.
It might be worth it for them just by making it hook in easily with Google ads and search.
Think about it this way: as mobile phones become more powerful and internet-ready, more people will be doing more of their casual online stuff on their phones. Right now, lots of smartphones are defaulting to Windows for their development. That means their web browsers will probably use Live search for their search engine. Phones will recommend Hotmail for anyone looking for webmail. It will become a good way for Microsoft to fight Google for online dominance.
So what's Google's way to fight back? Apple's keeping the iPhone software to themselves. Palm is basically a joke. RIM's stuff is pretty limited. Google has to build their own platform so that Nokia and Motorola will be using Google Search, Gmail, Google Apps, Blogger, etc. as a default.
So that's where the money is. That's where all Google's money comes from.
I belive that should be SQLite (www.SQLite.org)
http://www.intellipool.se/ - Intellipool Network Monitor
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?
Well I've been doing too much hex math, I read it as 4327 dollars.
First post from the Android emulator? Its slow as balls, btw...
SIGFAULT
They don't necessarily need to make a profit w/ Android. This whole thing might be a defensive strategy to keep the client-side web open, which is something google's real profits depend on.
-metric
Let me think about that for a sec...
.NET ES.
.NET ES is a bytecode interpreter platform for VB, C#, J#, etc.
:)
.NET and Java are pretty mixed when it comes to real world performance and memory usage. In a tiny app I wrote as an experiment in C#, I found .NET about 10% faster and 20% less memory efficient than the Java app it was based on. I've read .NET apps outperform java memory-wise in some real world conditions, as well as .NET having a problem with hitting memory bounds (and running very slow or crashing) much faster than java so as we say in the industry, YMWV. Both are generally about 10%-30% slower than C/C++, and both require memory tweaking by the programmer at times. For most mobile uses, this will be a non-issue - either is fast enough, and most apps won't put too much stress on available memory.
Windows Mobile is essentially Windows CE +
ergo, by postulate "Java means Real slow phones,"
Windows Mobile also means real slow phones.
Anyone have a problem with that?
Seriously, both
Nope. With the exception of the libraries, it's pretty much all Java, and actually, it would be insane for them to allow you to code natively. You loose all of the advantages of hardware independence which is exactly why this sort of platform exists in the first place.
PalmOS primarily ran on low power devices, and you pretty much needed to "hit the metal" if you wanted to get any sort of performance from your apps. It's something I used to do a great deal in the past, but not for many years.
However, we're talking about much more powerful devices here. Even the most basic smart phone packs quite a bit of processing power these days, and much of the core functionality is provided at a hardware level, so the level of abstraction provided by a driver model is absolutely essential. If you go low level, then your application isn't able to take advantage of the additional power offered by some devices but not others. You end up coding to the lowest common feature-set.
Making use of the APIs which provide interoperability and a standardised framework is the only way to ensure that your software will run on all Android devices, something which from a business point of view is essential.
For what it's worth, I was always a big fan of Palm's work back in the day, but they really haven't moved with the times, and I genuinely can't see them surviving for long now that Google have put together what, certainly at first inspection, appears to be a very fine, well thought out, free mobile platform and application stack, especially as they are also providing all of the necessary tools and support for free.
I know I'll certainly be putting in the time to fully learn the APIs and try and come up with novel commercial ideas for a chance to get hold of some of the $10M cash their putting up to get as many people involved as possible. I suspect many others will be doing the same.
With a company the size of Google behind the software, and interest from plenty of big players on the hardware front, coupled with sensible Open Source choices when it comes to the main platform components, I can't see it being anything other than a success.
Whilst it's currently being marketed as a smart phone platform, Android easily has the potential to spur on the creation the sort of non-mobile convergence devices that we've been expecting for years, but which have failed to materialise. If you look at the functionality provided by the platform, it's more than capable of providing all of most people's day to day requirements of a full PC, and not just a mobile device. If you ignore gaming, which has always been the driving force behind the push for faster hardware, then most users only require a small fraction of the processing power available in their desktop PC, so I wouldn't be at all surprised if within the year we didn't have full desktop oriented devices based around Android on the market.
As you can probably tell, I think Google have done pretty much everything right as far as Android is concerned, and I'm very excited about it. I fully expect the smart money and development talent to be behind them, if not from the very start, then very soon.