RIM's Android compatibility for BlackBerry PlayBook and QNX will be a big game of chase

RIM's big plan for its PlayBook depends on Android compatibility, but it's unclear whether the company can be nimble enough to keep up with new builds.

So the BlackBerry PlayBook has now finally arrived.

Also Read: iPad 2 Versus BlackBerry PlayBook: Of course you realize, this means war.

Last week, while I was on vacation in Las Vegas watching David Copperfield, drinking copious amounts of liquor and being convinced in my altered state to watch female impersonators, a slew of BlackBerry PlayBook reviews came out from the usual consumer-oriented technology writers.

Apparently, they were all released in a rushed and ill-timed fashion because some little jackass decided to either violate a embargo or somehow got their hands on a leaked device in advance of the embargo and official reviewer device pool, but I digress.

[Note to RIM for future reference: You might want to reconsider your working relationship with New Media outlets that make their living out of leaking your materials using coerced staff and which burn you on a continual basis. Just a thought.]

My own evaluation PlayBook arrived today and I've barely gotten a chance to play with it. Because I believe in producing original material and a unique perspective on the device I'm not going to re-hash the thorough and professional write-ups from folks like David Pogue, Walt Mossberg and Joshua Topolsky, all of which followed a very similar theme, evaluation methodology and came to nearly identical conclusions.

The result? According to the privileged pre-release review digerati, RIM's PlayBook hardware and QNX tablet OS is solid and has all the raw technology mojo to make an excellent tablet, but is currently missing built-in email, contact management and calendaring functionality unless the device is paired with a RIM smartphone using the "BlackBerry Bridge".

That missing functionality is due to come out sometime during the late summer with an OS software update. In the meantime, if you want to get to your GMail or Google Calendar or other cloud-based email service sans BlackBerry, you'll need to use the web browser interface.

Now that being said, I should probably mention that not a single review that I have read from the above mentioned authors or any of the others I have seen on the Internet from the usual New Media bloggerati suspects has been written from the perspective of an actual technologist working in enterprise environments, which is the target demographic the PlayBook is made for.

This is roughly analogous to Consumer Reports or Car and Driver doing a 100 point evaluation of the M1A2 Abrams Main Battle Tank and criticizing it for lacking sufficient cupholders and getting crappy gas mileage.

So while I agree with these gadgety-consumerist writers that the PlayBook has a number of shortcomings that might dissuade a consumer from giving the device serious consideration compared to the iPad or an Android tablet, it's probably a bit early to spell gloom and doom for the PlayBook.

We just haven't seen any of the type of enterprise-oriented exploitive apps that the device has been meant to run yet. Heck, there aren't enough apps to look at on the device yet, period.

So where's the positive spin on the PlayBook then, if it's missing key functionality and a large stable of apps like the iPad or Android tablets?

It really has to do with the actual potential of the device. Unlike the iPad 2, forthcoming Android Honeycomb devices or the HP TouchPad, the PlayBook will be able to run a lot of different kinds of apps.

Initially, you're going to see stuff written in Adobe Air/Flash and in HTML5 "WebWorks" because that's what's available in the current PlayBook SDK. But (hopefully) come this summer and fall, the PlayBook will also have native C++ as well as BlackBerry OS 6-compatible Java applications.

With such a wide range of APIs avaliable to write for, this makes the PlayBook a dream app development machine, particularly for the enterprise which is certainly more interested in stuff like mobile ERP and Business Intelligence type of stuff than the latest version of Angry Birds.

This is not to say that consumer apps aren't important for the PlayBook. For it to be a well-rounded tablet, it absolutely still needs those to gain market traction. Unrealized potential doesn't mean much if there's nothing good to run on the device.

One of the ways that RIM is going to try to get traction in the consumer space and beef up that app portfolio is for the PlayBook to be able to run actual Android 2.3.3 applications in addition to the Java apps written for BlackBerry OS 6.

In a couple of previous pieces, most recently RIM's BlackBerry PlayBook: A Better Android than Android? I theorized on how RIM might actually make that Android compatibility work. This was purely conjecture on my part, based upon my understanding of technologies currently available on the market and how QNX functions.

Today, after a brief call with Research in Motion, I actually did learn how the yet-to-be-demonstrated PlayBook Android compatibility actually works. I have to say, they went the route I thought they were least likely to do, which is to run re-compiled, re-packaged Android applications on a Dalvik-compatible JVM running natively on the QNX OS.

Apparently, just like in Sin City and Frank Marino's "Divas Las Vegas" female impersonator revue I saw last week, PlayBook's QNX is going drag.

[Next: RISE, FrankenBerry! RISE!!!!]»

This is not virtualization as I suspected it might be. This is binary-level API emulation more akin to the way WINE runs on top of Linux to provide Windows compatibility.

Essentially, what RIM has done is to write/modify their own proprietary JVM that is able to natively execute Android Dalvik bytecode that has been spit out of the Google Android SDK, once it has been run through a special re-packaging tool.

This code/app re-packaging tool that RIM is going to distribute to developers later on this year converts the native Android APK file format to the BlackBerry BAR file format,  code signs the app for use on the PlayBook, which in turn allows the app to be submitted by the developer to the BlackBerry App World for monetization.

Also Read: Can RIM's PlayBook sustain an Android Parallel Universe?

RIM has already told me that they have no intention of running Android Market on the PlayBook, so you should abandon any dreams of that happening if you thought it was going to.

RIM hasn't yet shared with me the details as to how this is exactly going to work, but later on this year, developers will have tools at their disposal to test these re-packaged apps to ensure that they run properly on RIM's special Android JVM -- which I repeat is not Google's Dalvik, but their own special JVM that is compatible with Android 2.3.3 and below APIs.

Since this special JVM is not an officially sanctioned port of Google's Dalvik to QNX (nor is it full-blown Android with the Linux kernel and Dalvik virtualized) we have to assume that compatibility is going to be best effort.

That means that a whole bunch of apps are going to be broken out-of-the-box and will need to be re-compiled and debugged to run on this new pseudo-Dalvik, or this "Android Player" as they currently call it.

RIM has already told me that only "pure" Dalvik programs written for Android will work -- if there are any hooks into C++ using the Android NDK, you can forget about it working properly unless you re-write those pieces of code in Dalvik-compatible Java.

If you want native C++, you'll want to take advantage of QNX's own native SDK when it comes out.

There are obviously a number of things which concern me about this Android compatibility approach. First, is the need to cross-certify everything on a completely different JVM than on the platform it was intended for.

Second is the fact that while RIM's sandboxed player may be Android 2.3.3 "Gingerbread" compatible at launch, it means that any Android app that uses the Honeycomb 3.x APIs won't function. It also means that as the 2.x branch of Android continues to evolve and get API enhancements, Android apps written to those APIs won't function either.

Waterloo is going to be playing a continual game and vicious cycle of follow the leader, where Google takes its sweet time in releasing  Android source code, and then RIM has to incorporate that functionality back into the PlayBook Android-compatible JVM in order to make apps run correctly which were written to take advantage of that platform.

RIM hasn't discussed with me any sort of roadmap for how they intend to continue to enhance and improve Android compatibility, but you can expect that any new APIs that need to be built into Franken-Dalvik going forward are going to lag months behind Google's partnership Android tablet and handset manufacturers getting the "real" Android incorporated into their devices.

It's going to get messy, for sure.

However, there's a strange side effect and perhaps a benefit to this approach that might not immediately occur to the Android development community regarding all of this Google-imposed API lag.

And that is that since the PlayBook and QNX only runs on RIM-produced devices, maybe "Franken-Dalvik" is the closest the industry is ever going to get to a "Standardized" version of Android.

I know that sounds a bit crazy, but just as iOS is a single worry-free standardized development target for iPhone and iPad developers, this new RIM Android JVM could also be considered a single development target. Compile to RIM's certified APIs for Android, and you have your enterprise Dalvik application execution environment.

By being an API subset that is known to work on RIM's devices, it could become a de-facto programming standard. This is in stark contrast to the fractionalization that is currently occurring in the "Real" Android ecosystem with tons of different handset and tablet device profiles running a wide mix of OS versions.

And the fact that RIM probably had to negotiate with Oracle in order to indemnify themselves and their enterprise customers from any ongoing litigation related to Google and Java in order to create their Franken-Dalvik in the first place doesn't suck either, especially if you are a large organization looking to build enterprise Android apps and deploy them on a large scale.

RIM hasn't confirmed with me that they have any indemnification agreements with Oracle yet, but I suspect that this has to be the case because they are an official Java licensee.

Will RIM's special Android JVM on QNX be a liability that requires them to constantly trail and chase Google's APIs in a never-ending Dalvik compatibility race, or will it allow them to pull in front with real enterprise mobile application standardization on Java? Talk Back and Let Me Know.