[StLouisMan2]

I don't know whether I have a right to start such a thread because I'm just copying something Robin Richardson said in another thread. To be precise, he said what PlayBook needs is sys.android.4.2.bar and sys.android.shell.4.2.bar. Then, some one asked if that was even possible. Then, some one said that it was. Then, I asked whether that wasn't something really important. Then, no one responded.
I'm asking you to respond here. If we had those two bar files, wouldn't Google Play be our oyster? Maybe that's a little over simplified, but I think that you can see my point.

Sent from my Nexus 7 using CB Forums mobile app

[SifJar]

Actually, the names of the files aren't especially important, and probably wouldn't be quite those anyway (the version in the file name is the version of the Android runtime itself, not the version of Android that runtime is based upon). What matters is the contents of those files. For example, I could rename the current Android runtime files with those names, but that wouldn't help in the slightest. What you actually want (and will probably never receive) is an Android runtime based on Android 4.2. [Although why settle for 4.2 considering 4.3 has been released now?] However, much more important than that is support for native code within Android apps. This is what would make apps like Netflix, Skype, Instagram, many games etc. work; these apps will work fine with Android 2.3 (like the current run time), but they need native code support. With both these additions, the vast majority of Android apps (not counting things like widgets, or cosmetic utilities like wallpaper changers etc., or root utilities) would work on the PB.

Of course, there still wouldn't be Google Play Store access. Meaning any apps not officially converted and put into PB's App World would still need to be converted and sideloaded manually.

[StLouisMan2]

Actually, the names of the files aren't especially important, and probably wouldn't be quite those anyway (the version in the file name is the version of the Android runtime itself, not the version of Android that runtime is based upon). What matters is the contents of those files. For example, I could rename the current Android runtime files with those names, but that wouldn't help in the slightest. What you actually want (and will probably never receive) is an Android runtime based on Android 4.2. [Although why settle for 4.2 considering 4.3 has been released now?] However, much more important than that is support for native code within Android apps. This is what would make apps like Netflix, Skype, Instagram, many games etc. work; these apps will work fine with Android 2.3 (like the current run time), but they need native code support. With both these additions, the vast majority of Android apps (not counting things like widgets, or cosmetic utilities like wallpaper changers etc., or root utilities) would work on the PB.

Of course, there still wouldn't be Google Play Store access. Meaning any apps not officially converted and put into PB's App World would still need to be converted and sideloaded manually.

I'm sorry that I don't know enough about Development to understand what support for native code within Android apps means. Can someone explain this to me, or is it too complex? I have a suspicion that this is something that is in BlackBerry's hands.

Sent from my Nexus 7 using CB Forums mobile app

[SifJar]

Yes, sorry I should have clarified; Android apps can be written using either Java or C++. Using C++ allows code to be faster because it is "native" rather than being interpreted on-the-fly. The PB only supports Java, not the apps written in C++ ("native code" refers to compiled C++ code).

Blackberry are indeed the only people capable to giving the Android runtime such an ability, just as they are the only people capable of providing us with an update to a runtime based on Android 4.2 (or any other version of Android for that matter). No one here can just create an update for any part of the PB OS; they have to come from BlackBerry, and BlackBerry have apparently announced that the PB will only be getting minor updates for security fixes from now on, so we're not likely to see any major improvements to the Android runtime unless some one figures out some way to hack the OS and install the BB10 Android runtime or something.

[speedklz]

DId the Dev Alpha version some were installing on the PB have a newer version of theses files?

[StLouisMan2]

Yes, sorry I should have clarified; Android apps can be written using either Java or C++. Using C++ allows code to be faster because it is "native" rather than being interpreted on-the-fly. The PB only supports Java, not the apps written in C++ ("native code" refers to compiled C++ code).

Blackberry are indeed the only people capable to giving the Android runtime such an ability, just as they are the only people capable of providing us with an update to a runtime based on Android 4.2 (or any other version of Android for that matter). No one here can just create an update for any part of the PB OS; they have to come from BlackBerry, and BlackBerry have apparently announced that the PB will only be getting minor updates for security fixes from now on, so we're not likely to see any major improvements to the Android runtime unless some one figures out some way to hack the OS and install the BB10 Android runtime or something.

Instead of just clicking "Like", I wanted to thank you in words for taking the time to explain all of this to me.

Sent from my Nexus 7 using CB Forums mobile app

[playbookpa]

Wow! Just had to thank you for this explanation: clear and concise for a non-coder, If you're not teaching yet, you might consider it, you're really good! Thanks!

Yes, sorry I should have clarified; Android apps can be written using either Java or C++. Using C++ allows code to be faster because it is "native" rather than being interpreted on-the-fly. The PB only supports Java, not the apps written in C++ ("native code" refers to compiled C++ code).

Blackberry are indeed the only people capable to giving the Android runtime such an ability, just as they are the only people capable of providing us with an update to a runtime based on Android 4.2 (or any other version of Android for that matter). No one here can just create an update for any part of the PB OS; they have to come from BlackBerry, and BlackBerry have apparently announced that the PB will only be getting minor updates for security fixes from now on, so we're not likely to see any major improvements to the Android runtime unless some one figures out some way to hack the OS and install the BB10 Android runtime or something.

[Nickstarmaster]

Yes, sorry I should have clarified; Android apps can be written using either Java or C++. Using C++ allows code to be faster because it is "native" rather than being interpreted on-the-fly. The PB only supports Java, not the apps written in C++ ("native code" refers to compiled C++ code).

I'm sorry, i respectfully disagree with that.
The PlayBook does run and recognize C++ code.(How couldn't it? Part of QNX is written in C++)
The reasons that the PlayBook does not run some apps are:
*Native code inside the app, for example, Where's my Water, it have specific instructions for ARM processors, and since the Android runtime can't handle that, it can't be run. But when i mean native code, i really mean an code written to do an specific set of instructions in a determined architecture.
*BlackBerry security ****: They really blocked some features for security, so few apps that require permission to share processes, for example, won't run.
*Hardware limitations: No barometer, no bluetooth, no telephony.
*Zero support for Google Android connection.

Basically is that, there are tons of another "can't do" things.
They are listed at: Unsupported APIs for BlackBerry PlayBook - Runtime for Android apps on PlayBook - BlackBerry Developer

Too limited runtime, such a shame.

[SifJar]

I'm sorry, i respectfully disagree with that.
The PlayBook does run and recognize C++ code.(How couldn't it? Part of QNX is written in C++)

No offence, but I thought that was obvious. I meant it does not run native code within Android apps. Obviously it runs native code within native QNX apps written using the PlayBook SDK (which is a C++ SDK).

The reason it doesn't run native code with Android apps is none of the stuff you mentioned. PB uses an ARM processor (TI OMAP4430 which is an ARMv7 processor), so it's not that it's a different architecture. The problem is that native code in Android apps is compiled against Linux libraries (e.g. liblinux.so). So the code makes calls to these libraries. However the PB OS doesn't have those libraries. It has it's own (e.g. libqnx.so), and they're not cross-compatible.

So for example the app will try to call a function from liblinux.so, and it will fail, because it's not there. And they can't just redirect the calls to libqnx.so, because the functions don't work the same. For example, the function "time()" might return the current time in a different format in libqnx.so than in liblinux.so (and of course, that's a simple example).

Now, there is a way around that; it's called "wrapping". Basically, it'll take the calls to liblinux.so, convert them into calls to libqnx.so, then convert the response from libqnx.so to the response expected from liblinux.so. This is what happens in BB10's Android runtime (which now does support native code in Android apps). It's also how programs like Wine work (allowing Windows programs to run in Linux).

[Nickstarmaster]

No offence, but I thought that was obvious. I meant it does not run native code within Android apps. Obviously it runs native code within native QNX apps written using the PlayBook SDK (which is a C++ SDK).

The reason it doesn't run native code with Android apps is none of the stuff you mentioned. PB uses an ARM processor (TI OMAP4430 which is an ARMv7 processor), so it's not that it's a different architecture. The problem is that native code in Android apps is compiled against Linux libraries (e.g. liblinux.so). So the code makes calls to these libraries. However the PB OS doesn't have those libraries. It has it's own (e.g. libqnx.so), and they're not cross-compatible.

So for example the app will try to call a function from liblinux.so, and it will fail, because it's not there. And they can't just redirect the calls to libqnx.so, because the functions don't work the same. For example, the function "time()" might return the current time in a different format in libqnx.so than in liblinux.so (and of course, that's a simple example).

Now, there is a way around that; it's called "wrapping". Basically, it'll take the calls to liblinux.so, convert them into calls to libqnx.so, then convert the response from libqnx.so to the response expected from liblinux.so. This is what happens in BB10's Android runtime (which now does support native code in Android apps). It's also how programs like Wine work (allowing Windows programs to run in Linux).

Now i understood that you were talking about Android Runtime and not the PlayBook itself.
Sorry.

[AshDeezy]

This thread is amazing.

If I'm understanding right, the android runtime that's compatible with PBOS will not allow for C++ coded apps to run as it doesn't have the ability to "wrap" the code? So even if we convert and sign the .apk files with a key, they won't work?

[KermEd]

This thread is amazing.

If I'm understanding right, the android runtime that's compatible with PBOS will not allow for C++ coded apps to run as it doesn't have the ability to "wrap" the code? So even if we convert and sign the .apk files with a key, they won't work?

Sort of.

Android OS supports c++ coded apps on the PlayBook --- however it is extremely unreliable and unfinished. The only c++ runtime elements that actually work are what was necessary to run the runtime. To make it worse if a C++ drive app for Android dies, the BB10 OS won't always catch the error.

SO Long winded way of saying, blackberry blocked native apps until the runtime was complete. However they have also realized allowing true native runtime could also allow developers to supercede some security protocols they have in place (such as refusing unpacked APK installs)

What this means...

Is you, as a 3rd party developer cannot sign native android apps to run. Once native code on Android is executed the OS will kill the app for having invalid permissions.

BlackBerry can sign apps to run with Native code - however, on PB, this is far more unstable than BB10. Which is why they signed apps like Netflix and the Unrestricted Android Runtime. For Bb10.

Makes it more muddy. But that's my understanding of android runtime at the moment - but I'm sure someone smarter than me can clarify

Posted via CB from my LE

[AshDeezy]

BlackBerry can sign apps to run with Native code - however, on PB, this is far more unstable than BB10. Which is why they signed apps like Netflix and the Unrestricted Android Runtime. For Bb10.

Thanks for the response. Can you clarify the above? What do you mean they signed Netflix? Does that mean they manually did something to specifically allow the old version of Netflix to be allowed to run on the restricted gingerbread runtime on 10.1?

Of course what I'm getting at is work arounds for Instagram and Netflix, like any other dweeb is.

[KermEd]

Thanks for the response. Can you clarify the above? What do you mean they signed Netflix? Does that mean they manually did something to specifically allow the old version of Netflix to be allowed to run on the restricted gingerbread runtime on 10.1?

Of course what I'm getting at is work arounds for Instagram and Netflix, like any other dweeb is.

Nope you are dead on.

A developer inside rim signed Netflix as an approved native app - essentially saying it's an essential android runtime file.

That's why BB10 users can sideload Netflix if they want, as long as it's that one version.

My understanding though is the native runtime it requires from gingerbread is actually completely broken at the PB level and it won't run at all.

To complicate it they signed it as a BB10 required app I think.

You might have heard of those work around on BB10. That's what debug tokens are all about - they let developers use any permission they want... temporarily

Posted via CB from my LE

[AshDeezy]

Is there a debug token process for the PB?

[KermEd]

Is there a debug token process for the PB?

No idea - I've never tried it. But the native side is less stable on PB to boot

Posted via CB from my LE

[SifJar]

The PB doesn't support native code (i.e. code written in C++) at all, to the best of my knowledge. The signed Netflix BAR that was released a while back installed fine on the PB (i.e. it was not signed specifically for BB10), but it didn't function at all (force closed [i.e. crashed] straight away, if I remember right). Around the same time, there was also an Instagram BAR (again, signed by a RIM employee), which had similar results (installed, but did not function).

The "debug token method" (documented by xsacha a few months later) worked because to use native code in apps, there had to be an extra permission in the BAR file's "manifest", and with that permission present, the official BB signing tools refuse to sign the BAR. However, when you use a debug token, you don't "sign" the BAR as such, and so can have whatever permissions you want (including the one for native code). Now the apps converted using these process could be installed on a PB, but the native code still didn't work because it's run time does not recognise the native code permission. So xsacha made his conversion tools convert the BARs with a minimum required OS of 10.0.0.0 to prevent people installing the converted apps on the PB and complaining they didn't work.

The debug token method does not and cannot work on the PlayBook. It is also outdated now on BB10, as there is a leaked runtime (possibly pushed out in an official update by now, not sure I don't keep up to date with BB10 too much) which allows native code without using that workaround. I think it just allows native code in all Android apps, regardless of whether or not they have that special permission. But of course that leaked runtime only works on BB10, so it can't be used for PB either.