There is a race condition in NetworkMonitor where native observers may be removed concurrently with a notification being dispatched, leading to a dangling pointer dereference (trying to dispatch an observer that was already removed and destroyed), and from there a crash with access violation. By ensuring dispatching to native observers is done within the synchronization lock that guards additions/removals of native observers protects against this race condition. Since native observers callbacks are posted to the networking thread in the C++ side anyway, there should be no risk of deadlock/starvation due to long-running observers. Bug: webrtc:15837 Change-Id: Id2b788f102dbd25de76ceed434c4cd68aa9a569e Reviewed-on: https://webrtc-review.googlesource.com/c/src/+/338643 Reviewed-by: Taylor Brandstetter <deadbeef@webrtc.org> Commit-Queue: Harald Alvestrand <hta@webrtc.org> Reviewed-by: Harald Alvestrand <hta@webrtc.org> Cr-Commit-Position: refs/heads/main@{#42256}
This directory holds a Java implementation of the webrtc::PeerConnection API, as
well as the JNI glue C++ code that lets the Java implementation reuse the C++
implementation of the same API.
To build the Java API and related tests, make sure you have a WebRTC checkout
with Android specific parts. This can be used for linux development as well by
configuring gn appropriately, as it is a superset of the webrtc checkout:
fetch --nohooks webrtc_android
gclient sync
You also must generate GN projects with:
--args='target_os="android" target_cpu="arm"'
More information on getting the code, compiling and running the AppRTCMobile
app can be found at:
https://webrtc.org/native-code/android/
To use the Java API, start by looking at the public interface of
org.webrtc.PeerConnection{,Factory} and the org.webrtc.PeerConnectionTest.
To understand the implementation of the API, see the native code in src/jni/pc/.