Is a particular threading model required for webRTC native Android app

Question

First, i am unclear whether appropriate to reference links to other code, and if so apologies and would like to understand what a more appropriate mechanism might be for this case in which i am referencing libraries (these links are mainly provided as references to interested parties).

We have a webrtc native app for android which runs into difficulty when calling the dispose of the peerconnectionfactory. When the user selects to end an active session, we have a cleanup routine that closes the peer connection and then disposes of it (though the close is not really necessary as the call to the dispose also closes the connection before freeing other resources - e.g., such as the streams and the native observer - see libjingle - talk/app/webrtc/java/src/org/webrtc/PeerConnection.java ). In our case, the creation of the peerconnectionfactory is performed by a thread created via a runnable whereas the dispose of the factory is performed from the main UI thread.

This is where we run into problems - i.e., when trying to dispose of the peerconnectionfactory, the app crashes.

On review of posts related to the webRTC demo code (see https://chromium.googlesource.com/external/webrtc/+/master/webrtc/examples/androidapp/src/org/appspot/apprtc ) they do not appear to have this issues.

Additionally, when reviewing the native code for the peer connection factory implementation ( see peerconnectionfactory.cc in https://code.google.com/p/chromium/codesearch#chromium/src/third_party/webrtc/api/peerconnectionfactory.cc ) we see the unwrapping and deletion of the worker thread for the peer connection factory destructor.

Additionally, on review of the chromium webrtc issues list, we see several issues (e.g., https://bugs.chromium.org/p/webrtc/issues/detail?id=3100 or 4196) that lead one to believe that particular care needs to be taken relative to the threading / loop model to be used when using the peerconnectionfactory.

So, my basic question is whether there are issues when creating the peerconnectionfactory from a different thread than it is disposed by and whether there is a particular set of threading / looping requirements for managing the peerconnectionfactory.

thanks,

Polymer

Answer 1

So, it turns out that the threading was not the issue, to the best that i can tell tracing through code, etc.. the issue was that we had a single private class that implemented the SDPObserver, the PCObserver and the DataObserver along with some other logic.

The result of this was that when the peer connection was initialized, the class that implemented all of the observers (and some other logic) was passed as the observer and the recorded as the native observer in the libjingle, hence, a call to dispose of the peerconnection resulted in the freeing of the native observer which resulted in not just the PCObserver being released (in the libjingle peerconnection.dispose()) but because for us, it was the same class, everything got released - resulting in a crash when other class was assumed to still be there.

So, reworked with separate private classes for each observer and correctly passed just the appropriate observer to the peerconnection creation (and sdp/data observers as appropriate to different calls) and then all works - the dispose just releases the PCObserver and all is good.

Polymer