But back to your main Blog points. You stated the key to RIM's QNX Android App policy success .. highly optimized hypervisor performance. But this success isn't just dependent upon software code. IMO, the SoC hardware must be capable and I don't see this as a possibility for a first generation PlayBook design.
If I may speak from experience alone, the A4 chip in the first iPad was a highly capable tablet SoC. But the hardware had limits and one example that exposed those limits was the iPad's inability to handle moderate to complex Excel spreadsheet tasks - either imported into Apple's spreadsheet program (Numbers) or manipulated in other iPad app programs. If the program app using those Excel files didn't crash, the calculations performed were done in an unacceptably slow time period.
Let's assume the PlayBook uses a SoC comparable to Apple's latest A5 chip. Even given that performance increase, I can't see the hardware handle virtualization operations in a timely manner. Oh, they will perform, but my bet is that they will be unbelievably slow!
Oh .. one final, somewhat related question. Did your Bushmills and Irish coffee indulgence that evening have any influence on your reasoning behind a MacBook Pro purchase? Grin.
RIM’s QNX operating system, which runs at the core of their PlayBook tablet will be able to run Android applications. But will that undermine native development for the aspiring OS platform?
I was rather shocked to hear the news today that RIM had finally confirmed what had been rumored for several weeks — that the new PlayBook tablet, which runs on the QNX operating system, will run Android applications in addition to Adobe AIR, Java and native C++ QNX apps.
Also Read: RIM’s PlayBook, Is It an Android FrankBerry?
Also Read: Can RIM’s PlayBook Sustain an Android Parallel Universe?
The more I wrap my head around the whole thing, the more I begin to feel like I’ve seen this happen before.
It could be an effect of ZDNet’s blog tech support adjusting the interphase transducer on the pattern flow buffers improperly on the site’s WordPress CMS during the recent New York City cosmic hail storm, or it could just be simply an enduring hangover from all the Irish coffees I had at the Setai NYC hotel bar last night.
Note to readers: The bartender does an awesome Irish coffee with Bushmills at the Setai.
But I digress. Yes, we’ve seen this “We do it better than the original on our platform” thing before. In fact, it was twenty years ago. The vendor who last tried to do this was… IBM, with their OS/2 2.0 Operating System.
This is going to open up old wounds for me, but I’ll do this anyway.
For the most part, in 1992, IBM succeeded in creating a “Better DOS than DOS and a Better Windows than Windows” with OS/2. It was a full 32-bit OS and could take advantage of much larger amounts of memory, which DOS and Windows could not. It could pre-emptively multi-task, where Microsoft’s DOS and Windows 3.0 could not. It could protect native OS/2 applications in discrete sections of memory, which DOS and Windows 3.0 could not.
It could also run DOS and Windows 3.0 applications in their own protected, separate regions of memory, which DOS and Windows… could not. It was the first PC operating system to ship with Windows virtualization included in the OS. It was amazingly ahead of its time, in that respect.
OS/2 ran DOS and Windows 3.0 applications so well, in fact, that IBM had a very hard time getting 3rd-party developers to write native OS/2 Presentation Manager applications. Indeed, there were a few little gotchas with OS/2’s Windows compatibility, it had problems for a time running Windows Enhanced Mode apps, and there were also issues with special types of device drivers, called VxD’s.
Eventually, IBM was able to resolve most of these compatibility issues in future versions of OS/2. But it was always a constant battle to keep up with Microsoft’s changes.
RIM is facing a very similar situation with PlayBook. Indeed, as I have written before, the QNX OS as it is implemented on the PlayBook is extremely impressive, resilient and sophisticated. I believe it to be a superior operating system in a number of respects to both iOS and Android.
However, there is a a great deal of risk associated with attempting to leverage a competitor’s ecosystem as opposed to being an active participant in it.
I do not know yet exactly how, from a systems architecture perspective, that QNX accomplishes Android compatibility. In some of my earlier articles which I’ve linked above, I’ve alluded to a number of possible paths the company could have gone down to achieve this.
This includes things such as doing a native port of the Dalvik VM for QNX, a binary emulation layer which would allow the native Linux-based Dalvik code to execute via API call translation at the QNX kernel and library level, or even something as radical as Android virtualization.
Also Read: Android Virtualization, It’s Time
The Android compatibility mode or “Player” as RIM refers to it in their press release, apparently run in something they call a “secure sandbox”. RIM isn’t going to show this software to PlayBook developers until May, at the BlackBerry World trade show in Florida, a few weeks after the device ships in retail, so presumably this won’t be released to end-users for at least several months post-launch.
I’m hoping that RIM went the Virtualization route as opposed to a native Dalvik port or a binary emulation layer. Ideally, I would like to see a full Android 2.3 stack running inside a Type 2 Hypervisor, which is similar to the way VMWare’s Mobile Virtualization Platform (MVP) technology works.
Essentially, this requires no “porting” work on RIM’s behalf. Instead, an actual copy of Android, with a complete Linux kernel, would run as “Guest” OS within QNX.
Of course, there are other ways to “Sandbox” an environment, such as with the use of OS system-level Virtualization (such as with Parallels Virtuozzo/OpenVZ or Solaris Zones) but it would still require binary emulation or a port of the Dalvik VM to do that.
Type 2 virtualization is obviously preferable because RIM would be running Google’s actual OS, and not attempting to mimic the native Dalvik API itself, which could present any number of compatibility issues.
This is not to say that this would not have its own number of risks associated with it — the hypervisor would have to be very performance optimized, and near-native Android performance would be expected by the PlayBook’s end users, or the compatibility mode won’t have much value.
To make Android NDK apps work, hypervisor-based virtualization is probably the only effective way to make Android C++ apps work correctly.
Regardless of the virtualization method used, however — there is the issue of whether or not Android compatibility will have the same “cooling effect” on the PlayBook’s native C++ development environment as well as on the Adobe AIR apps that IBM’s Windows 3.0 compatibility had on OS/2.
Obviously, there are differences here. Virtualization technology has improved considerably in 20 years and it has proven to be viable even on embedded systems. As opposed to trying to compete with an OS to sell on PCs pre-loaded and in retail, RIM is selling a hardware platform and going to monetize their own App World.
So the company might not actually care what developers target their apps to, whether it’s Android 2.3 Dalvik APIs, QNX C++ native, Java, or Adobe AIR/Flash. Oh, and then there’s the WebWorks platform SDK as well. The PlayBook is a literal smorgaboard of API’s, probably the richest of all the tablet OSes currently available.
The big question is will the PlayBook do all of them well, and will consumers “get it”. Only time will tell.
Will PlayBook’s Android “Sandbox” be a blessing, or a curse? Talk Back and Let Me Know.
Disclaimer: The postings and opinions on this blog are my own and don’t necessarily represent IBM’s positions, strategies or opinions.
