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.

Comments

Hardware?

[Andy Dodd]

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.)

Re:Hardware?

[aneviltrend]

True, measuring actual current draw and temperature statistics will always require the physical hardware in question. But modern hardware simulators are able to accurately model such parameters (as well as architecture-dependent events such as cache misses) and give a good feel for the performance (both in terms of power consumption and software speed). And I'm sure an architecture as popular as ARM has several simulators for that exact purpose.

Re:Hardware?

[angryLNX]

What would be needed would be a developer's model for these phones,
and the correct transfer hardware and developer's kit from a NON-OHA
phone.

Ironically, that makes this really hard, because the old-school (non-
Android) handsets make it very hard to independently develop with.

We have a forum thread discussing this possibility:
http://www.ohadev.com/forum/viewtopic.php?p=23

Cheers,
Brian Jordan
http://ohadev.com/ - Android SDK discussion, code samples, tutorials,
application submission

Re:Hardware?

[Andy Dodd]

What I would love to see is for HTC to port Android to some of their older devices in order to get a developer's platform out there quickly.

Android for Kaiser = drool. Even Android for Hermes would rock.

Re:Hardware?

[radimvice]

"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.)

The "custom Java Bytecode interpreter" probably means a Jazelle JVM or variant. These are specialized CPU/JVM combinations that execute Java bytecode in hardware. This technology is used on many of the Java phones already in the market.

-Will

Re:Hardware?

[ClassMyAss]

Having done a quick pass through the docs, it doesn't look like there's much info on the VM, other than that they're calling it the "Dalvik VM" (a Google search doesn't turn up much - Dalvik is just some place in Iceland, so it's likely they just chose the name).

I kind of doubt the Jazelle thing, though, since Warren East at ARM was talking smack about Android, and they are the ones that do Jazelle...

Re:Hardware?

[Anonymous Coward]

"What hardware platform does it run on?"

It doesn't because Steve Balmer said it was "vaporware".

Re:Hardware?

[Anonymous Coward]

"... Still, to evaluate performance you need real hardware"

Well, if you are talking about performance of the java interpreter, performance is a moot point, it's going to suck. It amazes me how people can think of java worthy to run time critical applications, but then again, most cellphones these days are nothing but toys, seems fitting that google chose java as a toy language for a toy platorm.

Re:Hardware?

[MrLizardo]

Other implementors of the ARM archictecture (think Marvel and TI) have implementations of Jazelle as well it seems, from some quick googling of press releases.

Re:Hardware?

[jrumney]

ARM license their architectures out to Marvell, TI and others. They don't actually build their own chips anymore, so it isn't a case of "other" implementors. That said, the XScale line is based on the ARM5 architecture, and I'm not aware of any Marvell/Intel chips with the Jazelle extensions, which are available on ARM9 and ARM11 cores with a J in the full model number (ARM-926EJ-S). Aplix and Esmertec are both Jazelle licensees, and also members of the Open Handest Alliance, so there might be some Jazelle capabilities in Dalvik that ARM doesn't know about.

Re:Hardware?

[MrLizardo]

Maybe a little late to respond to this, but it seems like TI is also a member of the OHA, and they have several chips in the OMAP line that have a big fat "J" in the name. I should know, I'm ssh'ed into one right now. :) Maybe Android can use the ARM Jazelle bits when they're available and fall back on software. It seems like that would create quite a performance gap, though.

Re:Hardware?

[AVee]

I think there is a fair chance someone will port android to the Neo1973, which should meet the minimum requirements fairly easily and is *very* developer friendly. To me, that will also be (part of) the benchmark on the 'openness' of google with this, if it cannot be ported to hardware of vendors not in the consortium it's not open enough to me.

Re:Hardware?

[loyukfai]

How about Android for Treos?

Java means

[rainhill]

Real slow phones.

Re:Java means

[Anonymous Coward]

WTFV. The Virtual Machine is not really Java. Java code gets converted to Google's custom "Dex" Phone VM.

Re:Java means

[paranode]

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.

Re:Java means

[Andy Dodd]

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.)

Re:Java means

[Metaphorically]

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.

Re:Java means

[paranode]

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.

Re:Java means

[0xdeadbeef]

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.

Re:Java means

[tkinnun0]

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.

Re:Java means

[AuMatar]

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.

Re:Java means

[cachimaster]

The bundled emulator is some version of qemu-arm. Just do a 'strings ./emulator'

Re:Java means

[Creepy]

Let me think about that for a sec...

Windows Mobile is essentially Windows CE + .NET ES.
.NET ES is a bytecode interpreter platform for VB, C#, J#, etc.
ergo, by postulate "Java means Real slow phones,"
Windows Mobile also means real slow phones.

Anyone have a problem with that? :)

Seriously, both .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.

Re:Java means

[AmaDaden]

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?

Re:Java means

[Anonymous Coward]

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.

Re:Java means

[ClassMyAss]

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.

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...

Re:Java means

[m2943]

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.

Re:Java means

[Anonymous Coward]

If these languages are interpreted, then I might see your 10-30% slowdown.

Even very good bytecode interpreters are usually at least 5 times slower than native C.

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).

Good JIT compilation can achieve C-like performance, although it often has about a 10-30% slowdown due to mandatory error check in Java. JITs also work best for long-running processes and machines with lots of memory.

I don't know whether Android even has a JIT. Do you?

Re:Java means

[ciw42]

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.

Re:Java means

[AuMatar]

Performance sucks. Yes, it does. Not up for discussion. I refuse to write or use real apps written in an interpreted language.

It has garbage collection. This is not a feature, this is a bug. Memory management is not difficult to do, and garbage collection doesn't actually help you avoid most of the issues it can cause. In addition, manual memory management helps improve your design- generally the first sign of a bad design is that the memory ownership becomes funky.

Forced OOP. OOP works well on some problems, not so well on others. Forcing it is a language flaw.

I have various issues with their standard library as well. Parts of it are very well done, parts are utter shit. The main problem is being way too abstracted and having far too deep an inheretance tree. The problem is that since its a standard, noone uses anything else. In C/C++, there'd be 10 different implementations of a library to do Foo, and you could pick the best one for your needs. Competition would cause improvements, and eventually 1 or 2 will rise above the rest. In Java, while the truely horrible may get scrapped, the bad and so-so libraries stick around and everyone just lives with them because they're standard. The giant 1 shop stop class library was a mistake, a Boost or CPAN type repository is a far better solution.

Clean threading? POSIX is pretty damn clean, and nice and easy to use. Reflection support? If you need to use a meta-feature like reflection, you made a mistake in design. Its a language feature that needs to go away.

Nope, Java is a no go. I'd prefer C, so I can choose to just stick with that feature set for problems where OOP isn't needed, although I'd be happy with C++ mas well. With Java only, I'll spend my time on other projects.

Re:Java means

[Wesley Felter]

Yeah, it's not really Java, only you write all your code in Java and the VM has Java semantics.

Re:Java means

[octopus72]

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).

Re:Java means

[SavedLinuXgeeK]

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.

Re:Java means

[AuMatar]

Except they aren't. If they code poorly and references dangle, it'll do just that.

Re:Java means

[Anonymous Coward]

How did they swing that one without releasing the source then?

Re:Java means

[AuMatar]

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)

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.

Use all the libraries you want, do it your way, but don't look at Java and say bad for standardizing

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.

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.

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.

Re:Java means

[SavedLinuXgeeK]

So what is wrong with AOP exactly, and what makes it unmaintainable?

Re:Java means

[bad_sheep]

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.

Re:Java means

[Anonymous Coward]

C++ Colin? Is that you?

http://www.hacknot.info/hacknot/action/showEntry?eid=81

Re:Java means

[Andy Dodd]

"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.

Re:Java means

[Andy Dodd]

"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.

Re:Java means

[Andy Dodd]

"Windows Mobile is essentially Windows CE + .NET ES. .NET ES is a bytecode interpreter platform for VB, C#, J#, etc.
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 .NET CF apps are native code (although generally regarded as bloated native code, which is why developing with .NET CF is generally frowned upon)

I have a total of one bytecode interpreted app on my Windows Mobile phone (Gmail Mobile), everything else is 100% native.

Re:Java means

[hey!]

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.

Re:Java means

[ClassMyAss]

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.

Okay, you may actually be right here about smartphone devs, I'm not sure - I was thinking of the aptly described "cripplephone" market, not the higher end one, I suppose I assumed it was the same at the top, too, since I've never even used one of those phones before.

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.

Re:Java means

[Creepy]

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.

but yes, Windows CE itself is an OS, and you can compile programs for it - you don't need .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).

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.

Re:Java means

[Andy Dodd]

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.

Android is not on hardware yet

[angryLNX]

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 COOL app

[cadience]

a TODO list!! ;-)

Eclipse means

[angryLNX]

Real fast development.

http://code.google.com/android/intro/installing.html#installingplugin

-------
Brian Jordan
http://ohadev.com/ - Android SDK discussion, code samples and tutorials

Re:Eclipse means

[Metaphorically]

Eclipse is cool, I like it for development, but can you run the whole thing on an emulator like QEMU or something?

Re:Eclipse means

[LWATCDR]

Why would you want to run it on Qemu?
You could install Linux or Windows and run them under Qemu and then install the SDK but why?

Re:Eclipse means

[Metaphorically]

I'm trying to figure out how the emulator runs. Now looking at the emulator package I downloaded it appears to actually include the QEMU source.

Incorrect repository URL?

[radimvice]

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?

Re:Incorrect repository URL?

[gjuggler]

The link goes to the "canonical" Google Code project page, but it appears that Google has set up a "special" page for the Android project. Note that if you try to use that format for a "normal" Google Code project, (such as my own PhyloWidget: correct, incorrect) you get an invalid URL error.

Furthermore, I was disappointed to see that the Android project's SVN browser page turns up blank. Come on, we want Source Code!

greg
OHADev

Re:Incorrect repository URL?

[gEvil (beta)]

The 'p' is for 'paranoid'.

Re:Incorrect repository URL?

[shdwtek]

"What's that...? (I may be paranoid, but not an android)"

Re:Incorrect repository URL?

[Anonymous Coward]

Ad-hoc? Mirror? My home this is!

Re:Incorrect repository URL?

[AchiIIe]

The source code for the kernel *is* available, here's the GIT repo: > http://git.android.com/ Right now it only includes the kernel, expect more soon.

Re:Incorrect repository URL?

[zolaar]

http://code.google.com/p/android ... some ad-hoc mirror?

Such strange notation, I agree. No doubt we have those meddling Hungarians to thank for this...

$10E7 ?

[blind biker]

That's a large enough amount that even I might dust off my old Java skiilz..

Re:$10E7 ?

[angryLNX]

prize = 10**7

py fo life

--------
Brian Jordan
http://ohadev.com/ - Android SDK news, code snippets, and discussion

Re:$10E7 ?

[paranode]

Well, you get $25k for being in the top 50. Then that gets subdivided after later development into two groups of ten, one group getting $100k and the better group getting $275k.

Re:$10E7 ?

[skoaldipper]

No dusting necessary. Just restore old memories by rummaging through the garbage collector.

Re:$10E7 ?

[LoonyMike]

Well I've been doing too much hex math, I read it as 4327 dollars.

Re:$10E7 ?

[hitchhacker]

Sorry to nitpick, but shouldn't that be $10e6, or $1e7?
Hell, just use <Dr Evil>10 Million Dollars! Muahahaha</Dr Evil>

-metric

Re:$10E7 ?

[blind biker]

You're right. I got my engineering notation wrong.

First patch

[Anonymous Coward]

SIGALRM signals to implement timers. this makes for much better timing accuracy when using "old" emukated Linux kernels

android-emulator-20071111/README:

s/emukated/emulated/

Emulator is a patched QEMU.

Android will start the Java tornado on devices

[Carl Rosenberger]

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.

Re:Android will start the Java tornado on devices

[Anonymous Coward]

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. Mobile Java *did* have a success. People realized it and it's now ubiquitous.

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. That also has already happened.

Re:Android will start the Java tornado on devices

[Anonymous Coward]

Hey, Carl! Long time, no chit-chat. :)

Looking at the Android platform, it's not completely Java based. It's actually a Linux platform with the APIs exposed through Java APIs which are compiled down to a custom VM platform. AFAICS, it's not MIDP compatible. Which means that DB4O won't run without being full-up ported. Which could be interesting considering that the API looks like it was designed by a former Microsoft employee... (What is up with the Hungarian notation? And why are all the services so disorganized?) :-/

--jbanes

Re:Android will start the Java tornado on devices

[Anonymous Coward]

Of course, the infamous "write once, test everywhere" :-)

Re:Android will start the Java tornado on devices

[ReeceTarbert]

This is the the single best possibe thing that could have happened for the success of Java on devices.

And what about Java ME then? It has been around for a while now and, for better or for worse, it's available on a lot of devices.

RT
--
Your Bookmarks. Anywhere. Anytime.

Re:Android will start the Java tornado on devices

[bondjamesbond]

The number of mobile phone users without a PC will soon be an order of magnitude higher than the number of PC users.

Order of magnitude?? You don't get around regular computer users much, do you? Most of the people I know want a phone to be a phone and a computer to be a computer. Screen size and not-wanting-to-be-bothered-all-the-time has a lot to do with gadget adoption. I think you meant "order of magnitude within my circle of friends.

Re:Android will start the Java tornado on devices

[drix]

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. There are close to a billion PC users, and there are six billion people on planet Earth, so no, there probably will not be that many more.

Re:Android will start the Java tornado on devices

[dintech]

Oh alright, why don't we just do what we always do. Hijack some other idea and do it open source, does that sound ok to everyone?

Re:Android will start the Java tornado on devices

[Anonymous Coward]

Advice for next time: read the post first, then answer.

Re:Android will start the Java tornado on devices

[Andy Dodd]

Mobile Java is a joke.

Look at the list of compatible devices for, as an example, iD Software's mobile Java-based games (like Doom RPG).

That's an awfully short list for a "write once run anywhere" platform...

75% of the Java MIDlets I tried in the JVM for my Treo 650 did not work. Probably 25%+ of the ones I've tried in the JVM on my AT&T Tilt don't work.

Re:Android will start the Java tornado on devices

[Anonymous Coward]

Actually I'm a j2me developer. I _know_ it doesn't work exactly as promised:) In fact from a programmers' perspective native platforms are heck of a lot easier to deal with. However, that's what makes it even more amazing. How did they do that?

Re:Android will start the Java tornado on devices

[Andy Dodd]

At least for Windows Mobile, Microsoft has declared a minimal amount of platform standardization, which is why developers really only need to write once and compile once to run on any recent WM device.

It used to be that there were a variety of CPUs allowed for PocketPC, but as the market share for many of them declined, everything but ARM was deprecated with recent versions of Windows Mobile. (May have started with PocketPC 2003?) It's kind of similar to how as MIPS and Alpha lost market share, resulting in later versions of NT dropping MIPS and Alpha support.

Despite this standardization, there's still plenty of flexibility available. (Some phones have video accelerators, some don't, some have keypads and lots of buttons, some don't, etc.)

The only major difference where developers have to be careful is the difference between non-touchscreen and touchscreen devices (WM5 Smarphone Edition vs. WM5 PocketPC Edition, and WM6 Pro vs. WM6 Standard). Often this does require a differently written and compiled application due to the UI differences between the two types of phones.

Independent developers discussion forum

[radimvice]

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.

Re:Independent developers discussion forum

[Hugo Graffiti]

How can you be an "independent enthusiast" for something that was only revealed a few hours ago and that therefore you can know very little about?

Re:Independent developers discussion forum

[jericho4.0]

$10,000,000 helps.

Terr'rists, Italians and Quebecers not allowed.

[trolltalk.com]

"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!

Re:Terr'rists, Italians and Quebecers not allowed.

[bucky0]

IIRC, There's some weird laws in Quebec about contests with prizes. Most contests aren't applicable there because of that.

Re:Terr'rists, Italians and Quebecers not allowed.

[trolltalk.com]

Yep - you have to pay a "license fee" of 10% of the potential prize to the government as a "permit" - even if nobody wins.

Of course, the simple way around that is to submit it via the web, naming a relative in another province/state.

Re:Terr'rists, Italians and Quebecers not allowed.

[MrNonchalant]

Cuba, Iran, Syria, North Korea, Sudan, and Myanmar (Burma) are due to export controls on countries the US doesn't play nice with. Quebec is because they have asinine rules about contests. Italy I have no idea, but it's probably similar to Quebec.

Re:Terr'rists, Italians and Quebecers not allowed.

[jrumney]

In Italy, contests are only allowed if Berlusconi wins.

Re:Terr'rists, Italians and Quebecers not allowed.

[Serhei]

Actually, it's because Quebec places onerous restrictions on any sort of contests within its borders: lots of ugly paperwork (such as filing ALL ADVERTISEMENTS 30 days in advance with the government), and a tax measuring TEN PERCENT of the value of the prize. So no one ever goes to the trouble except Quebec lotto companies. All of this is designed to protect the residents from fraudulent sweepstakes, but ends up protecting them from sweepstakes of any sort. Just google "Quebec sweepstakes" to find out.

Java is not bad for mobile phones.

[radimvice]

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.

Re:Java is not bad for mobile phones.

[Metaphorically]

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.

Not disagreeing with you but it's important to point out that the Java that runs on a phone is micro edition which has some important differences from standard edition. They're not exactly the same thing. And it's also important to note that there are other contenders for cell phone apps like BREW (at least that was around a while ago, not sure if it still is).

Re:Java is not bad for mobile phones.

[bitserf]

The impression among Windows developers that Java is necessarily slow is because they have something to compare it to on the same OS, which is functionally identical: The .NET CLR.

It still runs circles around Java on the same hardware.

Re:Java is not bad for mobile phones.

[tkinnun0]

Are you sure you're not breaking an EULA somewhere by alluding to benchmarks comparing .NET to other languages?

Re:Java is not bad for mobile phones.

[Anonymous Coward]

Which isn't saying much since a native win32/GDI application will also run circles around a .NET/CLR application (I know it's an ancient and cumbersome API, but it has always been the top performer in usermode gui throughput and latency).

Re:Java is not bad for mobile phones.

[Anonymous Coward]

...but Java on cellphones is lean, mean, and it's already pretty much everywhere.

Why do you bother? The children here have no notion of what Java can do so they just parrot the other children with, "java is bad, m'kay".

Re:Java is not bad for mobile phones.

[Anonymous Coward]

[.NET] still runs circles around Java on the same hardware. I call bullshit. Every benchmark I've looked at puts them neck and neck. They both have their strengths, they both have their weaknesses.

Re:Java is not bad for mobile phones.

[johnsie]

I would have to agree... Java certainly works better in certain situations. Java itself was original designed for mobile devices. It's pretty silly for people to judge Java because a few hjava apps like Limewire are a wee bit slow to load. Modern phones can run java apps really quickly

Here is an idea for Google

[WindBourne]

Rather create just cell phones, how about creating a regular house phone that uses VOIP (not a big deal), but have the base be able to talk to the local network (not just in VOIP mode).

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.

Re:Here is an idea for Google

[alienw]

Now the remaining question: who wants this and why?

Re:Here is an idea for Google

[Anonymous Coward]

I think you just described the 1960s' concept of home computing. Join us in the 21st century, where we have these magical devices called PCs that can do all that and more.

Re:Here is an idea for Google

[ccguy]

Rather create just cell phones, how about creating a regular house phone that uses VOIP (not a big deal), but have the base be able to talk to the local network (not just in VOIP mode). Now, your phone is your true home assisitant.

I've read your post 3 times and I still don't know if you are serious :-)

Re:Here is an idea for Google

[WindBourne]

Well, we have a baby camera here with a portible monitor. Great thing going. In addition, I have recently put all the video/audeo in a cabinet and I use an IR extender to control them. I have several house lights on X10, as well as several outdoor outlets (holiday lighting), and then use this for xmas lighting indoors. We have comcast, but only 1 tv has digital. The others are analog. No guide there. Have to go to the computer to get it. All sorts of uses for this. Heck, average ppl are spending 200 for simply IR controller. That is ridiculus. For what I talking about, even if the phone costs 200, that is nothing. Esp. if the system is extensible (i.e. 1 or more phones per base leading to a phone per house member).

Re:Here is an idea for Google

[DdJ]

Isn't Android open source?

Isn't the iPhone SDK coming due out right around February? And doesn't that support the iPod Touch as well as the iPhone?

Seems to me that you could combine what Google and Apple are doing in the handset space right now to achieve pretty much what you want...

(By the way, I've already been doing some of the specific things you're talking about with web apps designed to render on phones. There's a Java API (other languages too) for X10, and so you can write web apps tuned for handhelds that when used control the lights in your house. Add a handheld-tuned Wiki, a computer-controlled IR emitter, et cetera, glued to your web server with APIs in your favorite web app language and you can already to most of it.)

Re:Here is an idea for Google

[Aladrin]

So you'd rather see them jury-rig a home phone to do complicated things than have them create an interface on a mobile platform (PDA, phone, etc) that could do it much easier and visually, instead of having the user constantly listen to prompts and/or memorize button presses?

No thanks. I'd much rather see the same hooked up to a phone with a decent-sized screen (the iPhone comes to mind, even though I don't own one) and be able to control it like that. Maybe the Neo1973 ... Since OpenMoko is open source, it's probably not that hard to add this stuff to it, assuming most of it exists already and just needs to be modified for mobile use. In fact, I was just reading here yesterday that someone managed to use Bluetooth on a phone to track which housemate was where and great them when they enter, etc. I would love to have the house constantly adjust the lighting according to what room I'm in, which direction I'm walking, and what time of day it is.

Re:Here is an idea for Google

[WindBourne]

So you'd rather see them jury-rig a home phone to do complicated things than have them create an interface on a mobile platform (PDA, phone, etc) that could do it much easier and visually, instead of having the user constantly listen to prompts and/or memorize button presses?

Apparently, you have not looked over android yet. Short answer, they are targeting touch screens as well as old style. I would assume that most of the phones that will come from this will be iphone style. Me? I would rather see an iphone set-up. After all, if I am at home, and have need of a full keyboard, then I will simply use on of the systems.

Just out of curiosity, where did you read into the original post that you had to listen to prompts or deal soley with button presses?

Re:Here is an idea for Google

[senor_burt]

I'm doing most of this already, using a mashup of Asterisk (open source), Voxeo Prophecy (2-4 ports free CCXML/VXML ASR/TTS in English), Linksys web-cams, and the Insteon developer kit. It works with wireless PDAs which have SIP clients running on them, too. The cost was just in hardware.

Re:Here is an idea for Google

[nine-times]

This was part of the idea behind the UMPC. People didn't really buy it. I could see some sort of a universal home remote control being worthwhile, but only if my computers and appliances and stereo/TV all operated with some open standard that was easy to set up.

Re:Here is an idea for Google

[Aladrin]

" a regular house phone"

Wouldn't be much of a 'regular house phone'... or a regular -anything- phone... If it had an operating system and a touchscreen. That instantly blows it out of 'regular' price range of less than $100.

And if you're going to go that far, why would it -not- have cellphone abilities as well? Think of the iPhone without the cellular bit, but with a VOIP interface. Would it be popular at all? Hell no. It would be the laughing stock of the internet for years. $600+ and only remotely desirable to anyone who knows what SIP is.

The only way his proposal makes a bit of sense is if it's a cheap regular home phone.

Re:Here is an idea for Google

[WindBourne]

The cellphone electronics add $ to it, but contribute nothing. But later on, a cellphone type can be done.

The iPhone would be popular as a house phone if you have a common phone book, controller of the house, etc. Of course, if they are charing 600/phone then ppl are being ripped off. The reason that it is expensive is that Apple and ATT are making a killing on it.
The truth is, that phone as a wifi phone should cost less than 200.

Re:Here is an idea for Google

[MrLizardo]

So it's like a cell phone without the GSM hardware? With those functions it sounds pretty close to PDA hardware you want, and consumers as a whole have shown a complete lack of interest in that market segment. On the other hand, it also sounds a lot like Nokia's Internet Tablet series (770/N800/N810) which judging by the fact that they're still around suggests that Nokia thinks the market is there. The only problem is that what you want will probably cost more than a cell phone in up-front costs, both because it isn't subsidized by a carrier/longterm contract and because it's aimed at a smaller market.

Re:Here is an idea for Google

[MrLizardo]

The GSM chipset for the iPhone probably costs Apple $20 in bulk. The iPod Touch is the same hardware as the iPhone minus GSM, Bluetooth, and microphone/speaker and yet starts at $300. Maybe Apple (or someone else) could *build* what you want for $200, but it will definitely cost more after markup.

worth a try..

[abes]

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:

(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 .. it's on the side so it doesn't get in the way, but it's there if you want it).

(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 .. 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.

(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?

Re:worth a try..

[radimvice]

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

Re:worth a try..

[eric2hill]

(4) I have an iPhone. I'm waiting for the iPhone SDK to be released .. 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. I've had a much better GUI design experience after switching to JFormDesigner. It does a spectacular job of making all the layout managers completely intuitive. The only other GUI designer that even came close to it was the Delphi/C++Builder designer, but it was still a distant second place.

It's paid for itself many times over in saved headaches and time.

Re:worth a try..

[edxwelch]

(1) It doesn't come with java libraries, they have written their own framework. It pretty big though... I count 2000 classes.

(2) You need a bit of patience to learn eclipse. Don't try to learn it without reading the tutorial. Once you get over the learning curve you probaly will like it.

(3) Yeah, that annoys me too, but only minor annoyance.

Re:worth a try..

[abes]

(1) Yes, Java is a standard. Yes, it's part of Google's repertoire. But it doesn't mean it's the best selection (nor does it mean it's a bad one). I would point out that currently most mobile platforms aren't very good. Does this reflect on Java, the companies, or the market?

Flash is also a widely used platform, but I really wouldn't ever endorse it for anything besides making banner ads involving monkeys getting punched.

(2) Since they are going with Java, it does make sense to go with those technologies. It was more a lament on my part that that was the case. I know, some people really love those environments. And I'm happy for you. I have the personal preference not to (just as I really despise Adobe's Flash environment), and am saddened when I have to use them.

(4) This is a valid point. But I think part of the iPhone vs. Everyone Else fight will boil down to which platform is easier to code for, and which will allow for better environments. For example, if you look through the libraries for the iPhone, there are libraries specifically for gesture support. This means that with the SDK, you'll easily be able to add in things like thing pinch zooming.

If either phone has a large enough percept of apps that are particularly slow, kludgy to use, or generally badly designed, that will reflect poorly on the phone as a whole.

I know many Java enthusiasts say that: (a) Java is much faster nowadays, and (b) slow Java apps are written by bad coders. From personal experience, I've come across many slow Java apps. Maybe they're all written by bad coders. Maybe that Java as a language is great, but it's just that AWT and Swing suck. I don't know.

But, if phones running many processes at the same time (not just a single Java game running in the foreground) and users notice large latencies, then as a platform it's dead. iPhone wins.

If it allows fast development, can match the interface provided by the iPhone (doesn't need to be the same, but as friendly to use), then it wins by the simple fact that there are many more programmers who know Java.

Re:worth a try..

[Anonymous Coward]

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.

OpenMoko also supports many different phones, including phones I can buy and install OpenMoko on today. (The Neo1973 dev phone is available now, and the production phone will ship next month.)

iPhone has a phone now, and an SDK at some point in the future. Android has an SDK now, and a phone at some point in the future. OpenMoko has hardware and software to play with today. As a developer and user, I know which is most useful to me.

Re:worth a try..

[Anonymous Coward]

Your name and URL are already attached to every message so you don't have to type them again in the body of your message. (Especially if your motivation is some kind of SEO rather than simple oversight.)

Re:worth a try..

[recharged95]

try JDeveloper/JBuilder, it's more intuitive IMO--I'm currently getting the SDK up and running on it and so far so good.

Re:worth a try..

[Andy Dodd]

" (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."
It's the standard for cripplephone development, not smartphones.

Look at the hardware that's going to be supporting Android - not cripplephones. Java is a non-starter in that market segment. Windows Mobile and Symbian (which dominate in that area, with iPhone being the only other player) are almost 100% native development.

Re:worth a try..

[Anonymous Coward]

iPhone is a single phone. Android will support a whole platform of upcoming phones.

Yes, and they will all CallForSure.

ZOMG!

[0xdeadbeef]

It's a Cylon!

I demand that henceforth we all refer to the runtime as the Dalek VM.

Re:ZOMG!

[satoshi1]

Would it then be appropriate to call the antivirus "The Doctor"?

How will Google make money on this?

[bogaboga]

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.

Re:How will Google make money on this?

[nine-times]

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.

Re:How will Google make money on this?

[diegocgteleline.es]

I don't think they plan to make money from this, it just looks a way to avoid Microsoft doing in cellphones what it did in desktops.

Re:How will Google make money on this?

[cornelio]

Really simple: the more people who surf the web, (i.e. the more page views that occur) the more money Google makes. Right now a very small minority of mobile phone users access the internet. If Google can change that, they win, and disproportionately relative to any other web businesses.

Re:How will Google make money on this?

[hypnagogue]

Just a hint from the API: Google Maps is integrated into the framework. Thus, location-based services developed on this platform will use Google. This is no small thing -- look at the Google Maps mashups of the last several years.

As a user of Google Maps on Windows Mobile, I can tell you that the only thing broken about it is Windows Mobile. Amazing operating system, assuming you adopt the "why the heck did it just do that?" definition of "amazing". (e.g. wakes from hibernation to display the "low battery" notification)

Re:How will Google make money on this?

[Lord Ender]

It's more than that. Google makes money by gathering information about you based on your searches and email contents, then sending that info to advertisers. A Google phone could do both of those things, but could ALSO target ads to you based on your GPS coordinates!

For example, if your search history included something like "taco bell nutrition information," and you were walking past a Taco Bell, I'm sure Pepsi Co would gladly pay Google some cash to have your phone pop up the message "try our new Grande Chuldita Supreme! Just across the street and to the right! Stop by in the next 10 minutes and receive 50 cents off!"

Re:How will Google make money on this?

[bigjocker]

It's really simple. They own the 'Android' name. If you are a handset manufacturer and want to jump in the Android bandwagon, you will have to pay google (more likely you will have to pay for each phone delivered with the Android label (and google label, they'll want to put that too)).

Owning the platform (it's free, so you have a license to do almost anything, but impersonate google as the creator) gives them a lot of power. 10MM USD is pocket change compared with the publicity and the amount of great applications that will surface for the platform.

Re:How will Google make money on this?

[SuperQ]

WTF are you talking about. I don't think Google sends your information to advertisers. Sure they do keyword matching to give you ads that make sense... but no part of that is "sending that info to advertisers."

Re:How will Google make money on this?

[Lord Ender]

Hm? Of course they send money to advertisers. "439 people searched for the phrase 'barbie doll' and we showed your add to all of them," and I'm sure it gets more detailed than that.

$10E7 ?

[Tumbleweed]

Clearly I've been using Bittorrent to watch too much tv; I first read that subject as Season 1, Episode 7. :)

WebKit?

[DdJ]

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...

Re:WebKit?

[ianare]

It's going to get less and less safe for web developers to ignore the standards and only code for IE... There, fixed.

Re:WebKit?

[nobodyman]

Now they can ignore the standards and only code for webkit now!

Re:WebKit?

[nine-times]

Yeah, I'm surprised there hasn't been a bigger deal made out of that. It's not too surprising, since Apple and Google have been partnering up quite a lot lately. However, Google is also the big sponsor for Firefox. I guess Firefox wasn't mobile-ready yet.

Re:WebKit?

[DaggertipX]

Which would still be safer, as unlike IE's team - the webkit developers have gone to the trouble of even reading the standards docs.

(I kid, I kid. I don't blame Microsofts developers, I'm firmly convinced it's their 1863454 levels of management that bungle most of their projects.)

Re:WebKit?

[Anonymous Coward]

Now only if Gnome would drop Gecko in favor of WebKit. Imagine Epiphany with fully native controls (yes, I've used current FF3 builds, it still has a way to go), good font rendering, no freezing when pages are loading, etc. That would be awesome.

Re:WebKit?

[Anonymous Coward]

Yeah, I'm surprised there hasn't been a bigger deal made out of that. It's not too surprising, since Apple and Google have been partnering up quite a lot lately. However, Google is also the big sponsor for Firefox. I guess Firefox wasn't mobile-ready yet. It makes complete sense. Take a look at the source code for WebKit. Then take a look at Gecko (Firefox's rendering engine). WebKit is much cleaner and also runs faster. Mozilla's codebase is a huge bloated mess. WebKit FTW!

Re:WebKit?

[m2943]

The vast majority of smart phones in the world run WebKit... because it's Nokia's standard browser, and has been for several years.

Re:WebKit?

[Anonymous Coward]

It is management getting in the way, but it's just them bumbling through their Embrace Extend Extinguish model. It might work in their closed shop of hate, but never held much chance of working on the net as a whole.

Re:WebKit?

[Anonymous Coward]

Gecko won't even be able to compete until FF4. The only reason to its success is that IE was so much worse. Firefox is the second worst browser in many ways. Yet anyone concerned about web standards does rely on it because of it's market share. I'm using it right now.

Re:WebKit?

[nine-times]

Yeah, it makes sense, and I'm not surprised that they made that choice. I'm just surprised that no one has made a bigger deal of it. In one of the videos, the guy from Google says Webkit is the "standard". It seems like a pretty big endorsement of Apple's browser, coming from the biggest supporter of Mozilla's browser. It's a bit of a PR bitchslap, if you ask me.

Re:WebKit?

[sznupi]

More like "...only code for IE and Gecko"?

At least that's the impression I get (not using any of the above)

Re:WebKit?

[makapuf]

the one that's shared by Safari (and OmniWeb) on the desktop And Konqueror, damnit! IIRC, They wrote this code in the first place, please credit them at least here !

Re:WebKit?

[octopus72]

Firefox' extension system is a key to it's success, not the Gecko engine (although Webkit didn't even exist when it started gaining market share). FF for desktop, Webkit for mobiles seems to be a future direction (with a mandatory IE).

One thing is for certain...

[SlipperHat]

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).

Re:One thing is for certain...

[Anonymous Coward]

Imagine how stealthy the pedo's could become... little miss is at 12a x street... The potential risk in that kind of application is tremendously dangerous.

So, were all the nay-sayers now?

[SmallFurryCreature]

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!

Re:So, were all the nay-sayers now?

[legirons]

"So, were all the nay-sayers now?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."

OpenMoko mailing lists have average 50 posts per day (and has been that way for months). They've released real hardware. There are hundreds of youtube videos demonstrating OpenMoko interface, and hundreds of people hacking on the phone. It's the only phone where hackers are tolerated, let alone welcomed.

And the biggest tech company in the world tries to compete, they come up with this? No hardware, no software, no vision, no freedom?

That marketing budget could have gone a long way towards promoting a real project.

Re:So, were all the nay-sayers now?

[Anonymous Coward]

I was one of the nay-sayers. Sorry I was wrong. Time to buy lots and lots of Google stocks now!

Re:So, were all the nay-sayers now?

[Mdentari]

LOL. So funny. I'm sure someone will say it's vapor ware and that Google will go out of business soon or the hardware will never arrive leaving us holding the bag. Google has done a great job delivering the SDK and giving developers a chance to get into active development. I love to bet the naysayers some big money that Google will deliver, but their all talk and will not do it... as usual. I for one have started to work with the SDK. I may not develop anything worthwhile but know that if I do it will have a future.

Tivoization

[Microlith]

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?

Re:Tivoization

[johnsie]

If they are releasing the source code for the O/S then you can pretty much do whatever you want with it within reason. Java has been chosen for the standard apps because it's more suitable for portable devices. Nearly all portable devices use a form of java for this reason. Since it's a Linux based system and Linux is modular you can assume that C++ will work providing you have the right hardware capabilities and the right software and libraries installed.

Random?

[Duncan3]

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.

Re:Random?

[dyefade]

A lot of Google products have ads, and yet I've never wanted to avoid Google because of it so far. What makes you think this new phone will be worse?

Re:Random?

[hitchhacker]

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

Re:Random?

[CdBee]

Also, Microsoft's online Office offering (which required office installed..) doesnt work on any portable device. Google wants an open rendering engine on mobile browsers so it can more easily code their profit-making web applications to run on it. Think of Android as a driver for Google Apps for your Domain

Re:Random?

[Etyenne]

The nice thing about Free/Libre Open-Source Software is that you can modify it, if it does not behave the way you want. Assuming Android actually pop an ad at random (I seriously doubt it), you are welcome to remove the ad-poping bit.

Gaaaah, I have been trolled again.

Re:Random?

[Ginsu2000]

Unfortunate but true. Did they say 'interpreted' - I'm getting a sinking feeling. Hope it has nothing to do with cRapscript! I left the company because my ideas were misappropriated. I was platform agnostic. Wakeup and smell the coffee google. You can do better.

Re:Random?

[Anonymous Coward]

From the Android SDK:

"There is no requirement that any given phone include any Google software, or even be associated with Google at all."

Webkit as a powerful new platform

[605dave]

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.

Re:Webkit as a powerful new platform

[Tickletaint]

Actually, Google is traditionally associated with not sucking. Gecko sucks utterly, being rather behind WebKit in support for CSS properties and attributes; further, rather than serve to enhance the rendering engine, Firefox et al. from the Mozilla project shit all over usability. What's surprising is that you're only now beginning to realize this. Are you a PC user, by any chance?

Android: An indie game developers' paradise?

[gjuggler]

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

Re:Android: An indie game developers' paradise?

[Anonymous Coward]

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.

Re:Android: An indie game developers' paradise?

[bjourne]

This is what excites me the most about Android: OpenGL ES compatible Graphics API. Oh please. Handsets have been shipping with Mobile 3D Graphics for years (a 3d scene graph FYI). It is standardized as JSR-184 and is pretty much ubiquitous on even midrange phones. Earlier than that, you had the Mascot Capsule which is still the fastest J2ME 3D API for low end devices. Now there is also the OpenGL ES bindings (JSR-239) which will be included in many phones being released this Christmas and spring.

It is cool that Google is making a gPhone, but really, they aren't breaking any new ground here. Google's attempt to create a totally new embedded Java ecosystem also seems a little misguided. There is already the MIDP and CLDC platforms which are open, standardized and implemented on a huge number of devices. gPhone apparently has neither which will make porting apps to it a huge pain in the ass for developers. There is a reason why other handset manufacturers tries to stick with the established standards instead of doing everything their own way.

So... Java... standard APIs... WebKit...

[DdJ]

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.

Re:So... Java... standard APIs... WebKit...

[jrumney]

Maybe, if they release the source to their Java based but non-standard Dalvik VM under an open license.

Re:So... Java... standard APIs... WebKit...

[DdJ]

Maybe, if they release the source to their Java based but non-standard Dalvik VM under an open license.

Is the Apache license good enough?

http://www.betaversion.org/~stefano/linotype/news/110/

Re:So... Java... standard APIs... WebKit...

[jrumney]

According to some guy's blog, Dalvik is going to be released under the APL. But Dalvik is released now, and there is no sign of any source, and a no-reverse-engineering license to go with it. I haven't seen any definite commitment from Google to release the Dalvik VM under the APL or any other open source license. What they did say is that they will release some APIs under an Apache license, but if they don't release the VM which is required to run them, they might as well be closed.

Re:So... Java... standard APIs... WebKit...

[howardck]

I thought the iPhone didn't support Java, by decree of Steve. I heard that a couple months ago when the phone first came out. Did something change, or was that early information incorrect?

Great for operators

[Anonymous Coward]

The diagram looks like the one of the Access Linux Platform

http://www.access-company.com/PDF/ALP2007_08.pdf

It looks nice. I think the operators will like it. An open platform, cheap, with standardized tools. And Google has potential for big bandwith consumption: search, maps, video, desktop...

This cannot be true!

[sribe]

The android SDK has been released...

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.

Re:This cannot be true!

[Creepy]

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.

Re:This cannot be true!

[StrawberryFrog]

No it hasn't. THAT'S IMPOSSIBLE! IT'S JUST VAPORWARE

if you can buy or otherwise get a phone running Android, and the phone can make calls, then it's not vapour. Do we have that?

Re:This cannot be true!

[0xdeadbeef]

No, he wasn't, and repeating spin doesn't make it come true.

Ballmer comment?

[ikirudennis]

So does Steve Ballmer think this is still just a "press release?"

Re:Ballmer comment?

[Anonymous Coward]

I can almost hear the gentle whisper of chairs hurtling through the air.

included libraries

[doti]

FreeType, OpenGL, SQL Lite No SDL?

Re:included libraries

[hitchhacker]

FreeType, OpenGL, SQL Lite No SDL? They must have at least SDL because they showed off Quake running on it. The most popular port of Quake on Linux uses SDL. I'm sure they left out many other libs that it comes with too.

-metric

Re:included libraries

[hitchhacker]

Now that I think about it, that was completely irrational. It's not like Android comes with Quake.. If they got Quake on it, then they can get SDL on it... or statically link SDL with Quake.

-metric

Re:included libraries

[Metaphorically]

SDL is included in the android emulator source that I'm looking at.

Prototype in the vids

[Anonymous Coward]

Adding to the hardware questions and rumours: Does anybody recognize the prototypes in the google videos? Are these custom built, or regular cell phones which just run Android pre-pre-alpha (or mock ups)?

not using jazelle?

[edxwelch]

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)

SQL Lite ?

[BuR4N]

I belive that should be SQLite (www.SQLite.org)

Re:SQL Lite ?

[ciw42]

Nope. It's definitely just "SQLite". They've never done an OpenOffice.org and incorporated the .org bit as part of the name.

"SkyNet" Developers Kit

[peter303]

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.

I speak for all of us when I say

[Provocateur]

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.

Correction

[Osvaldo Doederlein]

"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. ;-)

I, for one, welcome our new Android overlords...

[Anonymous Coward]

(:]

I, for one, welcome our new Android overlords!

android's dungeon

[Anonymous Coward]

What, nobody has made the simpon's reference yet?

Not very exciting

[Goaway]

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.

Re:Not very exciting

[Ma8thew]

Watch the video. The basic interface of the OS is demoed, and I'm more excited by it than the iPhone. The whole UI looks slick and well thought out, no wait cursors, and simple, functional icons. The best thing? This will be available for manufacturers to put on any phone, instead of just one.

Re:Not very exciting

[ciw42]

By including OpenGL ES in the box as it were, you open up a whole world of nice potential interface designs.

Re:Not very exciting

[Goaway]

The last thing you want is a "whole world of potential interface designs", because that just means companies that won't put the effort into proper interface design will make more horrible interfaces, but now they'll use fancy 3d effects.

Re:Not very exciting

[Anonymous Coward]

Umm... it has OpenGL.

Feel free to knock us out with your s00p3r l33t UI design skilz.

Re:Not very exciting

[Goaway]

Thanks for posting the exact same thing that was already posted, and showing a complete lack of understanding of the entire concept of interface design.

Re:Not very exciting

[netsavior]

Apple is breaking new ground, but this seems planted squarely in the past.
Name one thing an iPhone does that my 3 year old treo does not do. You can't, because the iPhone has prettier, smoother, more friendly interface that does LESS than 3 or even 5 year old phones.

I am not arguing that android is revolutionary, but I am arguing that the iPhone is not.

Re:Not very exciting

[Goaway]

Thanks ever so much for the feature-checklist defense. That's the exact thing that is holding phone development back - the inability to see past the feature list that says "MP3 player!" and realize that that MP3 player is clumsy and unusable.

The iPhone is breaking new ground exactly because it is prettier, smoother and more friendly. That is what I was talking about from the start.

Re:Not very exciting

[netsavior]

I guess I'm just bitter because the iPhone does not have instant messaging or a fast way to type, the only thing I have really used a phone for in the last 5 years. So it seems like a step back, which everyone else is calling revolutionary. Since IM has always been the "killer app" on cellphones for me, the iPhone is not compatible with my ideal. Purchasing music and cute animations were never on my radar for a cellphone.

OMG! Sergei Brin's Outfit! Long Slv T-shirts FTW!

[TheNarrator]

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 :).

Java? what about C/C++?

[ardiri]

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

Re:Java? what about C/C++?

[larry bagina]

the iPhone/iPod Touch SDK will let you write apps in C/C++/objective C.

Re:Java? what about C/C++?

[ardiri]

the iPhone/iPod Touch SDK will let you write apps in C/C++/objective C.
yes, i already have support for the iPhone/iPod Touch (one of those users apple hates right now). the unofficial SDK is even hosted on google groups. now, android may create devices which are only for android, i need C/C++ SDK to support these devices. the other devices are already handled.

Ooops

[Andy Dodd]

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.

Re:Ooops

[bheer]

On the desktop (excluding OSX since I've not used Java much on it), I agree with you. But phones with good, fast Java support (and good Java apps, some of them from Google) do exist. And if the phone starts the JVM at startup (if it can be done without impacting battery life, of course), then you won't even notice the 'hit' as the JVM starts.

Re:Ooops

[LWATCDR]

Using Java doesn't cause lock you into a single language. The JVM could be targeted by any number of languages all you need is a compiler that will output the correct bytecode.
Going with a JVM is the only logical way to go with this kind of system. You don't want the end user to have to compile the application for their phone and yow don't want to have recompile a for each new cell phone that hits the market.

Re:Ooops

[m2943]

unfortunately Android apps are indeed intended to be written in Java. (as opposed to, say, something like a C/C++ toolkit with bindings

It seems like a little of both: they are intended to be written in Java, but all the important toolkits seem to be callable from C/C++ (the green stuff). So, there is hope.

Re:Ooops

[Anonymous Coward]

I personally DO_NOT_WANT native assembly/c code mucking around with the private information on my cellphone, secretly making expensive calls, running some weird new uber-connected botnet. Let all this widget application code stay in the sandbox WHERE IT BELONGS.

And seriously, go away. You sound like the kind of developer that would allow buffer overflow exploits and such for the sake of raw speed. And then open source your nigh impossible to compile code, expecting others to fix it.

Video, audio, and decompression belongs in supplied libraries anyways.

Re:Ooops

[stoanhart]

While I usually don't like Java apps very much, I think it makes sense in this case for two reasons:

1) Most mobile developers already use Java, as it is the most prevalent mobile language (Java ME). I have dozens of games and apps on my cell phone, and they are all written in Java.

2) While I have been trying to find out more info on what CPU this custom Java VM is for, I will assume it is ARM. There is a good video that explains to android software stack here: http://www.youtube.com/watch?v=Mm6Ju0xhUW8

Basically, you have the linux kernel. On top of that, you have the core operating system libraries, like graphics (2D, 3D compositing), data storage (SQLite), etc. These are all written in C/C++. This is where the heavy lifing occurs. Finally, you have the custom Java VM and all the libraries you get to work with. Most of these libraries are just wrappers to the C libraries. So, you get the speed and memory size of a lower level language with all the simplicity of Java. And, like they mentioned, this VM is customized for mobile applications, and presumably for this software stack in particular.

I think this looks like a fantastic platform to work with. Lots of power, lots of flexibility, and extremely simple to get going. Check out all 3 parts of the video I linked to above. There is even a video of android running quake somewhere!

Re:Ooops

[smittyoneeach]

Using Java doesn't cause lock you into a single language.

No, but the hardware platform might mean that you really don't want to get too weird running other stuff.
a) you have smaller chip/ram/drive resources, and
b) you don't have the user-tolerance for 'breakage' that you do on the desktop.

Re:Ooops

[LWATCDR]

A basic, ruby, python, fortran, pascal, or c compiler doesn't have to require any more resources than writing in java. The compiler just generates java byte code instead of the native instruction set for the CPU.
This website lists a lot of JVM languages http://www.robert-tolksdorf.de/vmlanguages.html

Re:Ooops

[smittyoneeach]

Noted, but the space taken up by runtime libraries associated with basic, ruby, python, fortran, pascal, or c is greater than 0, no?

Re:Ooops

[Andy Dodd]

"Using Java doesn't cause lock you into a single language. The JVM could be targeted by any number of languages all you need is a compiler that will output the correct bytecode."
Could be, but please name a robust well-supported compiler/library environment that works well.

"Going with a JVM is the only logical way to go with this kind of system. You don't want the end user to have to compile the application for their phone and yow don't want to have recompile a for each new cell phone that hits the market."
For smartphones, the CPU choices are typically Qualcomm MSM, TI OMAP, or Marvell PXA.

Oh wait, they're all ARM devices! Windows Mobile does just fine using native code. I was hoping that this would have the native code performance advantages of Windows Mobile, but with an improved UI, open architecture, and speed improvements.

Instead, it will either be limited to low-end cripplephones, will turn good hardware into a low-end cripplephone, and no matter what has zero chance of outperforming Windows Mobile in terms of UI responsiveness and such. (Which is sad because that should be easy to do, it's just not possible with the bloated horse-designed-by-committed nightmare known as Java.)

Phones are low-power, low-speed, low-memory devices, even high end smartphones. To make full use of such devices, developers need access down to the hardware level. If you're stuck in a JVM sandbox, many of the tweaks and hacks and nifty tricks available to developers of native code (see, for example, CellID-based profile switchers for Windows Mobile) won't be accessible.

Re:Ooops

[Andy Dodd]

"1) Most mobile developers already use Java, as it is the most prevalent mobile language (Java ME). I have dozens of games and apps on my cell phone, and they are all written in Java."
Depends on what the mobile target is. No one targeting high-end smartphones uses Java. I have dozens of apps on my phone, and ONE (Gmail Mobile) is written in Java, and will be replaced with a native app (WebIS FlexMail) quite soon. Two of the ones I use the most (TomTom Navigator 6 and TCPMP) could not possibly ever be written in Java and retain acceptable performance.

Re:Ooops

[AVee]

Java utterly failed in the "Write once, run everywhere" arena As opposed to what? I really like to know about this language which does allow me to write something once and then run it anywhere, because being able to run your app on just 95% of all mobile phones is annoying sometimes. There sure is loads of room for improvement, but until someone gives me something better, Java is the most succesfull attempt so far. That's not "utterly failed", thats better then anything else. But feel free to try and do a better job.

Re:Ooops

[LWATCDR]

Not a lot more. You would still code to the API you would need the basic IO library and of course any utility libraries that the programmer adds for the most part you would be coding to the API. Okay coding in C++ and using STL may put a bit of a burden on you but probably not as much you would would think.

Re:Ooops

[LWATCDR]

And the Blackberry uses Java and works just fine. In fact I would bet that most people would claim that it is a better smartphone than most Mindows Mobile devices. And then you have the example of Palm. They are still living with emulation the 68000.dragonball on the ARM,

"Instead, it will either be limited to low-end cripplephones, will turn good hardware into a low-end cripplephone, and no matter what has zero chance of outperforming Windows Mobile in terms of UI responsiveness and such. (Which is sad because that should be easy to do, it's just not possible with the bloated horse-designed-by-committed nightmare known as Java.)
"
I would say the BlackBerry blows that away.

"Oh wait, they're all ARM devices! Windows Mobile does just fine using native code. I was hoping that this would have the native code performance advantages of Windows Mobile, but with an improved UI, open architecture, and speed improvements."

And the Palm shows that could be a problem in the future.

Re:Ooops

[Andy Dodd]

"And the Blackberry uses Java and works just fine. In fact I would bet that most people would claim that it is a better smartphone than most Mindows Mobile devices. And then you have the example of Palm. They are still living with emulation the 68000.dragonball on the ARM,"
In the case of still living with m68k - Palm made migrating to native ARM code a NIGHTMARE. There is no way to write a 100% native PalmOS ARM app, and linking in "ARMlets" is an unholy nightmare.

BlackBerries do a few things extremely well. (Email, calendar, and... That's about it.) They're not very expandable/flexible.

""Oh wait, they're all ARM devices! Windows Mobile does just fine using native code. I was hoping that this would have the native code performance advantages of Windows Mobile, but with an improved UI, open architecture, and speed improvements."

And the Palm shows that could be a problem in the future."
It's only a problem if you're 100% stupid and make it impossible to run 100% native code on the new platform, and make it an unholy nightmare to even make parts of a program native.

Apple, on the other hand, shows that it's not difficult at all to maintain backwards compatibility with old apps (Palm did that) AND allow new apps to be written in fully native code for the new platform (Palm bombed that one royally. PalmOS 5 for ARM devices has been out for years and writing native ARM code is still hell.)

Re:Ooops

[LWATCDR]

"BlackBerries do a few things extremely well. (Email, calendar, and... That's about it.) They're not very expandable/flexible."
Really?
Well here are two navigation programs for the Blackberry
http://na.blackberry.com/eng/builtforblackberry/navigation.jsp.
Here is a collection of software for the Blackberry. http://na.blackberry.com/eng/builtforblackberry/
Here is a list of Favorite apps for the Blackberry from blackberry users.
http://www.blackberryforums.com/aftermarket-software/316-updated-blackberry-killer-software-utilities-thread.html
And this is a site for Blackberry Freeware.
http://www.blackberryfreeware.com/
There may be more software for Windows Mobile but the Blackberry seems to do a lot more than just Email and Calendering.
So as you can see using Java doesn't have to cause the downside that claim it does while offering great flexibility in the underlining CPU that native code just will not provide. Seems like Microsoft might even agree. http://msdn2.microsoft.com/en-us/netframework/default.aspx Seems like they are moving to .net for mobile devices.

Re:Ooops

[Andy Dodd]

"Seems like Microsoft might even agree. http://msdn2.microsoft.com/en-us/netframework/default.aspx [microsoft.com] Seems like they are moving to .net for mobile devices."
I'm fairly certain .NET CF is just a library framework - the code itself is still native.

Native or not, the framework itself is generally considered to automatically cause any app built against it to be bloatware. The most common feature request given to developers of .NET apps is "Please rewrite without .NET - uses too much RAM and flash storage." If it does actually use interpreted bytecode instead of native code, it's yet another example of why native code is the way to go unless you want to write a halfassed quick-and-dirty application and don't care at all about efficient use of a mobile device's limited resources.

It is given as an option for developers who want to write "quick and dirty" apps for Windows Mobile, and is SEVERELY limited in its capabilities on Windows Mobile devices. For example, it's either not possible or extremely difficult to write a Today screen plugin using .NET CF.

Re:Ooops

[LWATCDR]

I am no fan of .net. Heck I have to admit that I haven't written anything in Mono. I do use some apps that are written in Mono and they do seem to work just fine. Java I have used. The programs I wrote where not half assed. One could really only be written in Java. One is used to manage our tech support calls with Postgresql as the back end I use C++ for embedded development. I am using Linux for the OS and I have total control over the hardware that it will run on. For that Application I really need the speed and low level access of C++. I use Eclipse.org for my IDE. Eclipse.org is a Java application and it runs really well on my X23800 Linux box. But for applications that run on a phone I can see clear benefits to using a VM based language and Java is a pretty good language.
Before you blast Java maybe you should fire up the Android SDK and emulator and see what the performance is like? Take a look at all the software available for the Blackberry. It isn't the limited device that you think it is and is loved by it's users. It also seems to be pretty dang stable.

First Post?

[dfj225]

First post from the Android emulator? Its slow as balls, btw...

Re:First Post?

[Anonymous Coward]

Its slow as balls, btw... Duh, it's Java based. Man it is slow, drags my Opteron 250 machine to its knees just to open the Slashdot page.

I know Java is widely deployed on phones but it shouldn't be. I'm sick of slow-ass crap. Bloated software is everywhere, on the PC, on your phone, etc. The Java just makes it much worse than it should be. We could have so much more functional and fast stuff if it wasn't for crap like Java.

Plus Java's API's are an annoying convoluted mess. It's complicated to do simple stuff and you spend more than half your time trying to figure out the API when you could be developing. Object-oriented in the extreme is a very bad design. Everything in moderation you dolts.

Re:First Post?

[NusEnFleur]

I's not slow because it's java based. AFAIK It's running a arm cpu emulator (apparently qemu) which then runs a VM.

If you want to know what slow means you should definitely download the latest series 60 emulator from nokia. I develop J2ME apps for a living and I found this emulator to be pretty fast compared to other smartphones emulators I have tried (Nokia, Blackberry, Windows Mobile ones).

Re:First Post?

[Anonymous Coward]

Duh, it's Java based. Man it is slow, drags my Opteron 250 machine to its knees just to open the Slashdot page. Duh, it's running in an emulator.

We are doing just that...

[Wonderkid]

...to be kept informed, hit owonder.com/contact and submit the form.

Dollars?

[nicklott]

$10 million in prizes I hope that's Canadian dollars, US might not cover your ADSL charges...

Android Treo?

[Doc Ruby]

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?

You Got It

[Doc Ruby]

Oh, you mean LinuxMCE with Cisco 7970 phones.

To complete your dream, make the LMCE Orbiter run on an Android mobile phone.

In terms of open phones, the big question is ...

[TihSon]

... 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?

Re:OMG! Sergei Brin's Outfit! Long Slv T-shirts FT

[jamesmrankinjr]

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

Highly underwhelmed at the Telephony API

[Anonymous Coward]

call, dial and endCall? WTF? What about putting a call on hold, dialing DTMFs, entering Data mode? Compared the the MS RIL.h, this API is a joke (and btw I hate MS and their top secret RIL APIs).

It has a LONG way to go before you'll see anything remotely useful for this phone platform.

Support

[smitth1276]

B2B support? Consulting? Etc.?

Just Danger on Linux?

[Dahamma]

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...

Great news!

[dautelle]

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 :)

Re:In terms of open phones, the big question is ..

[argent]

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.

Desktop

[hey]

Looks like a reasonable OS for a desktop.
Would be nice to be rid of X.

Re:Desktop

[Anonymous Coward]

Why? If you hate X so much that you want to be "rid" of it, why not just use Windows or Linux?

Re:Desktop

[hey]

I meant it would be nice to be rid of X Windows. Sorry bout that.

assumptions

[m2943]

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.

Re:assumptions

[Metaphorically]

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.
They do this trick in Java Micro Edition where you wrote all your code as Java but you have the option of including a compiled version of the code. You can compile some, all, or none of your code. So the whole thing about JIT compiling becomes a non-issue. Of course, so does the "write once, run anywhere" lie. I have nothing against Java as a language, I just think it's silly the way it's packaged and marketed.

I also refuse to miss out on trying new stuff just because that right now it uses some bits I don't like. So I just installed and tried out Android with the emulator. Pretty neat stuff, hope they get some diversity in the languages.

Re:assumptions

[m2943]

but you have the option of including a compiled version of the code.

Unfortunately, that's only half of the problem. The other is that the Java language just has some performance bottlenecks.

So I just installed and tried out Android with the emulator. Pretty neat stuff, hope they get some diversity in the languages.

Same here.

Personally, I wish they just fix Java by adding a few C#-like extensions to it (backwards compatible).

db4o already runs OK, Android GUI is XML

[Carl Rosenberger]

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.

Re:db4o already runs OK, Android GUI is XML

[SavedLinuXgeeK]

db4o runs on Android out-of-the-boy.
I tried just now on the emulator.
Holy crap. I guess androids have to come from somewhere, but ewwww...

The iPhone isn't in the same league.

[argent]

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.

yes, but..

[CdBee]

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

Android + 700 mhz spectrum

[ozgood]

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?

nonsense

[CdBee]

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'll bite ;)

[siddesu]

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 ;)

Video of Android in action

[Anonymous Coward]

There's also a video of Android running on two prototype devices. OpenGL, integration of Maps, notifications, touch-screen functionality, cover flow view, and Sergey's pompadour are all on display.

Re:Video of Android in action

[LingNoi]

Either that or a monitor shaped phone connected to a pc...

Re:In terms of open phones, the big question is ..

[ciw42]

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.

Platform open to malicious code?

[sichbo]

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 ..

Still not better than Symbian or WM SDK

[S3D]

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.

Re:Still not better than Symbian or WM SDK

[octopus72]

I think it's still not impossible to develop C++ programs for it, if full stack will be open source (and if hardware won't block unsigned execution of core components). I guess a system daemon and C++ bindings could be written to allow pure C++ executables to bind over IPC mechanism to Java framework and cooperate with the Android system (same as Java app). It remains to be seen if Google even wants to allow that, though.

However I'm almost sure that vendors, maybe carriers will be putting closed source core components inside, to block certain kinds of system usage (e.g. blobs that do (from-userspace) programming of wifi/gsm/3D/DRM etc. hardware). Luckily GPLv2 prevents doing that to Linux kernel, so reverse engineering could be possible (unless devices would allow signed-only kernels to load).

Let's hope that we will be able to modify also non-Java Android components, like codec library (is that one even open source?).

Re:Still not better than Symbian or WM SDK

[IceFox]

In one of the videos they show Quake running so there must be some way to compile c/c++ code.

Re:In terms of open phones, the big question is ..

[LingNoi]

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.

Re:OMG! Sergei Brin's Outfit! Long Slv T-shirts FT

[Danny Rathjens]

"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. :)

Re:In terms of open phones, the big question is ..

[Danny Rathjens]

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.

Re:Posted from my Gphone

[Anonymous Coward]

/. is so popular, even the US Senate can't help itself.

Android for the iPhone

[jmil]

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.

Re:OMG! Sergei Brin's Outfit! Long Slv T-shirts FT

[Anonymous Coward]

He probably has a personal shirt wrinkler on staff who works for hours to give his shirts that perfect, geeky, slept-in look.

fuck eclipse & co

[Anonymous Coward]

another retarded SDK where I have to spend hours to figure out how to use it WITHOUT some pile of shit IDE. As if simply 'java' was not bad enough.

another one that wants to leave junk files all over the place. or wants to be run with administrator privileges (like the S60 SDK on Windows).

another one where you're simply NOT SUPPOSED to use your favorite version control system.

another one which is SPECIFICALLY designed for mouth-breathing script-monkeys, and deliberately hostile towards anybody else.

All 3 Android Videos

[HeaththeGreat]

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

Re:All 3 Android Videos

[AVee]

And it all seems to be about maps (e.g. about the data google doesn't put under an opensource license). Did anybody actually see a dialer application, you like what you get on a phone? And by the way, Opera's small screen rendering beats really beats being able to zoom in and out and (e.g. having to choose between not being able to read the whole scentence and being able to read half a scentence) when it comes to web usability.

Compatibility

[mandy2007]

What about the comptibility of the device?
http://www.oureasyshop.com/

Paranoid Android

[ItchyBob]

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.

Cool...

[Jaysyn]

... a press release with an API. Way to really put your foot in your mouth again Ballmer.

Two questions still unanswered

[efornara]

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.

X and native compilation

[Anonymous Coward]

What is native compilation good without having X? Obviously they go for a kind of specialized windowing system, or am I wrong? If so however, then you end up with the same as e.g. the original Sharp Zaurus ROM with Qt. Nice that you can write new apps. But you have to do it from scratch!!! Portability? Blah! What is that?!?

Re:In terms of open phones, the big question is ..

[Andy Dodd]

"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.

Symbian allows native development

[etinin]

What about Nokia phones? Most Nokia GSM phones run Symbian and everyone loves them because of their cool native apps... Portability is not a good thing and java is not a good thing, I'm not buying a phone running android because of these terrible news. Perhaps I should wait for Openmoko, QTopia or even buy something with Windows Mobile or Symbian that allows native applications.

Re:GOOG & the FOSS Community

[PropertyGuy]

The FAQs Google issued (via the Open Handset Alliance) on Android contain an interesting sale pitch related to Google's selection of the Apache license:

"The Apache license allows manufacturers and mobile operators to innovate . . . without the requirement to contribute these innovations back to the open source community. . . . [they] are protected from the 'viral infection' problem often associated with other licenses."

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"):

[A] copyleft license could potentially limit the evolution of the mobile software ecosystem by discouraging commercial development on top of the platform. Proprietary mobile software development companies that integrate Android into their technologies would have to dramatically change their business models if they aren't given the ability to keep their enhancements proprietary.

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.

Re:Android + 700 mhz spectrum - Tin Foil Cap

[jflo]

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?

Android Community Board

[Anonymous Coward]

Wan to grab the prize ??
Start learning to program Google-Android on our Tutorial-Board in a friendly Community-Environment.
We help on problems from HelloAndroid to LocationManagers ;)
Dive in: http://www.anddev.org/

See you soon,
plusminus