All about Android

More and more datapoints are pointing in favour of his “phase transition” thesis, that the smartphone market, as it gets more software-y, eventually becomes an emergent monopoly. Did you know, for instance, that Apple has a 70% share of contract sales in France? Seventy percent market share?! How do you break that?

If we’re going to avoid that fate elsewhere, we at least need Android to stop being entirely useless. There’s really nothing else. Here are a couple of judiciously chosen links that might help:

Boy Genius, king of the smartphone bloggers, enunciates the problem. He’s had enough of Google’s operating system and unloads a can of whup ass: “Android doesn’t make sense as a whole. It’s fragmented, poorly executed, the Android Market for apps is a mess, and developers still don’t care about it”.

In a similar vein, but more constructively, Silicon Valley VC and blogger Jean Louis Gassée also sees Google’s problem; it’s Linux strategy just isn’t working. It’s creating “Babelisation” instead. He thinks Android has to become more like Microsoft if it’s going to get anywhere. Is that a good thing?

Advertisements

Share this:

Related

36 thoughts on “All about Android”

This will be a bit technical.
Android in its current form has no chance to have the same quality applications like iPhone has. It is not just because of the fragmentation or the look, but the Android programming environment.
Roughly 8 years ago when the first programmable mobile phones were launched on the market, all of them supported Sun’s Java (first it was called J2ME, now the name is Java ME, i.e. mobile edition).
The Java applications were simple and slow. Simple because initial Java ME application programming interfaces (APIs) were very limited and slow because Java virtual machines that time were interpreted real-time by the CPU (which were clocked just around 40 MHz). Interpreted Java is roughly 10 times slower than native code (native code is compiled directly to the specific CPU, which is platform dependent).
During the years many new Java ME APIs were added to the stack, but even big vendors like Nokia used only a limited set of these APIs and the available APIs were different on each device. This was the cause of the big Java ME fragmentation.
Handset vendors supporting Java tried their best to improve speed: faster and faster CPUs were introduced (now they top around 500MHz), the efficiency of the Java engines (virtual machines or VMs) were increased a lot by using compiling VMs, which as their name states compile Java code to native code before or during execution.
However fragmentation was never really solved. Each vendor had their favorite Java APIs which each had different flavors. For example having the Multi Media API installed on the phone did not mean these phones supported the same media formats. No, the developers needed a trial and error approach, basically porting each application to several hundred different devices.
This was the time when Android was designed. The initial idea was to create a better Java environment, which is ultra portable using a single “perfect” API. As Google didn’t want to pay license fees for Sun (or any Java vendor), they did not license the Java name or one of the faster Java VMs. They brewed their own VM, called Dalvik, which happened to be a slow interpreted VM.
The timing was a disaster. Android was launched just after the market realized the powers of iPhone, which is a native platform. Apple actually forbids any interpreted code on their devices (not only Java, but also Adobe’s Flash in its interpreted form) in the sake of performance.
Due to all these, naively porting applications from iPhone to Android is simply impossible, because the performance sucks. As running anything more complex on Dalvik is prohibitively slow, the few developers building complex applications for Android try to circumvent this by using native (unofficial) Linux APIs. (Android OS has an embedded Linux core, which was originally not supposed to be used by third party developers. They were limited to use Java/Dalvik code only.)
Google lately recognized this and introduced its own Native Development Kit (NDK) which officially lets developers to embed native code in their Java applications. This way they officially dropped any future compatibility with CPU platforms other than ARM (Intel CPUs use different native instructions) which the original reason was to develop their own platform independent Java engine.
Let’s summarize this. Google created a platform which is not portable across CPU architectures, slow, already fragmented and where he lost its own control. Any other company on earth would take it as a big failure.

That’s really interesting, Laci, thanks very much for the comment. I’m pretty amazed Google screwed up like this. It tells me that Gassée’s idea of the microsoft-ication of Android is probably what has to happen, which also makes it a lot less attractive to handset vendors.
When I try and tell people of my thesis that it’s game over already in smartphones, and it’s all about the apps (not a totally original thought, I admit), they typically respond that all the top selling iPhone apps will be ported to Android and iPhone’s advantage will be whittled away. What you’re saying is that this is much less likely, no?

Laci, this is REALLY interesting. I’ve always found Android’s sluggishness to feel almost “preconscious” in how much it permeates the system: it just feels like EVERYTHING, everywhere, is half-asleep (or daydreaming). And it’s something I’ve always noticed with Java, in any form, on virtually any hardware. Now, I’m not a programmer, but this puts it in much better perspective. And it really is a treacherous path for Google to be on. The OS is overwhelmingly inferior, not just as a dev environment but for the user experience as well. So, what can be done? A few things I can think of:

– The ability to run “native linux code” needs to be pushed as the PRIMARY mode of programming for Android.
– Android needs to lock as much of the OS as possible to a specific platform, and iterate quickly. Google didn’t want to do this in the beginning but it’s become obvious that it’s the only way forward.
– Google needs to invest a LOT of time in developing super-fast native code that handles common tasks throughout the system (allowing devs to hook in to more complicated pre-written routines in order to speed up their own apps)
– Google should stop the endless fragmenting by setting up a common reference platform with higher performance, AS WELL as a less-“endowed” version (maybe similar to current Android). This way there might be an eventual gap between “real” Android phones and lower-end models, but it would at least allow there to be some competitive software out there.
– Finally, and I’ve said this before, but: Google needs to hire a real interface design team. Please.

Tim, balance is restored. But I worry that very few of the population of potential smartphone users really worry so much about O/S minutae like this. I don’t mind that I can’t multitask, really. Android probably attracts the tinkerers, the sophisticated power user. The sort of person who can build his own computer from a kit. I know 2-3 people like that.

I have only seen TWO Android phones in the “wild”, as it were, a G1 and an HTC Hero. Do you see lots around you where ever you are? iPhones are everywhere of course.

Each time I stroll past my local phone store in the UK I ask to see the latest stuff and he has had (usually under the counter) Android phones since G1. I still use old Sony Ericsson phones (P900 & M600) for calls, text and GMail. Until they break ….

I’ve been in France since November so no chance to get hands on with Nexus yet, nor have I seen any in the wild here. Loads of iPhones, of course.

My son (19 ans) surprised me when he built a powerful gaming PC from a kit all by himself a few months ago so maybe it’s not rocket science:-)

I multitask by nature I was told by an American colleague as he explained to a well known VC we were visiting in the 80’s that I had driven him through London at breakneck speed, while lighting a fag, speaking on mobile, changing gears (stick shift) and making U turns without missing a beat. He was a wreck. I still do the same now often in a car with the wheel on the wrong side and in Paris so I suspect the Nexus is the one for me, eventually.

Tim, I’m not saying it is not possible to build good apps for Android. I’m saying only it is not possible to build high performance apps with Android’s native Dalvik API.
You need to hack and use unofficial Linux APIs to do these. That’s a big difference from iPhone, where the standard API is already pretty efficient and well documented.
High performance is important for games and navigation. You can check Apple Appstore, the most earners are mostly games and navis.

App envy, or “lack of high quality applications” emerged as the clearest negative issue for Android users, and “better apps” the most important thing Android “needs the most to continue competing”, the second being “less fragmented”.

Laci’s app concern seems quite apposite.

There was a high level of user satisfaction apparent in the survey. Perhaps, however, we can chalk this up to humans’ irrational tendency to favour things they already own; the same reason US Chevy and Ford owners stay attached to their terrible clunkers, and why the inhabitants of clearly 2nd rate countries, like Belgium, Chad or Wales, can still be patriotic.

The fragmentation issue is really the most serious problem for Google. The technical speed/architecture issue from Dalvik having no JIT (Just in Time Compiler) can easily be overcome by upgrading the VM runtime to incorporate one, just as Sun did with Java.

Just as a quick aside, for Java 1 -1.3 there were numerous similar complaints about its speed comparison to C++/C, but now Java (and similar VM-based approaches) is the far and away dominant server side language approach for serious development in nearly all organisations. The current performance for the 1.6/1.7 VMs are routinely favourably compared to, or pretty close to native code without the downside of native code problems (porting, multi-target builds etc).

Indeed in reality a JIT is just doing what a compiler does, but is doing it at runtime instead of at build time, so it has the flexibility to produce optimised native code for the platform it is running on from the same byte-code without the developer having to write and build for all target platforms individually. This is a huge advantage if you can get it to perform well.

The VM/JIT approach is the only practical approach to multiple hardware platforms, so at the moment Apple has an advantage in using a single platform which enables developers to use native SDKs.

However, it can also become a tarpit over time as changes to the architecture and APIs are a lot more impacting in a native environment. So as the iPhone hardware offerings mature and evolve, native developers will have to constantly re-engineer their apps, while VM-based apps are much more resilient as the VM takes care of remapping the same byte-codes to the new architecture. Meaning your apps will still run, even if the hardware changes underneath you significantly. This is simply not doable in a native environment.

In saying that, Apple’s strategy of desktop/mobile platform application integration is far more important than the current (temporary) performance lead it has. Google’s challenge is not to fall into the same problem Sun got into and try and please all the hardware manufacturers. If they took a leaf out of Apple’s book and laid a unified spec for the phones that the phone guys had to adhere to, instead of the other way around, then the game would be much more level and Apple would find its market share not as big a buffer as it once was.

Having actually developed for the iPhone and Android (and other architectures in lots of languages), it is not a technical issue that prevents this situation playing out, but a mindset on behalf of the platform strategists at Google.

Just a note on the interpreted code ban on the app store it is not really performance based as even things like Spectrum/NES64 emulators are banned (which would easily run at original-device native speeds on the iPhone).

Rather it is so Apple does not have to deal with runtime access to APIs that it cannot pre-vet as part of the submission process.

This means it does not have to go to the same lengths as say Sun in providing a decent security layer in the OS to prevent malicious code being downloaded and executed, which reduces complexity in the OS and minimises the need for on-device verification etc, which also slows down execution.

Steve, I agree Apple’s prohibition of anything interpreted is not just about performance but also about control.

However I have some other notes as well:

1. It is true, we use a lot of Java on the server side, but the reason is not that Java is the same speed as a proper C/C++, but:
a) Java is a higher level engine (C/C++), ie it is easier/faster to program and/or the programmers are cheaper.
b) On server it is always almost cheaper to add one more CPU, GB RAM, or another commodity server machine than to have high performance and stable C/C++ code.
c) Most server side code is about manipulating data on the network and databases where the real bottleneck is mostly storage and network bandwidth. You rarely see CPUs running at full speed.
d) Portability is certainly an important plus for Java. But it is only possible because server side tools usually don’t require fancy user interface integration and high performance graphics. Java was never very strong in either.

2. Having a temporarily slow interpreted VM is might be OK for a 5 men startup, but not for one of the leading technology giants (Google) planning to rule the highly competitive mobile OS/device market. Switching to a high performance VM (when??) will certainly be not helpful for fragmentation. Supporting different performance characteristics will be nightmare on developers’ side. (Most devices will run slow, some will run better on same hardware.)

3. Just in time compiler (JIT) is not a good solution in mobile. It works on server side well because servers are doing specific highly repetitive jobs, so the compiler has enough time to search and compile hotspots.
That’s the opposite of mobile user case where fast application switching and startup time is critical for user experience. Compilation certainly takes time and slows down applications initially. (Compare Visual Studio IDE startup with Netbeans/Eclipse on desktop.)

4. No commercially successful games in Java:
a) In opposite to servers, desktop and especially mobile hardware is a limited resource. As a developer you cannot expect hardware upgrades just because of your (Java) binary is not 100% efficient. In order to compete on the marketplace you need to have the highest performance code available requiring not only C/C++, but sometimes even lower level stuff. Java is a no-no here.
b) Most platform companies forgot that integration is a very important task.
For example, Java is slow on the graphics side because there’s no unified hardware accelerated graphics engine. No matter how fast code you write and optimize for OpenGL if the generic 2D graphics (user interface classes) is CPU based. Unnecessary copiing of data and switching between GPU and CPU graphics will kill your performance. You can of course rewrite your UI in OpenGL, but why bother simulating/calling C code in Java, when it is much easier to do in C/C++?

We can ideally expect that Google will learn from these experiences and improve their environment, but I think timing is everything in technology and it is much better to have a well-thought, stable and high-performance environment at launch time than continuous incremental repairs later causing fragmentation and user dissappointments.

I think we are conflating some unconnected issues here. So a bit of clarification is in order.

All higher-level languages are an abstraction in some form from the hardware, even C/C++. Indeed, higher level languages had similar discussion s around speed, hand rolling of routines etc from the assembler camp when they came out.

Java as a technology is a combination of the .class files containing the byte-codes produced by the compiler and the VM-Runtime. The use of the Java language is not required and is purely a syntax abstraction for the programmer (as evidenced by a number of other languages that produce .class format outputs). Similarly the Java syntax can be compiled to other things, such as native code (http://gcc.gnu.org/java/) or to another byte-code format entirely such as Dalvik, Microsoft’s CLR etc.

Most graphic intensive work is not really done in general purpose CPUs by programmers in any language, but rather is delegated to dedicated GPU hardware using APIs like DirectX or OpenGL. No one really does matrix transformations by hand in code and the maths intensive processes needed for these operations are performed by the hardware. Try running any modern Game without a dedicated Graphics card. If we had to use general purpose CPUs then we would still be at the 2D Donkey Kong stage even using assembler. Indeed for the iPhone you would use Objective-C and the Apple APIs for OpenGL.

The assertion around Java’s add another CPU approach compared to C++’s high-performance stable output is largely a myth, and indeed if we look at some of the more objective benchmarks (http://shootout.alioth.debian.org/u32q/code-used-time-used-shapes.php) we see that the Java 6 server benchmarks are not so far from the C/C++ numbers. Poor, bloated code in my experience is a function of the programmer not the language, although there are a large amount of poor slow Java apps produced by the large consultancies who tend to have poorly trained and lower skilled programmers.

JITs are varied in approach and do not need to be architected similarly to the server-side ones. Indeed, There are a number of approaches specialised for Mobile devices that include JIT/ hybrid hardware execution of bytecodes from ARM (Jazelle), incremental compilation so the app moves to a compiled form over time and the compilation results are stored for later use (thumb2), Sun’s own CLDC hotspot technology, Intel and Ximian’s Jit engine,
etc. In reality a JIT is needed more on mobile devices due to their resource constraints.

Pervasive computing requires a more security oriented environment that VM-based approaches are built from the ground up to support if are to limit the virus, trojan issues that plague desktop devices. This is not achievable in native code and Apple sidesteps by using the Appstore to prevent installation of apps from other places, dynamic installation, etc.

So what can we draw from this?
1. Specialisations are best done in hardware that language APIs give us access to. So the better devices with hardware targeted for computing (as Apple have done) rather than glorified Cameras as the phone manufacturers have given us is a must and will change over time as more decent OS-based devices make it onto the market

2. Google using Dalvik is not tied to the JVM spec and can easily extend the VM in anyway it sees fit, including mandating of APIs (OpenGl or otherwise) and hardware support. the choice of the Java language is purely a syntactic one for the developer.

3. The VM-based language limitations often pointed to are not in general a function of the language but of the surrounding VM-architecture, OS-level integration etc (do a bit of research on the JIT specs for mobiles) There are some things like pointers and some direct memory access that these languages generally avoid, but that is not to say that the VM is not implemented like this to optimise native OS calls.

4. The VM-approaches have rapidly caught up with native code on the server, without the programmer having to deal with the drag that native code development applies. Over time this approach will come to be the norm in other areas. Not many game devs now use assembler (the lowest level access to ha machine) as it is not needed any more given the frameworks available.

5. There is no reason to suppose that this cannot be done in the mobile world. Indeed the common refrain of well it does not work now so it will never be possible is refuted by almost every technical advance in history (large scale magnetic storage, high density solid state memory, general purpose processing etc, low-power radio silicon devices, steam engines etc).

In order to succeed Google needs to enforce a minimum spec from the manufacturers, not do a Sun and try and fragment the APIs to fit the poor devices on offer. Once this happens then mobile computing will be here and Apple will no longer dominate in the way it is.

I for one will be happy as I will not have to do builds for lots of individual target machines any more.

Steve, I do abolutely agree with you in the long term. If Moore’s law will hold, programming and machine abstraction will be at higher and higher level.
But this is a technology investment blog, and I care much more about who gets the majority of a new market (mobile Apps and content focused smartphones) in the next two years, than what happens in 5 or 10 years, because share prices and investors usually react short term.
In addition to this I expect a very strong network effect (or consolidation), like we saw in the cases of Microsoft Windows, EBay or Google recently, so I don’t expect more than 3 firms (or consortia) standing after the battle finishes.
As hardware is already commoditized (iPhone, Nokia N900 and Nexus One both use similar and widely available components) it seems that the selection and availability of quality content will be the key for winning this market.
In the consumer application space gaming is overwhelmingly the most important, most competitive market and requires the highest performance. This is why I’m focusing so much on gaming.
I still think it is not a coincidence we haven’t seen a single high-end (big budget) game written in Java in the last 15 years. The same way you won’t find many professional 3D graphics (OpenGL) programmers using Java (ask around DemoScene guys).
Maybe it’s just psychology, but that’s what I see and I doubt it will change in a very short term.

I didn’t want to bring this up, because the competitors actually have no paid appstore’s yet.
Android Appmarket has a lot of apps, but most of them free. Buying – with real money – is only available in a few countries.
Ovi has only a few – mostly unnecessary – applications.
Samsung just opened its store recently, I doubt it will gain a big market share.
RIM’s store is actually very professional – seems they know how to earn money – but their devices are more limited performance wise, so they should target their business users.

I think it’s game over already and Apple won. It will just take a few more years to see that. All tecnical jargon aside this is exactly how it happened in the desktop. No one realized Microsoft won until 2 years later.

For the wast majority of future iPad users who don’t speak native English – like me – this name is simply the extension of Apple’s iProduct line.
Apple thinks globally that’s why they should not worry about the name and should use GSM rather than CDMA (which was one of the most criticized thing yesterday). Outside US most countries use GSM.
The funny thing about iPad reviews is, most reviewers compare it to notebooks and netbooks comparing technical specifications side-by-side, where obviously every aspect of the iPad can be overcompeted by other devices. (Except multi-touch, maybe.)
Again many people likes to forget the design, integration and content aspects this little device provides in an easy to use and light-weight package. This is was not created for busy, creative professionals (like most of the reviewers are), but for lazy entertainment.
The integrated ebook store was not overemphasized at the event (because they have only a few partners yet), but I think this was the last piece missing from Apple’s content delivery platform and – if they do it right – it could make the biggest hit long term especially in education. (I’m just thinking about 7 year olds packed every day with heavy books going to school.)
Baruch, Tim, what do you think?

Apparently “Android” is a four-letter word in Cupertino. The flash card app Flash of Genius was a finalist in Google’s Android Developer Challenge, and the developers thought that was worth mentioning in the description of the iPhone version of their app. Apple didn’t agree, and sent the developers an email asking them to remove the Android line from their app description, under threat of an “interruption” in Flash of Genius’ availability on the app store.

Here’s something new, an apparent fork in the Linux source tree by Google. Key points appear to be that the Google kernel developers have not played nice with the Linux kernel developers, the Android code has been dropped from the Linux source tree, Google may have an exceptionally arrogant corporate-culture among its engineers, and Nokia has been playing nice with Linux. Can be taken as more evidence that Maemo is worth keeping an eye on.