Meet the BlackBerry wizardry that created its 'better Android than Android' Some remarkable technical wizardry lies behind BlackBerry’s Android coup. When it was launched in January, BlackBerry’s new OS was brand new BlackBerry 10 and largely app-less. But today it can execute Android apps at impressive speed. How did they do it? Thanks to some helpful inside knowledge, The Register will reveal it all …
An alternative would be to run Linux in a VM and then Android on top of that. This would be in some ways cleaner, but would greatly increase the RAM requirements, since there'd be two separate full OSes running at the same time. Cleaving at the POSIX layer reduces duplication of OS resources.
As for security, the Android binary blob is no different from any other binary blob QNX runs in user space. (A 3rd party BB10 native app is as "blobby" to the company as an Android binary.) It doesn't increase the surface area for attack.
The android apps can be housed in a Secure container using blackberry "Balance". There is no inherent danger to using android apps. It is no different than accepting any other form of unsecured data, or any blackberry native app because they is don't have access to root.
This is coup pure and simple. There really is no reason to consider the Blackberry anything less than a "better android than android". Still the average consumer is going to just grab whatever phone he last saw on a tv commercial. That's why Blackberry is best to focus on Enterprise or a couple years and look for another chance to crack the wider consumer market.
So in effect, the message Blackberry is giving to app vendors everywhere is "Write for Android, and you'll target us too". Thus removing any motivation for these developers to try and write native QNX apps. Even in Apple's darkest days before the iPhone, they never bundled Parallels or any such emulation software with their machines, they knew that that might have provided a short term gain, but long term it would have been a sign of surrender. Vendors don't want to targer a platform whose makers have surrendered.
I have owned a series of Macs since 2007. I would not own one for work today if it did not have VMware , Virtualbox or Parallels support. There are still many native apps that the Mac platform does not support. As big as apple is today, the Mac native app support is still pretty poor at least in the workplace. I don't agree with your argument.
But Apple never BUNDLED emulators with their machines. It was always an aftermarket purchase. In the same way, Blackberry should have made this something users could add on later, not something that comes with the phone. App now have negative incentive to make a native QNX port.
>Go get a Nexus5 and save yourself the grief that will surely accompany BB10 ownership.
>>I have followed your advice and am still trying to work out where to insert my SD card. Also, I can no longer go two days between battery charges. How do I fix this?
Er, trade it in for an LG G2?
Have a Nexus 4. No thanks to the Nexus 5. With the news that it can run apks directly I just ordered the Z30. Pinch gesture in the HUB to close out / open read mails, custom quick menu and the native Blackberry Express on the fly presentation tool are just 3 of many great features I am looking forward to. So no thanks again to the Nexus 5. My nexus 4 will be a more than adequate backup to my Z30 upgrade.
So after management ran the ship headlong into an iceberg, and fled into their golden life rafts, its up to the engineers to save the company with "this cool hack"? At this point, the ship is halfway to the bottom, and no amount of hackery can save it.
Only thing that would have save them would be if they had build a Java API on top of QNX from the start, or just rolled their own Andriod OS 3-4 years ago. However, that would have required competent management.
Kinda reminds me of the whole JCPenny mess, in which a new CEO and his management team were given ~80 million in one year to save the company, and guess what, company is now way worse off. The JCP board would have been better of just setting 80 million dollars on fire or just given it to their employees.
Wow.
That would make one of them the third legitimate use for this technique I've heard of (I gather it's popular with malware writers, but apart from them it's not really clear who else). The othere 2 were the AT&T "Blit" bitmapped graphics terminal and the Apollo Guidance Computer.
The article does not give enough tech detail to understand what they've done. I'm getting (having nosed through Wikipedia)
1)Dalvik is a special JVM. It reads its own file format that is more compact than Java .class files.
2)RIM engineers have ported it.
3)But QNX <> Chrome <>Linux (IIRC Chrome has been formerly forked from Linux)
4)Their hack operates below the kernel function call level and operates right at the software interupt (SWI) instruction level (actual ARM op code) AFAIK a OS kernel call can have multiple SWI calls inside it.
5) But I'm b**gered if I know how.
So thumbs up for the hack, whatever it is.
Only time will tell however if the management manage to snatch defeat from the jaws of victory. :(
That would make one of them the third legitimate use for this technique I've heard of (I gather it's popular with malware writers, but apart from them it's not really clear who else).
Self-modifying code was quite common in mainframe applications at least into the mid-1980s. It was often used in assembly-language apps for things like patching, on-demand loading, memoization, etc. Some higher-level languages supported it directly, such as COBOL with its ALTER statement.
I've also seen it used in some performance-critical code, again back in the '80s. As CPU caches became more complex, there was a lot of discussion about their effects on self-modifying code.
Depending on what you consider "self-modifying code", you might also include some techniques that involve dynamically-generated code, such as GCC trampolines (which build code at runtime on the stack). That's not usually considered self-modification, though.
As for how the QNX technique works: it's really not that complex (or new - Andrew oversells it in the article). The interrupt handler looks at the parameters to determine whether it's a QNX syscall or a Linux syscall. In the latter case it probably jumps to a thunk that does the conversion. (The conversion could be done in the handler, but that'd be messy.) QNX and Linux syscalls are mostly equivalent, thanks to POSIX, so it's mostly a matter of massaging parameters.
> it stand to reason that by 4.5 or 5.0 ART will be default and all Blackberry's effort will seem rather pointless.
ART is open source too. BB can build their own version.
In any case ART does run Dalvik apps, it just starts them faster by running the 'JIT' compiler on installation rather than at app startup (plus other optimizations). The apps aren't any different so they will still run under Android Dalvik* and BB Dalvik.
* NOTE: there is no plan to obsolete every app** in the play store nor all pre-4.5 Andoid phones** and tablets just to make BB unhappy.
** cf Windows Mobile 6.x and Windows Phone 7 where they _did_ do that to their own developers, OEMs and customers.
The Register 
Biting the hand that feeds IT
Copyright. All rights reserved © 1998–2024
