91d6edef35
We must remove dependency on Chromium, i.e. we can't use Chromium's base/logging.h. That means we need to define these macros in WebRTC also when doing Chromium builds. And this causes redefinition. Alternative solutions: * Check if we already have defined e.g. CHECK, and don't define them in that case. This makes us depend on include order in Chromium, which is not acceptable. * Don't allow using the macros in WebRTC headers. Error prone since if someone adds it there by mistake it may compile fine, but later break if a header in added or order is changed in Chromium. That will be confusing and hard to enforce. * Ensure that headers that are included by an embedder don't include our macros. This would require some heavy refactoring to be maintainable and enforcable. * Changes in Chromium for this is obviously not an option. BUG=chromium:468375 NOTRY=true Review URL: https://codereview.webrtc.org/1335923002 Cr-Commit-Position: refs/heads/master@{#9964}
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, build with
OS=linux or OS=android and include
build_with_libjingle=1 build_with_chromium=0
in $GYP_DEFINES.
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 jni/.
An example command-line to build & run the unittest:
cd path/to/trunk
GYP_DEFINES="build_with_libjingle=1 build_with_chromium=0 java_home=path/to/JDK" gclient runhooks && \
ninja -C out/Debug libjingle_peerconnection_java_unittest && \
./out/Debug/libjingle_peerconnection_java_unittest
(where path/to/JDK should contain include/jni.h)
During development it can be helpful to run the JVM with the -Xcheck:jni flag.