Given the love of the hardware on the Blackberry, and the love for the Android software platform, Google’s new open phone system, it seems like a given, yet I haven’t seen anyone mention combining the two before. I had to google quite a bit and I was pleased to see some people are already pondering what they could do with the Android SDK once it’s fully released with all the Android libraries released to the wild. The Blackberry Curve uses a 320mhz processor with ~32mb of avalible ram, while the first Android phones use a 550mhz processor and 128mb of ram. The Blackberry Bold, when released, will have the hardware needed to run Android no problem.
Interestingly, both the Blackberry and Android run all apps as Java apps – the main difference lies in that blackberry apps run on the J2ME JVM while android apps run on the Dalvik JVM which has a lot more access to various math functions. So what does this mean? Well the Curve may be able to run a slimmed down version of Android (linux) and have some functionality down the road, but in the short term it’s very likely we’ll see someone come along and port the Dalvik JVM so that we have an Android runtime app – think about that; Android apps running natively on your Blackberry!
Technical details after the jump.
Some interesting tidbits:
There was talk (http://blackberryforums.pinstack.com/showthread.php?t=71334) on this forum earlier about the possibility of an Android runtime for the BlackBerry, and what sorts of compilers would need to be written for that to happen. The necessary compiler is nearly complete.
Once Google releases the source code to the remaining Android components (Dalvik VM, and the remaining libraries), it would take a couple of weeks to port it to the BlackBerry. If so, we will be running Android applications on the BlackBerry about the same time Android native devices are available to mere mortals.
The BlackBerry 8xxx generation devices (excluding the 8700 series) are a bit weaker on the processing side than the prototype Android devices that Google is showing off. PXA901 series CPU at 312 MHz, 32 MB of RAM, 64 MB onboard flash compared to the Qualcomm MSM7201A processor at 528 MHz, 128MB of RAM, 256MB of flash on the HTC Dream used to demo Android at I/O.
The BB Android Runtime will require a microSD card in the 8xxx series devices, which will be used to store the libraries, system files, and Android programs. The 9000 series devices should be more than capable of running the runtime though, and those are the primary targets for the release.
Still a lot of work ahead.
A couple of thoughts on the differences between the two:
The RIM Java environment relies heavily on J2ME from Sun, but the Android environment runs on a non-Sun Java Virtual Machine called Dalvik. There are a number of noticeable differences – for example, J2ME has little/no support for many java.lang.Math functions, but Android has them all. Android’s development environment is also very nice, and mostly well documented. The RIM java dev environment can be painful, with large holes in the documentation. (I haven’t tried out the latest eclipse stuff tho, so my comments may already be dated).
Translation from standard Java bytecode to the BlackBerry bytecode happens during the installation of MIDP/CLDC applications. This translation is essentially identical to what happens with producing COD files in the development kit.
And, as I said in my previous post, the firmware is where the BlackBerry JVM is located. That’s also where the carrier logo is located, as well as where the operating system signature verification code is located, and it isn’t a user alterable part of the system. It is similar to the BIOS in a PC, except there is no user method to update it. It exists only as microcode on the device, so the language in which it is written is a bit of a moot point (but, I would predict either in C or in the processor specific assembler).
The firmware abstracts the processor specific architecture away from the system/ That includes hardware abstraction for dealing with things like the DSP, speakers, buttons, the screen, USB-client port, microSD, battery, and the various radios. The hardware abstraction layer for each device is slightly different, but the mechanism for enumerating and utilizing the hardware is the same. The firmware based JVM also removes the need to recompile operating system/other software for the various CPUs that the BlackBerry devices have used over the years.
Some people who are familiar with the low level device functionality outside of RIM speculate the reason the JVM instructions for the BlackBerry are different was due to performance considerations on the older ARM7 based devices. Only the people who developed it at RIM can be certain.
As far as security, there are a few rather important points to consider. Managed languages (Java, C#, Python, Ruby, Lisp, et al.) are more secure than non-managed languages (C/C++, architecture assembler, et al.) because it is effectively impossible (assuming proper implementation of the managed language) to smash stacks (which include buffer overflow, format string, stack overflow, and other code exploit techniques), corrupt heaps (ditto with the stack smashing), or otherwise use data as code instructions directly (which encompasses just about every system compromising vulnerability that can exist). While managed languages are slower, security is a big advantage.
Sure, it is possible to write perfectly secure code in a non-managed language like C (like say… the RIM JVM), but it require substantially more competent programmers who understand the implications of working on a low level system. This is part of the reason why only the JVM and firmware HAL are written in a non-managed language on the BlackBerry. The amount of code is small, thus it could be throughly checked and rechecked for potential vulnerabilities prior to release.
There have, to date, been no successful attacks on the BlackBerry firmware, or the operating system itself. If there were, the Verizon GPS lock wouldn’t be an issue, application signing could be subverted, and non-RIM operating systems could be loaded on the devices. Considering BlackBerry devices have been available for over a decade, I’d say the security model works.
Linux has its own vulnerabilities. In the last 12 months, there were 6 local root exploits in the Linux kernel. That’s just counting the vulnerabilities in the operating system itself. Consider the vulnerabilities in applications that people run on the operating system. In the same time period there were 26 remotely exploitable application vulnerabilities, and 5 more non-kernel exploitable vulnerabilities.
Linux is by no means the most secure operating system in the world. It’s more secure than Windows, sure, but that doesn’t mean it is “unquestionably” the most secure. OpenBSD, for one, has had zero remotely or locally exploitable vulnerabilities in the last 12 months, and in the 10 years the OpenBSD project has been running, they have had a grand total of 2 exploitable holes. OpenBSD is dedicated to security and code correctness above other priorities (whenever a new class of vulnerabilities are found, they audit ALL of the code for potentially exploitable areas using the new techniques), and they have all sorts of memory protection methods to protect against stack/heap/memory corruption that can lead to arbitrary code execution.
All of the blockquoted text from here