23 Reader Comments

1. mrsteveman1 Ars Tribunus Militum

   quote:

   Each individual application runs in a separate Dalvik VM instance, and memory is shared between these instances to reduce overhead.

   
   
   So while you can run background processes, aren't they going to be unstable like this? If one VM crashes does that take down the others?
2. Viewer Ars Tribunus Militum
   Blasting a Java related technology in favor of Mono?
   Blasting the Eclipse-based SDK and holding Microsoft Visual Studio as the gold standard...
   Quoting an ex-Microsoft .NET developer with some rigged benchmarks?
   
   Was it even relevant to bring that kind of politics into an article on Android?
   
   There probably is some awesome engineering in Mono and Visual Studio, but this site is so heavy-handed and evangelical about it, it's hard to take this seriously.
3. Viewer Ars Tribunus Militum
   One more thing: Just *glancing* at that Fibonacci test...
   
   Why is he wrapping a single integer in a class and allocating 10000 instances? Why not just allocate 10000 integers, which is the simpler and much faster, common sense approach?
   
   Because he's bending over backwards to showcase the advantage of structs vs classes.
   
   That's so obviously political...
4. gmerrick Ars Tribunus Militum

   quote:

   It's not directly compatible with glibc, however, and it omits some POSIX features such as support for wide characters.

   
   
   I'm a bit rusty on my programming skills, however don't you need wide character support to provide for asian languages such as Japanese and the written Chinese text?
   
   One would think that Android would require this support if they wanted to break into the asian market
5. digit_1 Seniorius Lurkius

   quote:

   I'm a bit rusty on my programming skills, however don't you need wide character support to provide for asian languages such as Japanese and the written Chinese text?

   
   
   No, you don't need wchar_t in the C library to handle Chinese/Japanese. Android uses ICU to deal directly with UTF-8 and UTF-16 strings in memory, handling internationalization, a very large range of character encodings needed for the Web, and much more. There is was no point to duplicate this in the C library.
6. hobgoblin Ars Tribunus Angusticlavius
   all in all it sounds like android is a rerun of what powers the hiptop/sidekick.
   
   not really surprising as the person that runs the android show is the same person that started the company that makes hiptop, and i think he also started the company that google bought and whos "IP" formed the basis for android...
7. ButWhenYouThinkFirst Seniorius Lurkius
   So why did they use the Linux kernel instead of one of the BSD kernels or perhaps Darwin?
8. ButWhenYouThinkFirst Seniorius Lurkius
   BTW, GPLv3 FTW. I wish it was possible for Linux to go GPLv3.
9. hobgoblin Ars Tribunus Angusticlavius

   quote:

   Originally posted by ButWhenYouThinkFirst:
   So why did they use the Linux kernel instead of one of the BSD kernels or perhaps Darwin?

   
   
   whats the support level for ARM on the BSD's?
10. ayelao Ars Scholae Palatinae
    When I attended Google I/O last year, I went to listen to the talks about some of the things they were doing in GWT, and the then-fairly-new Google App Engine. Due to the demand for those two services, I found myself attending Android-related events when the GWT and GAE events were too full.
    
    I found myself happily surprised by the things they discussed regarding Dalvik, and the software stack as a whole. It's been very interesting to watch Android evolve and grow, and I think this article was a great overview into how to begin working with Android.
    
    I've found it less fun than digging into the iPhone platform, but I think that's purely because I've had more time to spend with the iPhone SDK and toolchains, as well as its resemblance to Mac OS X.
    
    That said, Android is definitely a great environment in which to develop, and it's only getting better as time goes on.
11. Dr0ne Seniorius Lurkius
    As for me, Android is a very boring platform.
    
    Not compatible with anything else. Everything from scratch (and uhm, you can develop quickly stable and featured program but you can only choose 2 out of these 3 in any time). You are forced to use Java (but what about C, C++, Python, and more... ??). No real desktop environment. And officially you are even forbidden to run native code (i.e. not a smart phone-grade device but rather J2ME-like dumb dialer). All this comes with huge device size. Pretty useless brick with toy-like Java apps. As for me, I'm personally like Maemo platform design. Much more than this Android stuff.
    
    For example, try to beat something like this: http://tigro.info/blog/images/173.png
    
    This is Psi, great and featured Jabber client, preferred by many users on desktop. But now you can carry it in your pocket with Nokia n800\n810 and wonderful QT libraries. I bet years would pass before any Java craplet can really compete with Psi in terms of features and good protocol implementation.
    
    So, Android haves ton of apps. But these are usually toy-like useless stuff. Just like it was with J2ME and I do not see how Android is better and how it can really compete with WinMobile, iPhone and whatever else with such stupid and restricted platform design.
    
    My bet: Nokia needs to replace Symbian and Maemo would be a thing which replaces it in top smart phones of Nokia. And this will be Linux. Powered by it's whole community power and using tons of impressive libraries like QT. And this thing will be able to compete with WinMobile or iPhone on par. With fast and lightweight native apps and without dumb limits on which language you are granted rights to write code. As for me, it is pretty abusive tactics to restrict developers to certain selected languages only. This is not even in Open Source spirit to put such moron restrictions. And it very little differs from J2ME devices with proprietary OS. You can't use Linux power anyway so there is no real benefits on it's usage. So yeah, this is not Linux. This is just strange and boring stuff from Google with bunch of non-friendly restrictions, pushing Google's services over others in anti-competitive manner.
12. Osvaldo Doederlein Wise, Aged Ars Veteran
    Dalvik is an interpreter on steroids, but no interpreter will EVER compete with compiled code - even against code produced by the relatively limited JIT compilers targeting mobile devices. Those tests against Objective-C/Mono/JavaME are credible, it's just what I'd expect when comparing interpretation with native execution. And it's not going to get significantly better in future Android releases; interpretation is a DEAD-END. Unless, of course, they go the way of JIT. And in that case, they'll end with basically no advantage over JavaME VMs for code sharing and loading time. So much for a Radically Innovative VM...
    
    Quoting myself from another recent thread, "[i]The only chance for Android apps to have competitive performance is relying a lot on native components, like the GUI toolkit, SQLite, OpenGL etc.; or being I/O-bound.[i]". Android seems to rely so much on native components that I suppose that Dalvik is very optimized for that (Java/native interface); but this is also a tradeoff: a lightweight native interface is not compatible with high-performance JIT compilers and advanced Garbage Collectors; if Android ever evolves to have great JIT and GC, the native interface must become thicker and suddenly Android's Java frameworks - mostly designed as thin Java layer over native code, requiring massive Java/native calls - ain't a great idea anymore.
    
    Try writing an Android app that depends on CPU-intensive code that can only be written in Java (not "accelerated" by any system API); let's say, a program that captures the camera's input and performs real-time processing of each frame... say, to detect movement for devices without accelerometer, or to detect region of interest (human faces for photos, etc.). You can do that with JavaME in current feature-phones (not smartphone-class devices with state of the art mobile CPUs/GPUs that cost your eyeballs); and of course also with native code. But I'd be surprised if you can do it with Android.
13. jonabbey Ars Tribunus Militum
    I wrote my first Android app the other night, and I have to say it was a pretty great experience. The APIs make it terribly easy to bootstrap a new application with useful functionality. The Eclipse plugin and the Android/ARM emulator that comes with the Android SDK makes for a well integrated development environment. (Though I've not programmed for any other mobile device, and all my previous (very heavy) Java development was done with Emacs, so a lot of the pleasure is probably just from finally getting why people like Eclipse so much..)
    
    I've not programmed J2ME, but I have done quite a heck of a lot of Swing, and I have to say that working with the Android GUI stack has been much more pleasant so far. Good performance, support for really nice accelerated 2d and 3d rendering, an API for animation, GUI widgets designed for handheld use.. all very modern and enjoyable to use.
    
    Having integrated support for using WebKit for rendering, SQLLite for data storage, the Intents and Content Provider system.. all significant advantages over basic J2ME devices, as well, I should think.
    
    Using the G1 is not nearly as charming as using an iPhone, and there are definitely rough edges still, but programming it is a great experience, and I think I'll be writing a lot of apps for it as I go along.
14. 0xdeadc0de Ars Centurion

    quote:

    Pretty useless brick with toy-like Java apps.

    
    
    Oh, lookie what we have here, the opinion of an expert . Tell us, oh wise one, what these other platforms do that Android can't.
15. jonabbey Ars Tribunus Militum

    quote:

    Originally posted by mrsteveman1:
    

    quote:

    Each individual application runs in a separate Dalvik VM instance, and memory is shared between these instances to reduce overhead.

    
    
    So while you can run background processes, aren't they going to be unstable like this? If one VM crashes does that take down the others?

    
    
    Each VM runs in its own Linux process. They share memory for the Android SDK classes, but the VM is designed for that, and the shared memory is never written to after the system starts creating VMs.
    
    One of the things that makes Dalvik a bit different from other VMs is that it maintains the GC metadata on separate pages from the non-writeable shared object/class data so that the different VM processes are strictly separated despite the memory sharing.
    
    So, no, the VMs are independent in all the ways that matter for matters of stability and security partitioning.
16. Dan Bornstein Seniorius Lurkius
    Hi. I'm the Dan Bornstein quoted in the article.
    
    

    quote:

    A look at the Dalvik source code reveals that it is largely derived from the Harmony project, an open source Java implementation that is distributed under the Apache license and is maintained under the umbrella of the Apache Foundation. Android also leverages Harmony's class library. Google optimized various components of Harmony in several key ways. In addition to adapting the Harmony VM to support Dex, Google also rewrote parts of the stack to use faster native libraries?such as ICU for character encoding and OpenSSL for encryption.

    
    
    This isn't quite accurate. Dalvik incorporates many many classes from the Harmony library but none of the VM implementation from it.
    
    A condensed version of the history is that the VM and libraries were originally written from scratch. At the point when the system was "up and limping" we evaluated many options for how to bulk up the library to the point that it would be generally useful. At the time (early 2007), the Harmony library codebase was, relatively speaking, immature, but it seemed to have promise. So, we selectively imported code from it, made changes to it to make it better fit with our environment, and did rounds of bugfixing and stabilization on the results. We also continued to write some of the library code from scratch, in cases where the Harmony code simply didn't make sense to use in the Android / Dalvik environment.
    
    And that's what we shipped with. Since shipping 1.0, we have diligently been merging in more recent code from Harmony while also very explicitly marking places in the code where we have intentionally modified it. We are doing the marking for two reasons: (1) to help us identify potential patches to send upstream; and (2) to help maintain these intentional differences (so we don't inadvertently clobber them when we merge in newer Harmony snapshots.
    
    Modulo the intentional differences, we have in fact gotten the salient code in Dalvik pretty close to Harmony's tip-of-tree. We still have some general source tree cleanup to do in order to make merging (in either direction) straightforward, and we are very explicitly working towards that goal now.
17. recharged95 Ars Centurion
    "For example, try to beat something like this: http://tigro.info/blog/images/173.png "
    
    Tufte would be proud. But for the rest of us, that's why all the Maemo devices come with a stylus and run a non-smartphone 5-6" screen just to barely read stuff. And Styluses are sooooo 80's .
    
    Android is looking for 1 hand, efficient operation. No everyone's going to have a 800x400 6" screen and a full qwerty keyboard + stylus. That's one (or many) reason multitouch was not included too--and considering there are more efficient gestures to mimic the functions where Apple uses multitouch. Android is looking at what combining J2ME's MIDP and CDC profiles--which should have been done by Sun in the 1st place.
    
    As for performance, yes, you'll never go as fast as native code touching the metal, BUT, if you can get the same concurrent, parallelism, multimedia, and data processing behavior as those other languages, you're 90% there... where the 'customer' really, only cares about 40% of that stuff. Android applied K.I.S.S. and guess what? It works.
18. ButWhenYouThinkFirst Seniorius Lurkius
    I'm disappointed: this is rather weak for an arstechnica article. It's called "A developer's introduction", but has a whopping zero lines of code shown. Where's the part for developers? Do developers really care primarily about licensing, screenshots, and performance comparisons with Mono?
    
    In comparison, Siracusa's Mac OS X 10.5 review for arstechnica has a couple of DTrace scripts and some sample CoreAnimation code, and it doesn't even claim to be for developers. Maybe you could get him to write a follow-up review of Android with some more depth.
    
    P.S., I love the line "It gives application developers virtually unprecedented access to underlying platform components". I suppose "virtually unprecedented" does actually mean "with precedent" (e.g., OpenMoko), but it's a hilarious turn of phrase. :-)
19. segphault Ars Tribunus Militum et Subscriptor

    quote:

    Originally posted by Dan Bornstein:
    This isn't quite accurate. Dalvik incorporates many many classes from the Harmony library but none of the VM implementation from it.
    

    
    
    Thanks for the correction! I've changed the article accordingly.
20. Dr0ne Seniorius Lurkius

    quote:

    Originally posted by 0xdeadc0de:
    

    quote:

    Pretty useless brick with toy-like Java apps.

    
    
    Oh, lookie what we have here, the opinion of an expert . Tell us, oh wise one, what these other platforms do that Android can't.

    
    
    Simple. Android can not officially have fast and lightweight apps, libs, modules, codecs or whatever else. At very best, it can live as unofficial hack and with ton of headache due to lack of usual libraries.
    
    When it comes to intensive computations or intensive RAM access, with VM you're simply done. Especially on weak CPU of mobile device.
    
    Try to implement Vorbis encoder\decoder with Java? You will be awfully lucky if you will manage to fit real-time decoding on such CPU (not to mention that CPU load will be much higher anyway). Or what about H.264 encoder\decoder? Or, maybe, Theora and Dirac? (Yeah, I'm bastard, I know...). Then compare speeds and CPU loads with native versions, especially asm-optimized ones. How about data compression? According to http://quicklz.com/ very decent Java implementation loses 2..3 times to native code when there is real need for speed. Should I mention that mobile's CPU is weakling on it's own and does not needs to be slowed down further? Also, 2-3 times more CPU cycles means 2-3 times more battery power used to implement SAME algo. Each CPU cycle costs on mobile device. It costs you battery life. Very simple. The more cycles CPU doing, the more power is gone. That's how CMOS logic works. Maybe this is one of root causes of Android's awful battery life? Yes, you can run lots of Java stuff. But it does haves certain costs in terms of CPU load and battery power consumed
    
    Well, how about running Doom with decent FPS? I can do this on Nokia n8x0 devices. Even without 3D accelerator. Wow. What I will have on Android with Java (if someone bothers to port Doom into this non-standard Java?) I can imagine cool slide-show. Instead of game .
    
    And btw, on n8x0 I can run decent IRC client like X-chat and it can also run scripts. But hey, I neither can run it on Android nor Android is willing to run scripts on "foreign" scripting languages (at least officially).
    
    On my Nokia tablet I can also run OpenVPN and compress traffic on slow\expensive links like GPRS and protect it from sniffing in untrusted places (like public access points, etc). Not just it written on C (so I am out of luck with Android). It also does compression and encryption. Something like this will be awfully slow and consume battery like the hell if rewritten in Java and running on mobile CPU (but actually there is no such things for Android at all and they're officially impossible, only as unofficial hacks which can't be easily supplied to end users anyway so they're pretty useless waste of time).
    
    I also almost can not write apps on C, C++, scripts or apps on Python for Android. Nor I can really reuse existing code, apps, libs, codecs, modules, ... - that's really sucks. Of course you can stick to "our non-standard Java should be enough for everyone" point of view. But let's remember about another person's (old) mumblings that 640Kb ought be enough for everyone . This (pretty famous) person fortunately has been wrong. And Google doing just same kind of mistake? Of course you can hack stuff a bit but ... this is prohibitively hard and well, you can not easily package result and give it to others. And writing cool stuff for myself only or developers only or few geeks only is a waste of time. So, I'm do not consider Google's platform as an interesting target for me.
    
    P.S. I actually have just one question: why Google decided to take away freedom of choice? You can not use any programming language except one allowed by Google. That's weird. Especially for OpenSource project where I did not expected to encounter such proprietary-like and truly artificial limitations. What next? They will also forbid me to connect anywhere except google.com and it's services "for my own security" tomorrow? That's not funny.
21. Dr0ne Seniorius Lurkius

    quote:

    Originally posted by recharged95:
    
    Tufte would be proud. But for the rest of us, that's why all the Maemo devices come with a stylus and run a non-smartphone

    
    Maemo devices are pretty flexible. You can use it with just fingers most of time (and I do prefer it). Of course things like Psi are much better with stylus. But then you're rewarded - you can use a REAL program. With tons of working features and already debugged by years of hard work of it's dev team and users who use it daily for years. So at least you will not be hit by stupid protocol implementations bugs, etc. And it is fortunately not a notepad-like toy application with 3 buttons but a real serious program.
    
    

    quote:

    5-6" screen just to barely read stuff.

    
    JFYI, N8x0 are coming with 4.8" screen so N810 can easily fit some pockets. And 4.8" 800x480 screen is a very cool thing. With Gecko and decent screen you can browse web like it looks on your PC. Webkit (and things based on it) are good in their speed but have rendering issues on some sites which are critical for me. And if choosing between speed and ability to render site into something usable... choice is clear for me.
    
    

    quote:

    And Styluses are sooooo 80's .

    
    There was almost no handhelds in 80's, dude.
    
    Yeah, I dislike to use stylus BUT it allows to use screen much better so I do not have to stick ONLY to primitive apps with couple of buttons (and more controls will be pretty problematic to hit with fingers on a cat-a$$-sized screen). So, I have a freedom of choice. I can use a bit primitive native IM client and operate it with just with fingers. But when serious stuff getting needed I can resort to heavyweight and fully-featured decent IM client. And if there is choice between stylus and fail mission at all, I'm choosing stylus. Not to mention that drawing lines in graphic apps much better with stylus and turns into a real nightmare with fingers. Or I'm expected do not use any graphic editors at all by Google? Also for things like editing Open Street Maps same goes here. To pinpoint some location you need precision and stylus much more precise than fingers. So in some cases stylus can help so much. While I prefer to use fingers for basic device operations, I should have options for tricky and precision-sensitive operations anyway. And I value freedoms I have with Nokia's tablet. It haves comparable size but can do much more and does not restricts me. I'm really like this. I can even download torrent with transmission, etc. Feels like a small but real computer.
    
    

    quote:

    Android is looking for 1 hand, efficient operation.

    
    I can hardly imagine how can I use such brick with one hand. Especially when it comes to sliding it and using qwerty keyboard. Is this a, uhm, such joke?
    
    

    quote:

    No everyone's going to have a 800x400 6" screen

    
    It 4.8" so if fits pockets...and btw, screen is one of best things on tablets. I really like such wonderful screen :P
    
    

    quote:

    and a full qwerty keyboard + stylus

    
    But G1 does... and what is a clue to have a qwerty-enabled brick-sized device with features comparable to my old dumb J2ME dialer with cat-a$$-sized screen and single slow CPU to run both java and GSM? If device looks like a brick, it have to offer a decent features set. Or it is simply not worth of it's size and weight.
    
    

    quote:

    That's one (or many) reason multitouch was not included too--

    
    Probably main reason is Apple threat. I wonder if Apple also keeps patent on Ctrl-Alt-Del multitouch gesture btw
    
    

    quote:

    and considering there are more efficient gestures to mimic the functions where Apple uses multitouch.

    
    Well, my bet is that Android will not beat Apple. Btw, Apple also allowed to run native code. As well as WinMobile. It is pretty amazing that proprietary stuff ... less restrictive to developers than open source project. Does Google thinks it's funny? Good luck to them to compete with iPhone, huh.
    
    

    quote:

    Android is looking at what combining J2ME's MIDP and CDC profiles--which should have been done by Sun in the 1st place.

    
    But actually at the end of day it looks like useless toy similar to J2ME mobiles but with pretty huge handheld-like size which also causes me to expect much better feature set than J2ME cheap devices are offering. I expect that smart phone is thing which is smart enough to handle some tasks previously required me to use PC or PDA. And even dumb Symbian can run native code stuff like 3rd party multimedia player if I dislike built-in one. So I can choose between many 3rd party players. I can install codecs (so, I can have OGG ringtones). I can use 3rd party camera apps and they will even have horsepower to post-process image (for example, do noise reduction or resize) or save into format not supported directly by underlying operating system.And so on. So in some cases even stupid and ancient Symbian stuff is much smarter phone than Android. Amazing.
    
    

    quote:

    As for performance, yes, you'll never go as fast as native code touching the metal, BUT,

    
    This means also that you will waste more battery power to do same things. Every CPU cycle costs. It costs you battery life. And there is no "but" and no excuses. Because when device is off due to exhausted battery, it's just useless brick.
    
    

    quote:

    if you can get the same concurrent, parallelism, multimedia, and data processing behavior as those other languages, you're 90% there...

    
    Nice joke. You're "90% here" but several times slower and eating battery several more times than with native code. And virtually cannot use most of C, C++ libs, write on Python, etc. And when it comes to a real time (be it audio decoder for not-yet-supported audio format or just a 3D game) there is no 90%. You're either fit real time or you're not. So, Android is great for writing notepads. But I do not need such brick just to be able to launch notepad-like text editor.
    
    

    quote:

    where the 'customer' really, only cares about 40% of that stuff. Android applied K.I.S.S. and guess what? It works.

    
    It works? Huh? As a dumb and useless brick with dozens of restrictions and harcoded programming language? Wasting battery power quickly as the hell? And with such moron platform design you hope to compete with something like iPhone or WinMobile? IMHO, not a chance. I'm simply do not see how this device better than other things on a market. It ates battery like a hell, haves PDA-like size but features are rather resemble J2ME-like cheap and small phones. Do you really think such platform can compete on par with WinMobile and iPhone?
22. jonabbey Ars Tribunus Militum
    One thing to remember with Android is that there is not the assumed homogeneity of hardware that iPhone or Maemo has. Both iPhone and Maemo are restricted to a specific platform.
    
    Android is aimed at being a cross-manufacturer standard for the operating system and for an application development and distribution stack. Using code compiled to a VM makes sense in that kind of context, particularly when vendors who might be interested in shipping Android devices might not be interested in letting their customers muck around at the non-constrained userland level, let alone at the kernel level.
    
    Now, should Anroid be able to compile .dex classes to native ARM? That seems like a very fine idea.
    
    Would Android be better off if developers could write low-level C code and then be required to get all their apps approved by Google and/or the carriers before letting them be distributed or installed?
    
    I'm not sure that such is the case.
23. Dr0ne Seniorius Lurkius

    quote:

    might not be interested in letting their customers muck around at the non-constrained userland level

    
    I do not see any use of such decisions except bothering customers. Look, I can use sim card in another phone and\or I can then use (unrestricted) notebook or N8x0 from Nokia with full Root-level access. Then, nothing prevents my native code with unrestricted access from communicating over wireless. Actually, it makes little difference if GSM\3G modem is built-in into device or attached by external (usb, bluetooth, ...) connection. So such restrictions are pretty stupid since they're ONLY harm fair legal customers and do not achieve anything else. What is the clue to harm people who is not willing to do anything bad anyway? And these skilled enough for hacking or tampering with will work-around any restrictions anyway. And do you really expect many opensource-minded people will support restrictive platform? Well, let's see.
    
    And about "homogeneity of hardware": there is no universal stuff in the world. And attempt to use same programs without changes on 176x220 (medium-end phone) and 1024x600 (Netbook) screen will result in simple fact:
    
    Either users of phone will feel horrible when using programs developed with 1024x600 in mind or users of 1024x600 netbooks will be pretty unhappy with child-toy-like interfaces of programs intended to run on 176x220 screen and only 12 buttons available. So, dreams about cross-platform stuff which works anywhere without re-compilation and any adaptation are good but result will be quite disappointing.
    Even best intentions often do not lead to best results. So the result will be slow and restricted platform where developers have to broke their heads what they can expect - netbook sized device allows to comfortably place far more controls on screen than 176x220 cat-azz-sized screen for example.And Android said to support both.
    
    As for compiling, C and C++ compilers have gone a long way in optimizing code (and still skilled programer can outperform them up to several times in optimized assembly, that's why almost all real-world video codecs, players and so on contain asm-optimized code blocks in critical places). I'm really doubt Java can compete here anytime soon. Well, when Java implementation of H.264 will beat asm-optimized x264 on the same hardware (without help of hardware accelerators since they support limited set of algos anyway), I will have to take my words back. But I doubt I will be able to live long enough to see this moment and I doubt it will happen ever