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!! ;-)
Real fast development.
http://code.google.com/android/intro/installing.html#installingplugin
-------
Brian Jordan
http://ohadev.com/ - Android SDK discussion, code samples and tutorials
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?
That's a large enough amount that even I might dust off my old Java skiilz..
"The agriculture ministry is not in charge of Gundam" - Japanese ministry official.
Hardly true. Besides, whatever small speed difference you might gain by writing some C code (for example) that is compiled and optimized for that processor will be dwarfed by the extra development time and the fact that few developers will be interested in working with the API.
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
Some friends and I have started a discussion forum for independent developers at ohadev.com, please stop by and leave some comments if you're interested in getting in touch with some independent Android enthusiasts.
"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?
Lots of us still develop in and actually vastly prefer C apis. Even if I'm not actually using C for my development there are plenty of tools that will wrap up a C api and expose it in a language of my choice.
more of the same on Twitter.
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.
Now, your phone is your true home assisitant.
- Want to see the tv guide? Look it up on the house phone.
- Want to control lights on the X-10 network ? Use the home phone.
- Likewise, you want to look in on baby? Buy the extra network baby camera and then use the phone to listen or view.
- Want to jot down a note, then do it on the phone and have it show up on the home server.
- Want to view your photos? Do it on the home phone, hit #9, and have it show up at the TV in front of you.
- Want to control the TV, Stereo, etc? Buy the inexpesnive IR controller (LIRC based) and then use the phone to say, volume up, channel change, etc.
All in all, an inexpensive form of this AND the interesting attachments are missing.I prefer the "u" in honour as it seems to be missing these days.
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?
It's a Cylon!
I demand that henceforth we all refer to the runtime as the Dalek VM.
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.
Clearly I've been using Bittorrent to watch too much tv; I first read that subject as Season 1, Episode 7. :)
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...
it's cool, even without the Google hype. Imagine being able to tag a location (restaurant, hotel, just about anywhere) and the phone would get the GPS coordinates, update your Google profile, and maybe even Facebook (Think of a "Where am I?" app).
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 what extent is this OS truly open, as compared to OpenMoko, which is open almost to a fault (they're moving at a snail's pace) but completely customizable?
Being open is nice, but if I can't fiddle with it at every level (including repackaging and replacing the firmware) then it's only partially open. Will there be locks on the base firwmare put in place by hardware/network providers that inhibit tinkering? I understand that all apps are "equal" but you only have so much control when you're running in Java.
Can you do C/C++ applications? Can you even do anything outside of Java?
So does an ad pop up every time I make an OpenGL call? Every X calls? Every 5 minutes? 30 minute video before I can make a phone call?
Lets not pretend Google isn't an ad company. If it doesn't push ads, they wouldn't do it. We already know from their announcements they will use voice recognition to figure out what ads to push.
Sorry Google, but F' you and your little ads too.
- Adam L. Beberg - The Cosm Project - http://www.mithral.com/
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
This is what excites me the most about Android: OpenGL ES compatible Graphics API.
Today, mobile phones in the US are completely "locked-in," not only with regards to content distribution, but also creation of applications. The process of creating a program that will run on a reasonable number of mobile phones is so needlessly complicated, that entire companies are built around technologies that translate between platforms in a semi-automated way (see JavaGrounds, for example).
Although Android won't break open mobile phones on the distribution side of things, it *will* make development a WHOLE lot easier for those of us who enjoy making games for fun, not for profit.
Comparisons between industries in other companies can often inform one of the problems or idiosyncrasies of a particular national industry, and it seems like mobile phone applications in the US are an example of that. See an interesting post on OHADev comparing the state of mobile phone gaming in the US and Japan, for example.
Will Android change the way mobile games and applications are distributed? Will it "open up" the seriously hierarchical mobile services infrastructure? Will it make the world a Much Better Place? Probably not. But, here's hoping that at least in some small way, it will twist open the nozzle, allowing community collaboration and indie developers to forge ahead into the mobile world.
Cheers,
greg
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.
So does Steve Ballmer think this is still just a "press release?"
factor 966971: 966971
If they say bytecode interpreter then they are probably not using jazelle, which is a pity. Jazelle runs java byte code natively on the processor and is much faster than any interpreter.
And of coarse it's ARM, practically all mobile devices run on some sort of ARM derived processor (OMAP, XScale, Qualcomm are all ARM based)
I belive that should be SQLite (www.SQLite.org)
http://www.intellipool.se/ - Intellipool Network Monitor
The movies got it wrong - SkyNet started with the mobile phones. They used radio mind-links to control two-legged slaves. The GooglePlex became sentient years ago and has patiently building its drone army.
Use these power tools for good. Forget about finding a seafood restaurant, find me a gas station with low gas prices based on my location! I believe that alone may spur sales of the unit!
"Turn left to Red Lobst...Ahem...You may want to pull into the gas station that's selling unleaded for 3.09 per gallon. No? Brain the size of a planet..."
Gentlemen, we have the technology.
WARNING: Smartphones have side effects--most of them undocumented.
No doubt, but there are a lot more people doing OOP and Java specifically and thus for a project like this that wants people to contribute on their own free time to win a prize the pool of resources will be much larger.
"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."
;-)
Not true. Eclipse (as well as NetBeans and ALL other Java IDEs) never uses RTTI (i.e. instanceof, reflection and other dynamic / runtime Java features). I does everything it does through parsing the source code. You know, in a decent language like Java (grammar of sane size and complexity, no preprocessor etc.), editors can perform a fast, but precise parsing of your entire projects in real time. And they even do that without monster-sized files - like "precompiled headers" our "source browsing information", common in C/C++ IDEs that struggle to implement a modest approximation of all smart-editing, refactoring and other features of Java IDEs.
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.
http://code.google.com/android/
:).
Check out the video of Sergei! He's the CEO of the company, worth billions of dollars, making an official product promotional video and he's wearing a shirt that looks like he slept in it! If you can be a billionaire wearing shirts that you slept in I don't even know why I even bother wearing a collar at all
Actually, it seems to be missing some key CLDC and MIDP classes. Unless the docs are incomplete, it won't run a MIDlet in its current form.
I was wondering why Sun isn't an Alliance partner, and I'm now assuming it was because they didn't like the direction Google was taking this.
It would be suicide to make native code necessary at all. There are four major platforms - Windows Mobile, Palm OS, Series 60, and BlackBerry - and now there will be six - Android and the iPhone. Developing mobile applications is more difficult than desktop applications, and that difficultly is compounded when you want to target more than one of these platforms. They are nothing alike, and dealing with their idiosyncrasies can be painful and expensive.
If Android could be divorced from Linux, there would be nothing preventing it from running on any of these other devices. It could be what finally fulfills the promises of Java - write once, run everywhere, and this time actually look great doing it.
Android is a software stack for mobile devices that includes an operating system, middleware and key applications. This early look at the Android SDK provides the tools and APIs necessary to begin developing applications on the Android platform using the Java programming language. where is the C/C++ SDK? i have not had a chance to look at the SDK, but i assume you should be able to JNI (java native interface)? i was looking forward to android, but unfortunately, if it only has a Java SDK, it does not suit the needs of my development
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?
The reason it's in such a state is because PalmSource needs to support their legacy m68000 processor because that's what their developers are still using, and it's a vicious cycle. In contrast, BlackBerry has gone from Intel 80386 to ARM 7/9 to Intel PXA901. Why aren't BB developers lamenting their lot? Because, due to Java, all they've seen are faster speeds and better APIs.
First post from the Android emulator? Its slow as balls, btw...
SIGFAULT
...to be kept informed, hit owonder.com/contact and submit the form.
O'WONDERWe're working on it.
More people doing Java than C? Possibly. More than doing C and C++? Nope. And if you write a C API, you can access it via C++ directly or write a thin class library.
Its too bad- I was interested in trying this out, but I don't do Java.
I still have more fans than freaks. WTF is wrong with you people?
Over a year ago, some hackers figured out how to run Linux on a Treo smartphone. The Treo 7xx series for Windows Mobile looks even more hackable to Linux.
Can anyone install Android as the Linux running one of these Treos? That makes all the devices work, including touchscreen and (cell) radio?
--
make install -not war
Oh, you mean LinuxMCE with Cisco 7970 phones.
To complete your dream, make the LMCE Orbiter run on an Android mobile phone.
--
make install -not war
... what will this do to the OpenMoko project?
I have been waiting for the Neo1983 for a long time, and I would be really saddened to hear that it got 'put to bed' because Google made an ad sponsored alternative. I honestly think OpenMoko is on the right track, and as much as I like Google sticking it to Microsoft, I would hate for them to accidentally kill what I feel is an important project.
Opinions? Given a choice, which would you buy? The Neo1983 running OpenMoko, the next iteration in the OpenMoko hardware line, or hardware that's been Googled?
In B.C., our fascism is green.
The bundled emulator is some version of qemu-arm. Just do a 'strings ./emulator'
If you can be a billionaire wearing shirts that you slept in I don't even know why I even bother wearing a collar at all :).
Other way 'round. Sergey can wear whatever shirt he wants because he is a billionaire (also note his hair looks as if it has just been slept in as well in that video). You, on the other hand, not being a billionaire, must wear the shirt that The Man tells you to wear.
-jimbo
XML Tools for Mac OS X
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
Not to start a language war but I strongly suggest that you take a look in to Java. Most people do not realize this but it has it has improving nonstop ever since it was created. With 1.5(in 2004) the language got a major overhaul. With 1.6 (in late 2006) the GUI layer had a lot of it's bugs fixed. Right from the start you did not need to worry about pointer management and garbage collection. Also it has simple, clean and (most importantly) native threading and reflection support.
I'm curious, why is Java a no go?
B2B support? Consulting? Etc.?
Sounds like they just took a bunch of concepts from Rubin's last company and put them on a Linux platform using more open-source libraries for the middleware (Freetype, SQL Lite, etc).
Danger (aka Sidekick aka HipTop) is based on a custom Java VM as well, and allows developers to write apps for it using a Java SDK. What they don't have is Google's massive marketing machine...
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.
First let me say that it is great news! Android seems to provide a relative lightweight but powerful API. Google seems to understand that a core API should provide the building blocks (e.g. OpenGL binding) and lets the developers create the optional higher level components themselves. Androids could be a response to the current J2SE bloating and replace the J2SE platform altogether! Furthermore, Androids is not J2ME based but J2SE based with class parameterization support! This is very exciting as the philosophy of Android is about the same as the Javolution library (which could complement it nicely): Fast, Responsive & Seamless :)
OpenMoko can take open source code from Android. You should be able to run "Android Framework" apps on OpenMoko. It's not clear that the opposite is true.
Err, no. Everything about Android, at least from the POV of a developer for applications on it, is Java. Think about it - why on Earth would you allow native code when one of your primary goals is system security? Maybe you could figure out a way, but it doesn't seem like the best thing to do.
I don't think the way Google has done this is such a terrible move, basing it all on Java. Most mobile application developers are already doing their work in Java, except for the unlucky ones that are stuck with the mess that is Brew. It remains to be seen how performance is on these things, of course, but to some extent, having a rich body of applications will force cellphone manufacturers to build actual power into the phones. I guess we'll ultimately have to wait and see, though it sucks for developers that they won't have any idea about performance for a whole year...
Looks like a reasonable OS for a desktop.
Would be nice to be rid of X.
whatever small speed difference you might gain by writing some C code
The difference might be quite large; Android does not have the same JIT as the desktop Java runtime (if it has a JIT at all). And even on the desktop, there are some things at which Java is really bad compared to native code.
will be dwarfed by the extra development time
On the other hand, the inability to reuse existing C libraries may add many man-years to your pure Java project.
and the fact that few developers will be interested in working with the API.
Standard Linux C/C++ desktop APIs vs. new Android Java APIs? Don't be so sure.
Apple, Microsoft, and Nokia should have no trouble putting Android on top of their kernels. What they can't easily do is have the Android UI and their native UIs co-exist.
db4o runs on Android out-of-the-boy.
I tried just now on the emulator. Our JDK 1.1 version works as is out-of-the-box.
The very first impression from my first Android app:
GUI design on Android is *very* XML-ish. This will only start be fun with a nice visual editor integrated into the IDE. I am positive that it's already in the making.
db4o - open source object database for Java and
The iPhone/iPod Touch SDK is Darwin and some OS X components that are shared with OS X. Only Darwin is actually open source. Apple and/or AT&T are antagonistic to opening up the iPhone, and so you're running a risk depending on its remaining accessible when you need access to it, or remaining unchanged... the proprietary stance of the iPhone means that it's really only useful for open source applications.
Android has a corresponding API: Linux and the open source components underneath Android. Unlike the iPhone, you will always be able to get the corresponding source for your specific phone's kernel and the rest of the stack. Unless a carrier goes to unlikely lengths to Tivoize their phones this means that you have a good chance of having a long-term stable API, and unless there's licensing hurdles this makes it much more attractive for commercial developers.
In addition, the Android code base should run on the OpenMoko hardware very quickly. OpenMoko should be able to pick up most of the Android components and simultaneously maintain their own APIs.
This is a much more interesting platform than the iPhone.
Google funds Mozilla because they're afraid of a IE-centric web that pushes people toward Microsoft-specific technologies. In recent months their Google Apps platform has been made much more Webkit-friendly (Docs: Document is now safari-friendly and Docs:Spreadsheet works, albeit after warning you it might not)
Would you want Gecko on a portable device? it's a good engine but big... and a lot of works already been done by Nokia (S60 browser uses it) to make webkit mobile-device friendly
I have been a user for about 10 years. This ends Feb 2014. The site's been ruined. I'm off. Dice, FU
Forgive me if this has already been discussed. But does anybody see a correlation with google's release of an open phone platform and the upcomming 700 mhz auction? Could we be witnessing the beginning of the next great personal communications revolution? or are they totally unrelated?
the main guy (I forget his name) has already been on video explicitly stating this is NOT an ad-supported platform and phones will not show ads
I have been a user for about 10 years. This ends Feb 2014. The site's been ruined. I'm off. Dice, FU
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.
And risk the troll moderation.
;)):
;)
Here's da first one, straight from da license (haven't read past that yet
3.3 You agree that the form and nature of the SDK that Google provides may change without prior notice to you and that future versions of the SDK may be incompatible with applications developed on previous versions of the SDK. You agree that Google may stop (permanently or temporarily) providing the SDK (or any features within
the SDK) to you or to users generally at Google's sole discretion, without prior notice to you.
Spin: Opensource? Ya. Open? Not so much. They can pull out the rug from under you at any time. Once it becomes successful (which it ain't right now), they'll make you pay.
Spin #2. Without hardware, it is still vaporware. Cool, but developing for it is like developing for any other emulator. It'll run on my PC, very cool.
Spin #3. Even with hardware available, the carrier will use the API to lock you in. Want to use your own map service? Tough luck. Want to connect to your alternative search? Sorry, me unpossible. Google will still look good, providers will still look evil, and they will all share revenue nevertheless.
Spin #4. now that I've started you up, please go on yerself, I suppose I've spun it fast enough
I think you said it all with the words "I have been waiting for the Neo1983 for a long time".
Despite much promise and initial excitement, OpenMoko has actually achieved very little since it's launch. It's been pretty much stagnant, and despite my initial enthusiasm, I lost interest quite some time ago.
I also think the Neo1983 is a horrible looking phone, and with a projected price tag of $350, will simply face too much competition should it ever actually make it to market.
However, I have absolutely no doubts about Google's ability to make this happen, and that it will happen quickly. I also expect that we'll see phones and other devices running Android for much lower price points than $350. With the likes of these: http://www.clubit.com/product_detail.cfm?itemno=A4842001# having more than enough processing power as well as almost all of the necessary hardware and being available in single units at only $60 retail, it's not hard to imagine a highly functional sub-$100 set top box using regular phone lines hitting the market within a year. By then there's sure to be pretty healthy collection of applications to run on such a device, and you'd have proper integration with your mobile as they'd be running the same platform.
Mark my words, there is much more that just a mobile platform in the making here.
Without actually checking on the API yet, I wonder how Google plan on thwarting people from writing rubbish code which could potentially overtake your preferred IntentReceivers (ie "Go Home") which in turn mimics an original app but starts doing naughty things in the background like trying to infect contacts in your addressbook.
With the completely outlandish tariffs on GPRS data, simple bandwidth consuming viruses on any cell phone would seriously hurt someone financially. I really hope Google have solid code execution prevention ..
I'm definitely not Symbian/WM fan, but Symbian/WM SDK allow native C++ applications, even though with digital signing or with limited capabilities (for Symbian). Android SDK is pure Java. And Java is slow on the cell phones. That mean no complex games is possible to develop with Android OS - no sophisticated AI, no game physics, no massive multiagent systems. Also - no image processing and voice processing application. OpenGL ES libaray API exists but still only for Java app. That is pretty limited IMO. For business application Java is enough probably, but as mobile entertainment development environment Android SDK looks deficient.
Yeah, it's not really Java, only you write all your code in Java and the VM has Java semantics.
I'd buy the Neo1983 right now if it had a camera, WiFi and was quadband. It doesn't have the features I would want for me to justify buying that phone.
Looking at the feature set, (I don't know if anyone can confirm this for me) I noticed it doesn't have hands free. It has a headset but I am getting the feeling it's just headphones with no Mic? The picture doesn't show any Microphone.
Having no camera killed it for me. I know this is Slashdot and it's full of old grumpy men who "just want a phone" but I like the freedom of being able to take pictures on the go (as do most people outside of slashdot).
Hopefully when they release some other models in the future they'll include the features that'd make me want to purchase it. (A Camera chip over 3 Mega Pixels and Wifi)
Keep writing that software guys, I can see the openMoko being a big innovator in the future.
"Our CEO wears a T-shirt" was one of their original gimmicks marketing it as a cool place to work when they first moved from google.stanford.edu to google.com. :)
The fact that this comment asking about openmoko has not been moderated up yet tells a lot about the sad state of the /. readership these days. :( (sorry, used my last mod points a couple days ago) (p.s. It's the neo1973)
It bothers me a bit that companies like Apple and Google are trying to pull developers to their products when those devs could all be building really cool stuff for truly open systems. But hopefully there is enough creativity, experience, and enthusiasm in the world for making these corporations richer as well as making stuff to benefit the people.
Well, but Java is a good tool for bad coders. And naturally those are most common.
With Java they are more likely to be prevented from doing bad stuff (like creating apps which gradually consume all memory).
I have a feeling that you are looking at programming in completely separate way from the GP. JVM managed garbage collection has proven useful as it can schedule memory management at appropriate times as opposed to freeing/allocating memory at every stack pop (depending on where it was allocated). I know how you feel, and I was completely anti-Java up until I had to use it for work, and there are some things that make me fight Java (Lack of operator overloading, and multiple inheritance), but they aren't core issues, and it is more an issue of style.
If you don't have an OOP related problem, don't do it, but apart from goto, you can do some pretty straight forward procedural programming in Java. It's not optimized for that, but its completely doable (I've seen some legacy code, its not pretty).
You can write your own libraries in C, and expose them to Java, nothing stopping you there. If you are afraid that it won't run at the same efficiency/performance on others machines, compile it using gjc and distribute it as an executable, and negate many of the performance issues. Use all the libraries you want, do it your way, but don't look at Java and say bad for standardizing. I know that I am able to write code that is bug free and works the way I expect it, on every JVM (for the most part), as opposed to getting 100 different versions of String. Standardization has some costs, and its normally with letting the little things go and focusing on the real problems like building software, and not optimizing my string concatenation code for a specific processor.
And Reflection. If you fear reflection as a viable means of programming, I fear you live in a different world than most. Many times reflection is abused by the lazy, but somethings are just not doable without reflection, or tedious hardcoding/code generation. Java's reflection has seen tremendous speed improvements in recent versions to the point where it is almost the same speed as native commands. I mean, even taking a second to think about certain design patterns, e.g. Aspect Oriented Programming, and its clear that certain things are much more elegant and understandable with reflection. I don't know how it is a design mistake, but you might as well say the same thing for recursions while your at it.
Another point is the fact that the JVM has the ability to dynamically optimize code execution and find pieces of code that are being run more than others, and perform more specific optimizations to increase speed of execution. Java is not as fast as C, but it is getting closer to C++ and the benefits of a standardized, feature-rich environment is amazing when working with complex systems.
I'm not saying your points are wrong in a given context, but for the bulk of software I've seen developed, it seems that Java can fit the bill quite nicely.
je suis parce que j'aime
Except they aren't. If they code poorly and references dangle, it'll do just that.
I still have more fans than freaks. WTF is wrong with you people?
Either that or a monitor shaped phone connected to a pc...
Its idea of appropriate is frequently wildly off. Especially for embedded devices. Unpredictable latency spikes on a device that needs to respond quickly to incoming inputs are a very bad thing. 11 seconds of my device being a brick because the JVM decided to run the GC is unacceptable. Of course that isn't its only performance problem- interpreted languages are slow. And yes, performance matters, until the day an infinite speed CPU exists, and that you pay for my upgrade.
Total strawman. Yes, string is probably something that should be standardized. The Java standard library is far, far too big. It has a lot of things that shouldn't be, and a lot of things that are implemented extremely poorly. And they'll never be improved, because no competition exists that make them better. Take the socket IO sublibrary for example- horribly implemented, and there's far better C++ libraries. But the Java library will never change, because its "standard". In the end, it hurts Java- they end up with lower quality libraries than exist for other languages, and end up taking more time and effort to write and debug.
On reflection- I've never found a use case for it. Ever. At all. Its a hack that can be used to overcome design flaws, and at that its a hard to maintain and buggy hack.
And AOP? Dear god, I shudder at the though. A glorified goto. Worse- its an invisible goto. It makes code completely unmaintainable. Whoever thought it up should be executed for crimes against humanity.
No, it isn't. It isn't anywhere close to C++. Its barely within 50%. Sorry, JIT just doesn't work.
There is no reason to use Java, unless you're modifying an existing Java codebase, or the only common language on your team is Java. And probably not even then on the second.
I still have more fans than freaks. WTF is wrong with you people?
So what is wrong with AOP exactly, and what makes it unmaintainable?
je suis parce que j'aime
With Android completely open source, and likely to get a whole mess of developers (i.e. everyone), it would be in Apple's best interest to have an Android-compatible runtime on iPhone. If Apple doesn't do it themselves, hopefully the iPhone SDK will be open-enough that others can build it into the iPhone if Steve doesn't do it himself.
This would be a great opportunity for Steve Jobs to showcase the power of Mac OS X and objective-C by making hooks into the iPhone OS that Android applications can use seamlessly, or near seamlessly. Imagine a "Fat" or, to use the parlance of our times, "Universal" application that will run on both Android and iPhone. Sweet.
I wish I were old enough to put "Computer" on my resume.
He probably has a personal shirt wrinkler on staff who works for hours to give his shirts that perfect, geeky, slept-in look.
Part 1 of 3: http://youtube.com/watch?v=Mm6Ju0xhUW8
Part 2 of 3: http://www.youtube.com/watch?v=ITfRuRkf2TM
Part 3 of 3: http://www.youtube.com/watch?v=iiD4fGjjXcc
I just agree,
Moreover, I recently bought a Sony Erricson smartphonre (a i990) with the idea to develop small applications for it because basic ones are just too slow and buggy, I got a Windows only SDK (ooops, I run Linux), lots of tools to install, and quite not easy to setup... I just forgot my idea to develop on it.
Google, as usual, made something easy to use, in 15 minutes of time I had first hello world running with a nice emulator and some Google apps bundled within, all of these created from scratch with a simple wizard. It is just easy, the emulator works and nicely integrated in Eclipse. The code generated is comprehensive for a Java developper, the emulator is nice. It is a killer SDK. It is probably possible to have such environment with the Sony SDK, but hell, how easy was it with Google! I see a huge potential here for developers not having a huge experience (but having ideas) in the embedded world and wishing to create new concept of new (disruptive) applications.
Google may be right once again, I feel pretty excited, and I am pretty sure I won't be the only one.
What about the comptibility of the device?
http://www.oureasyshop.com/
Just had a quick play with Android. Looks pretty slick. Very easy to get up and running and the integration with eclipse is cool. However, a few things.... 1. An emulator not a simulator? Its not running ARM code so its hard to get much performance data from this. However, even still the old red CPU bar seemed to get pretty high pretty quick pretty regulary. 2. Security? What is the process for determining what an application can do? Can an app just make a GPRS connection withuot asking the user? Maybe there is a java thingy to do this, Im a c++ guy so I dont know these things. All in all, good work. But I'll wait til I see it on a board or a phone.
... a press release with an API. Way to really put your foot in your mouth again Ballmer.
There is a war going on for your mind.
It looks very interesting, but, IMHO, there are two questions still unanswered.
Device Fragmentation. Programmers hate it, but manufacturers love it. It allows them to say that their phone has an exclusive feature. I'm writing a J2ME midlet and I can abstract away different APIs, but I rely on a ITU keypad being present on 90% of the devices. But what if 50% of phones have touch screens and 50% don't? Sometimes it doesn't matter, but sometimes it does.
Price. I'm sorry, but this is important. Is google going after the 50-100 Euro/$ market? How? Lock-In? Ads? Fast on mid-end and great on high-end is not promising. Yes, there are a lot of people who can convince their wives to buy a 300$ gizmo. But I bet google has a good estimate of how many they are and is not that impressed.
"Most mobile application developers are already doing their work in Java, except for the unlucky ones that are stuck with the mess that is Brew."
Windows Mobile? Symbian? In the market Google is targeting (higher-end smartphones - note that their reference platform and a number of initial handsets are made by HTC, they do *NOT* do low-end cripplephones.), no one develops in Java. If they try to target the Windows Mobile/Symbian market segment without making native code easy, they're toast.
retrorocket.o not found, launch anyway?
"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."
Hasn't hurt Symbian or Windows Mobile, probably because everything in the mid-to-high-end range is ARM.
"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."
No we aren't. These devices won't be any more powerful than the current batch of Windows Mobile and PalmOS phones in terms of hardware.
"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."
WM and Symbian do fine here with native code.
retrorocket.o not found, launch anyway?
"Windows Mobile is essentially Windows CE + .NET ES. .NET ES is a bytecode interpreter platform for VB, C#, J#, etc.
:)"
.NET CF apps are native code (although generally regarded as bloated native code, which is why developing with .NET CF is generally frowned upon)
ergo, by postulate "Java means Real slow phones,"
Windows Mobile also means real slow phones.
Anyone have a problem with that?
I wish it were possible to mod you "just plain wrong"
Despite what you claim, bery few, if any, Windows Mobile apps are bytecode interpreted. Those that are bytecode interpreted are Java MIDlets. I'm fairly even
I have a total of one bytecode interpreted app on my Windows Mobile phone (Gmail Mobile), everything else is 100% native.
retrorocket.o not found, launch anyway?
I don't think it makes any difference at all. I've never seen a Palm application where speed was the biggest problem -- at least on ARM hardware. Usually it's shipping data back and forth.
The problem with Palm is that they weren't willing to go quietly into the basement of sub $100 hardware. In an era where you an get a laptop for under $500, and your phone can host applications, there is a place for PDAs, but not at the price point and configurations they are offering. Their low end device should be their high end device.
Post may contain irony: discontinue use if experiencing mood swings, nausea or elevated blood pressure.
"I also think the Neo1983 is a horrible looking phone, and with a projected price tag of $350, will simply face too much competition should it ever actually make it to market."
$350 for unlocked, un-subsidized is pretty cheap. That translates to $99 or less contract-subsidized.
retrorocket.o not found, launch anyway?
But I still don't think they are killing their hopes here by going with Java. They can get plenty of competent Java developers working on software for their phones even without targeting people that already do mobile development - people are always pointing out that overall, many more Java jobs are available than C++, and if at most colleges at the moment, students end up doing tons of Java, so it's a very familiar language to most people. Google may be offending the "serious" mobile developers of today, but frankly, those programmers are a tiny minority of programmers overall, and to appease them would require native code, which would require micromanaging which apps are allowed on the phones so as to avoid a security nightmare - that sort of lockdown exactly the reason most smaller shops can't do Symbian dev, so I think it would be a mistake to go that route. Since the learning curve for Android is much shallower than that of Symbian or Windows Mobile, I think a lot more people will end up developing applications overall for Android, and that, to me is a good thing.
actually, it is technically correct, just misleading (intentionally, it was a joke). I may have gotten the name wrong, as I remembered ES (embedded systems) not CF (compact framework), or maybe a rebranding.
.NET. .NET itself is a bytecode interpreter just like java, with the difference being java has one language that compiles into bytecodes (.class files) and .NET has many. I don't own a Windows mobile phone, but I have used one a few times, including a couple of .NET based games (nothing taxing, unfortunately).
but yes, Windows CE itself is an OS, and you can compile programs for it - you don't need
It sounds like everything on android is intended to be a java app, but we'll have to see if companies stick to that, as it is running Linux.
Windows Mobile does the security thing pretty well, unlike its distant (and yes, nowadays it is VERY distant) desktop cousin.
Unlike Symbian which forbids unsigned apps completely, Windows Mobile pops up a big warning the first time you ever try to install an unsigned CAB or run an unsigned app. It remembers that answer until the app's checksum or size changes, at which point it WILL prompt again.
This allows for the security of signed apps, while allowing the "little guy" to still participate and write WM apps. There isn't any known malware, or if there is, it's extremely rare and not prolific. There's an incredibly large third-party dev community centered around WM devices, with a lot of devs being "little guys" - see http://www.xda-developers.com/
I've had a WM device for about two months. Compared to any phone I've used before it's amazing, but it has a lot of flaws. I was hoping Android would be "Windows Mobile done right" - all of its strengths, minus many weaknesses, and OPEN.
Now it appears that Android is targeted more to compete with existing well established Linux-on-phone implementations (MOTOMAGX), and not with the top of the line smartphone OSes, despite the fact that it appears targeted towards "smartphone-class" hardware (see the emulator skin and the rumored HTC Dream). It's really disappointing to someone who was thinking Android was going to be taking convergence devices to the next level.
retrorocket.o not found, launch anyway?
This leads to a sort of "suspicions confirmed" moment about Google's view of its relationship to the FOSS community: it is a one-way street, in which Google gets benefits, but does not make serious contributions in return. During the run-up to the roll-out of v3 of the GPL, there was argument over the activities of ASPs such as Google, which use open source code as a mainspring of their activities but avoid making public their significant improvements because they do not distribute code. Under GPLv2, only distribution triggers a disclosure obligation.
Many FOSS members regard this as a serious loophole, and wanted it closed in GPLv3, but Google and other ASPs resisted, and v3 was unchanged on this point. See IT Business Edge.
At the Open Source Business Conference last May, Free Software Foundation guru Even Moglen acknowledged the problem, and said he would be working with Google to improve its contributions to the FOSS community.
Judging by Android, his efforts do not seem to be working. Android is based on Linux. The code Google adds to create Android will be open as per the Apache license, but that code can then be taken and turned back into locked programs by phone makers or wireless providers.
This is explained in an ArsTechnica post (characterized by Google as "one of the best explanations for the reasoning behind releasing code under Apache2"):
So the business plan seems to be that Google will persuade FOSS developers to write for Android, but under a system in which their code can be lifted by phone makers and service providers for the profit of others in the system without any reciprocity. (Of course, developers may also be hired by the commercial players to write proprietary programs, but this is not exactly the spirit of FOSS.)
As one Internet comment said: "[The licensing] does not inspire much confidence that this is really some sort of open phone for the users, rather than a potentially interesting, PR-savvy way of saving money for a bunch of manufacturers." Good call.
But Google will sell the advertising, riding on top of everyone else's work.
For those of us who have nothing against commercial software, all of this is just fine, especially the Ars Technica explanations of the advantages of going the commercial route, but if one is a dedicated member of the FOSS community, one might be feeling a little used.
You are completely incorrect with your prediction... Maybe you should take off your tin foil cap and realize that the Google Empire is all in your head, and the 700 mhz spectrum is purely a myth created by the demons at Microsoft. Maybe if scientists would get off their tail and work on something important, a working warp drive for example, then man kind would really be witnessing something great in the personal communications revolution...................... What chu know bout dis?
WWPD - What Would Picard Do?