Without the usage of the srcjar_deps attribute we were not able to include .java files from other packages without violating the package boundary contraint. As an example, in this CL the target "libjingle_peerconnection_java" was directly including .java files from another packages in its "java_files" attribute. Using srcjar_deps we are able to declare the dependency of the target avoiding to create hidden dependencies in the codebase. This is not fixing the webrtc:6356 bug directly but it is a first step to include ThreadUtils classes in libjingle_peerconnection_client_java.jar again. It seems also to be related to the chromium:648244 bug. This can be solved if we can find a way to perform srcjar generation in the android_library target without changing the semantic of the target. BUG=webrtc:6356 Review-Url: https://codereview.webrtc.org/2610823002 Cr-Commit-Position: refs/heads/master@{#15914}
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, generate GN projects with:
--args='target_os="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 jni/.