[xanderten50]

Just a simple question really,
Since most information I can find on the PlayBook cpu puts it as a Cortex A9, why do android apps seem to see it as a ARMv6?
This mostly affects 2 apps that I'm trying to use: OnLive & the TeamSpeak beta client.
Both install fine and seem to work (IE. they don't force close as soon as they run) but the OnLive app sites incompatible hardware (since I'm a fan of OnLive as well I've been looking into this on their forums and this only happens on ARMv6 CPUs) and the TeamSpeak app actually says it is not compatible with ARMv6 CPUs.
Does anyone have any idea if hardware checks in android apps can be circumvented?

[SifJar]

The problem is both apps use native code. This native code is compiled for ARM v7 processors. I'm not completely sure what's going on, but the fact of the matter is that even if the PB did report an ARM v7 processor, the apps still wouldn't work because native code doesn't work on the PB.

Perhaps the PB reports an ARM v6 processor so that the apps won't even try to run their native code, but will just report an incompatibility. (If they tried to run the code, the apps would probably just crash without any sort of error, which is poor user experience). Of course, this won't necessarily work with all apps (some may have native code compiled for ARMv6, in which case they'll just crash) but I believe ARMv7 is the most common amongst Android devices, so perhaps BlackBerry decided to report ARMv6 because they knew some apps would display an error on ARMv6 devices.

[quackquack147]

The problem is both apps use native code. This native code is compiled for ARM v7 processors. I'm not completely sure what's going on, but the fact of the matter is that even if the PB did report an ARM v7 processor, the apps still wouldn't work because native code doesn't work on the PB.

Perhaps the PB reports an ARM v6 processor so that the apps won't even try to run their native code, but will just report an incompatibility. (If they tried to run the code, the apps would probably just crash without any sort of error, which is poor user experience). Of course, this won't necessarily work with all apps (some may have native code compiled for ARMv6, in which case they'll just crash) but I believe ARMv7 is the most common amongst Android devices, so perhaps BlackBerry decided to report ARMv6 because they knew some apps would display an error on ARMv6 devices.

adding to sifjar's post, modern devices are armhf or arm hard float. so armel or armeb will result in a core dump. IMHO. can you reproduce the error code. i think it will result in a segfault. because armv6 and armv7 are different. and also not all armv7 are identical lets say omap3340 onwards are armhf. so armeb v7 even thought same family will result in segfault. i am not 100% sure. but playing with qemu i always ended up with a segfault and then a coredump, and have never ran a trace or dbg on the trap and where the fault lies.
hope this helps. if someone can reproduce the errors will be nice. i mean in playbook. there are log files which got the segfault messages. and lastly QNX is bsd based microkernel aka mach, and android is linux. so you need to translate, so you need the libraries also. i am not sure 100% again.
thanks
-paul

[quackquack147]

one more thing i forgot to add, both the distro qnx and android uses dalvik and java (jre/jdk), so if its java based then it should not be much of an issue. and then again i have no idea on this. this is my assumption and/or speculation.
so if both are java based then they should work 100%. but if they are core and/or foundation based i.e. uses systemcalls and ipc then i am sure it will result in a segfault. i have seen this happen in qemu all the time. this is the experience when i was trying to work with maemo for my nokia n900 in 2010 and 2011 (n900 got stolen in 2011), so had to abandon all my work almost, now i got a second hand one. so based on your query i will try to put back the old abandoned work back to business.
but still i am 100% sure armel and armeb of armv6 will result in a core because of segfault and also armv7 with different sub arch might also result in segfault or coredump. i will have to work again on an abandoned project to confirm this.
thanks
-paul

[xanderten50]

Going off these responses I take it there isn't going to be a quick fix - Am not overly surprised, was just a bit hopeful!
Thanks for the info guys