Java Development

[b42slo]

I have published a BBM Connected app based on the “Alternative Dependency Checker” sample in the BBM SDK. Recently, a customer reported a problem with the app hanging after they upgraded the OS on their device from BB OS 6.0 bundle 1907 to 6.0 bundle 2647.

I was able to reproduce this hang using the Torch 9800 simulator running BB OS 6.0.0.534. The “Alternative Dependency Checker” sample app tictactoeplus_app also hangs on this simulator. Further investigation revealed that this OS version includes BBM 5.0, but contains many of the BBM 6.0 modules.

The “Alternative Dependency Checker” works by splitting up the app into three modules (I’ll call them app, bbminterface and bbmsupport for convenience). Both app and bmmsupport depend on bbminterface which acts as a bridge, but app does not depend directly on bbmsupport. Rather bbmsupport is configured to run automatically at system startup, and the register an instance of itself in the RuntimeStore. Later when app is run, it can use bbminterface to lookup that instance of bbmsupport in the RuntimeStore. If the instance is present, it means BBM 6 support is available.

In order for the bbmsupport instance to not be present in the RuntimeStore, bbmsupport MUST crash when it tries to run. This is by design. bbmsupport should crash whenever the BBM 6 API modules are not present. Since it crashes upon loading, it never gets a chance to register itself in the RuntimeStore. While this is a rather unconventional method for detecting the availability of an API at run-time, it is nonetheless the method recommended by RIM for BBM 6.

However, in BB OS 6.0 bundle 2647 (or the simulator version referenced above), several BBM 6 modules are present even though BBM 5 is installed. This breaks the “Alternative Dependency Checker”. Normally, bbmsupport crashes because it cannot find a module like net_rim_bb_qm_platform. But on this OS bundle, that module is present. So bbmsupport runs and registers itself. Later, when app runs, it finds the instance of bbmsupport and attempts to establish a connection to BBM 6. Upon the attempted use of certain BBM 6 API classes, the app will hang. The point where the hang occurs is in the internal method ApplicationRegistry.waitForObjectToBeRegistered().

All of this can be reproduced simply by running the “Alternative Dependency Checker” sample app from the BBM SDK on the device or simulator OS versions referenced above. The only workaround to this issue I have found is to upgrade BBM to version 6.

[simon_hain]

excellent analysis b42slo.
Maybe it would work to put another layer in front of it, more or less performing your own check?

We have experienced this issue ourselves, but did not analyze it in depth as it only occurs when a certain menu is used.

[peter_strange · Accepted solution]

Agree with SImon, good work.

I am not sure I would put this down to an issue in the dependency checker.  Since the problem actually occurs in the BBM invocation, I think the same problem could occur if you had made your app dependent on BBM.  It seems that there is just a bug in BBM.

To explain this, I need to expand on your comment

"bbmsupport should crash ...."

In my understanding, this is not technically correct.  As I understand it, the bbmsupport module is not loaded because the loader finds that it can not prelink the calls that this module makes with any classes it has.  So the fact that is not present is not because it has crashed, but because it was never started.  This is splitting hairs in terms of how the dependency checker is supposed to work, but is important in the understanding of this problem. The point here is that all the required API calls from bbmsupport were found correctly, so the dependency checker has done its job.  The fact that some of these calls fail is a problem in BBM, not the dependency checker. 

In your specific case I would add a check in the dependency checker, like the check in proxy approach, which confirms the level of BBM before adding itself to the RuntimeStore. 

[RileyGB]

Interesting, I just tested an app of mine that uses the alt dependency checker on a 9800 device with bundle 2647 and BBM 5 and it doesn't appear to hang.

[peter_strange]

Note this sentence from the original post:

"Upon the attempted use of certain BBM 6 API classes, the app will hang. "

It will not fail for everything, just some BBM interaction. 

[RileyGB]

I'm confused. If that's the case, the app shouldn't be able to register the implementation with RuntimeStore. In which case, other API classes could not be accessed correct? On my Torch, the app cannot find the instance of the impl in the runtimestore and therefore it detects BBM6 as not being installed with this bundle of OS6. You shouldn't be able to do any BBM interactions without the instance in runtimestore correct?

I think I'm missing something here.

[peter_strange]

I tried to explain the issue in my first post.

The problem is not with the dependency checker.  It is working fine.  The problem is with BBM.  Some API Methods cause it to stall.  The original poster put this down to the dependency checker not doing its job.  However I think it is doing its job - the APIs are present, but broken.

OK?

[b42slo]

In my testing, I found that some classes like BBMPlatformApplication could be created without any problem. I encountered hangs when executing BBMPlatformManager.register() and when attempting to create an instance of ChatField.

It seems like the real problem is that a partial set of BBM 6 modules was included in this OS release. I'm not sure why BBM 6 modules were included when only BBM 5 is installed.

@searingmedia - if your impl is not getting registered, then it is likely due to one of two scenarios:

1. For some reason, your device does not have the BBM 6 modules.

2. Your impl is attempting to load a BBM 6 module which is not present and that my app and the sample do not.

[RileyGB]

Thanks for clearing that up Peter, makes perfect sense.

[b42slo]

Peter, thanks for the tip on the proxy solution. I hadn't looked at that yet, and it did indeed provide a good solution.

For those interested in the details, here is what I did:

In LibMain, before creating an instance of BBMBridgeImpl, perform the following steps to get the version of BBM:

final int bbmHandle = CodeModuleManager.getModuleHandle("net_rim_bb_qm_peer_lib");
if (bbmHandle != 0)
{
	// Check the module version for the main BBM module
	final String version = CodeModuleManager.getModuleVersion(bbmHandle);
	
	// Compare the version string to see if it meets the minimum requirements ( >= "6.0.0")
}

Iff the retrieved version is 6.0.0 or higher, then continue to create the instance of BBMBridgeImpl and store it in the RuntimeStore.

Tip: The BBMSDKDemoProxy project has some good code for parsing and checking the version number.