[passportowner]

A historical question: did BB ever published the ART sources? I asked myself why didn't they published it and allowed the community update it. I assume it is integrated way too deep into the system and without the whole os source code one wouldn't be able to mess with it. But am I right?

[conite]

A historical question: did BB ever published the ART sources? I asked myself why didn't they published it and allowed the community update it. I assume it is integrated way too deep into the system and without the whole os source code one wouldn't be able to mess with it. But am I right?

The "source" is basic AOSP.

And no, it can't be tinkered with by the community, as it can't get installed without BlackBerry's signing keys.

[passportowner]

I know it is signed, good question if there was an alternative way to handle it.

Just theoretically:
I imagine the interface to the kernel and to other subsystems were kept minimal to separate the code as much as possible, and I think they did actually this. Now as it is possible to uninstall ART a developer would be able to install an own version (as long as BB keeps the wrapper up to date on the BB10 side). It means they had the chance to outsource the ART maintenance (at least a big part of it) to the community.
I ask why they never did that.

[conite]

I know it is signed, good question if there was an alternative way to handle it.

Just theoretically:
I imagine the interface to the kernel and to other subsystems were kept minimal to separate the code as much as possible, and I think they did actually this. Now as it is possible to uninstall ART a developer would be able to install an own version (as long as BB keeps the wrapper up to date on the BB10 side). It means they had the chance to outsource the ART maintenance (at least a big part of it) to the community.
I ask why they never did that.

It is not possible to uninstall it.

[Dunt Dunt Dunt]

A historical question: did BB ever published the ART sources? I asked myself why didn't they published it and allowed the community update it. I assume it is integrated way too deep into the system and without the whole os source code one wouldn't be able to mess with it. But am I right?

BlackBerry = Security = no messing with it. Sadly it's stuck in 2013 for the most part.

[Dunt Dunt Dunt]

I know it is signed, good question if there was an alternative way to handle it.

Just theoretically:
I imagine the interface to the kernel and to other subsystems were kept minimal to separate the code as much as possible, and I think they did actually this. Now as it is possible to uninstall ART a developer would be able to install an own version (as long as BB keeps the wrapper up to date on the BB10 side). It means they had the chance to outsource the ART maintenance (at least a big part of it) to the community.
I ask why they never did that.

BlackBerry = Security = not allowing other to mess with their products.


Be that the PlayBook, Passport or any other left in the past device we have wanted unlocked.

[passportowner]

True, my mistake, it is only possible to disable it.

[app_Developer]

If you think about the kind of permissions and resources that a runtime like this requires, allowing end users to install their own arbitrary runtime would be a big hole in the way BB thinks about security.

[SteinwayTransitCorp]

Any companies nightmare, every phone tinkered with would be a bomb looking to go off.

[SteinwayTransitCorp]

I must ask this question. In Windows new programs can get around older window versions by running in compatibility mode. In in essence tricking the new OS to run the program. It should not be that hard then again the cost to figure it out is not worth it. Just thinking.

[conite]

I must ask this question. In Windows new programs can get around older window versions by running in compatibility mode. In in essence tricking the new OS to run the program. It should not be that hard then again the cost to figure it out is not worth it. Just thinking.

I can't even begin to describe how much worse/harder this would be.

[app_Developer]

I must ask this question. In Windows new programs can get around older window versions by running in compatibility mode. In in essence tricking the new OS to run the program. It should not be that hard then again the cost to figure it out is not worth it. Just thinking.

Well the new OS is not being tricked! This is for old programs, that expected certain things to be work a certain way (how resolution is managed and reported by the OS for example), to continue to work by having the newer OS emulate the older OS's behavior.

But I'm not sure how that applies to what we're trying to do here?

[SteinwayTransitCorp]

whatever

[eshropshire]

Well the new OS is not being tricked! This is for old programs, that expected certain things to be work a certain way (how resolution is managed and reported by the OS for example), to continue to work by having the newer OS emulate the older OS's behavior.

But I'm not sure how that applies to what we're trying to do here?

Yes, Compatibility mode allows some, not all older programs to run.

Not sure how that applies to having new programs run on an older OS.

[eshropshire]

Yes, Compatibility mode allows some, not all older programs to run on newer versions of Windows.

Not sure how that applies to having new programs run on an older OS.

[Leyra B10]

If you think about the kind of permissions and resources that a runtime like this requires, allowing end users to install their own arbitrary runtime would be a big hole in the way BB thinks about security.

Yes but apps do not interface with the kernel. They run as processes controlled by a process manager.

Posted via CB10

[Leyra B10]

that applies to having new programs run on an old

Posted via CB10

[passportowner]

Actually they sometimes do need support from kernel side.

[Leyra B10]

Actually they sometimes do need support from kernel side.

Do you mean android or blackberry10?

Posted via CB10

[app_Developer]

Are we talking about Android apps or the Android runtime? you guys lost me.

I was saying the runtime needs so much access that it would break the BB security model if users could replace the runtime with one they spun or one they downloaded from some random place.

[passportowner]

In general.

[m3mb3rsh1p]

I was saying the runtime needs so much access that it would break the BB security model if users could replace the runtime with one they spun or one they downloaded from some random place.

All BB10 apps are sandboxed so none will ever access stuff without permission. BlackBerry's Android runtime being integrated into BB10 doesn't mean it is tied to the QNX kernel. BlackBerry probably uses the same method as BSD operating systems to route linux kernel calls to QNX through a dynamic library.

If someone made their own runtime, they could package it into a BB10 app. Users would then open that app and install Android apps through it, placing links on the desktop that start the app instead of the built-in runtime. It's just a huge technical feat.

BB10 has some features that are still amazing to this day. BlackBerry really has some wonderful software engineers.

[Leyra B10]

BlackBerry probably uses the same method as BSD operating systems to route linux kernel calls to QNX through a dynamic library.

Yes this is what I was referring to.

The QNX Neutrino Micro Kernel supports symmetric multiprocessor affinity called bound multiprocessing. It's used to improve cache hitting among other things.

You could install a run time like the javascript virtual machine and even your own drivers into the boot image. Communication with the kernel is done by a process manager.

I think it copies (not sure though as the documentation I read may have meant move) messages from their address space to that of the receiving process, and if receiver is waiting, control of the CPU is transferred over at the same time.

Part of this architecture is why the hub has been so great, it's easier to leverage hardware accelerated features using markup as a user interface, and faster to transfer data as typed arrays over the network.

Android, on BB10, is an embedded machine, rather a virtual machine somewhat like the browsers javascript engine.

Posted via CB10

[app_Developer]

All BB10 apps are sandboxed so none will ever access stuff without permission. BlackBerry's Android runtime being integrated into BB10 doesn't mean it is tied to the QNX kernel. BlackBerry probably uses the same method as BSD operating systems to route linux kernel calls to QNX through a dynamic library.

If someone made their own runtime, they could package it into a BB10 app. Users would then open that app and install Android apps through it, placing links on the desktop that start the app instead of the built-in runtime. It's just a huge technical feat.

BB10 has some features that are still amazing to this day. BlackBerry really has some wonderful software engineers.

No.

BB10 apps have a set of APIs that are available to them, and those are governed by permissions. It's like any other mobile OS.

An app (completely distinct from a runtime) can only make the calls that are available to an app (this is NOT a desktop environment as much BB woefully tried to make it so).

A runtime like Android needs far more than what an app would need. It needs access to hardware that an ordinary app wouldn't need (that it will then vend to its own apps). It needs permissions that an ordinary app wouldn't need and that the sandbox wasn't made to support. An Android runtime needs to dynamically manage process to support its own child services and activities, as just one example of something a runtime has to do that an ordinary app doesn't (and can't)

Again, if the BB10 sandbox, which is designed for apps, and it is designed to keep the device *safe* from arbitrary apps, then it would be a *huge* security hole if they (BB) had allowed this type of activity within a sandbox.

The sandbox was correctly designed to support mobile apps, not entire app environments with their own VM.

[app_Developer]

Yes this is what I was referring to.

The QNX Neutrino Micro Kernel supports symmetric multiprocessor affinity called bound multiprocessing. It's used to improve cache hitting among other things.

You could install a run time like the javascript virtual machine and even your own drivers into the boot image. Communication with the kernel is done by a process manager.

I think it copies (not sure though as the documentation I read may have meant move) messages from their address space to that of the receiving process, and if receiver is waiting, control of the CPU is transferred over at the same time.

Part of this architecture is why the hub has been so great, it's easier to leverage hardware accelerated features using markup as a user interface, and faster to transfer data as typed arrays over the network.

Android, on BB10, is an embedded machine, rather a virtual machine somewhat like the browsers javascript engine.

Posted via CB10

BB themselves have explained how this works, if you remember the BBJam sessions (the one in Orlando in particular).

They have a translation layer that sits between the kernel and the runtime. It effectively is emulating Linux. That's necessary, because just imagine all of Android system that they would otherwise have had to rewrite.

So there is no QNX magic dust going on. It's emulating enough of Linux so that the Android runtime effectively thinks it's running on Linux. Then they did some work to share the GPU (which is a big deal on this type of device) and that's basically the strategy.

No magic.