04-05-2013 04:15 PM
Hi. After waiting a month, BlackBerry tester reports my app fails to launch when tested. That is all I got. I have a dev. and a Production Playbook, with OS version 126.96.36.1996, so the old NDK ver. 1.0 problem of the missing library "libbps.so.1" file is not likely issue... My little scientific graphics app works fine on my Playbooks. I deleted the app on one Playbook, and rebuilt and re-installed the .bar file, and had no reported problems locally here whatsoever.
As long as I have a debug token installed, my app launches ok, and works fine. Even if I turn off Development mode, still works fine. Maybe its a.file-protection issue? (Usually is, in any Unix/Linux world...)
My key question: How do I replicate *exactly* the environment the Blackberry app testers are using?
If I can't do that, then I am simply checkmated. <Feel free to imagine the applicable angry rant ...>
Seriously, though, any ideas or suggestions appreciated. Right now, I can go no further with Blackberry.
04-05-2013 05:04 PM
*** Replicated *** ! Got it. I can now at least replicate the launch failure. I used my second (newer) Playbook, and have at least replicated the error. Both Playbooks run QNX O/s version 188.8.131.526, but the one I use for testing and development is older, by maybe six months. It also has four or five experimemtal apps on it, and a custom DOSbox.
That one loads and runs my graphics app fine, but on my newer Playbook, it fails to load and launch. It partly launches, and gives me the permissions screen, where I allow the app to have file access, but then it fails, and on the Windows box running the NDK doing the load-launch, I get the error box: "Downloading and Starting the Application... has encountered a Problem: Unable to determine returned PID from launch."
So, thats the problem. The newer Playbook is failing to return a vailid process-id to the NDK. Maybe file directory perms for the target \accounts\1000\shared\<yattayatta> app install dir then aren't set right? Don't know. But the icon is created, and I end up with a broken app on the newer.Playbook, but a successful install on the older one. Arrgh. And yes, I have set up the debug token correctly on newer PB, and Dev.mode is enabled, etc.
Anyone seen anything like this? When I figure it out, I will post the solution or workaround. - Rus.
04-05-2013 06:27 PM
Still goofy behaviour. One Playbook works fine as load-launch install target, one does not. Both run same o/s version. The previous error message does not look like its related to the problem. The PID (process-id) looks to be the wifi PID, as I install and load-launch apps via wifi. Never been a problem. Second attempt to load-launch on newer PB, reported that debug.token not installed (it was). Queried debug token details (via Run, Run Configurations, Target Properties, Debug Token Details button sequence, and new debug token date and details reported correctly. Shut down and restarted the NDK, this time query of debug.token details reports also the local debug token .bar file location ( in local settings dir, since I'm using Windows..), and when I delete and reinstall the app, I do *not* get a message about the debug token being wrong. The app semi-installs, but in broken mode, so that I get an icon, a partial start, and then it exits. Maybe either a permission problem, or a missing shared library. Also, do not get PID error message.
But the, I noticed a critical config file is being written to //accounts/1000/appdata/com.companyname.appname.te
and I am pretty sure that the path-structure of this non-accessible test location (for device-release test runs) is different on my first, older playbook. I must say, I find it difficult trying to do development on a platform without having root access. Its like trying to build a full-sized ship in a wee bottle.
Anyone able to point me to a simple two page note that describes in detail the localization differences for NDK code running under debug-token, vs NDK built code installed for production use? I sorta figured it out a while back, but maybe it has changed? The idea being that even a new O/S install, would still preserve the older directory structure and naming conventions, and that might account for this kinky situation, where two identical machines, running exactly the same O/S and program code, can behave so **bleep** differently. -Rus
04-05-2013 08:16 PM
Solution: Ok, here it is. I am rather embarrased. Must say, the Playbook NDK and its linkages to the Playbook device are pretty darn good. It's a decent environment, and with the ability to use open-source code, you can make it do anything you want. I've built a port of GNUplot graphics, and it now works. I was missing a small file, which was needed for memory management by the emulator / virtualization environment. It was in the path on one machine, and not part of my .bar file package, so it kacked in testing and on the 2nd Playbook. You use the file "blackberry-tablet.xml" to define all the "assets" you need for your package. You just use the xml construct <asset path="c:/needed_file">/accounts/1000/shared/misc/n
and the needed files are dropped into the //accounts/1000/appdata/com.yourname.appname.testD
directory, and your code should be able to see them. But you are sandboxed, so your stuff cant whack anyone elses app. The testDev_x_ string gets replaced by your unique hash on the production install at app download time, and your sandbox is under appdata, dir, accessable only by your apps code. Its a clever structure, but makes testing a bit complex. I had simply missed including a small 20k file the virtualizer need, but it was sitting in the shared common directory on my older Playbook, so my initial tests never caught my stupid error, as it was being found at run time.
I hope all my blather here is at least educational to someone learning the Blackberry Native Development Kit.
It's a complex environment, but everything works, and it's actually quite solid. At least all the bugs I've found.have been mine or in the open-source code I've pulled.out of Github. - Rus.