Enable the Java wrapper to load different .so library.

Enable the Java wrapper to load different .so library.


BUG=webrtc:7613

[Zhi Huang, 2017-03-21 17:58:11]

Description was changed from

==========
Enable to build DataChannel only WebRTC.

Create the PeerConnectionFactoryBase without library and different subclasses
can load different library according to the requirements.

BUG=None.
==========

to

==========
Enable to build DataChannel only WebRTC.

Create the PeerConnectionFactoryBase without library and different subclasses
can load different library according to the requirements.

BUG=None
==========

[Zhi Huang, 2017-03-21 17:59:34]

Patchset #1 (id:1) has been deleted

[Zhi Huang, 2017-03-21 18:02:46]

zhihuang@webrtc.org changed reviewers:
+ deadbeef@webrtc.org

[Zhi Huang, 2017-03-21 18:02:47]

I think with this change and some ifdef in the BUILD file should be able to
unblock Allo.

The good news is that we don't need to load the lib in PeerConnection.java so
that we don't need to have different PeerConnections.

[Taylor Brandstetter, 2017-03-23 18:02:29]

If we plan to support different sets of functionality by building shared
libraries with different names, this seems like a good solution. But we should
first decide if this is the long-term approach we want to take. I think before
going forward, we should start a discussion about how the "slim and modular
webrtc" design can be extended to the Java and Objective-C code, and come up
with a plan everyone approves.

[Zhi Huang, 2017-05-10 01:06:03]

Description was changed from

==========
Enable to build DataChannel only WebRTC.

Create the PeerConnectionFactoryBase without library and different subclasses
can load different library according to the requirements.

BUG=None
==========

to

==========
Enable to build DataChannel only WebRTC.

Create the PeerConnectionFactoryBase without library and different subclasses
can load different library according to the requirements.

BUG=webrtc:7613
==========

[Zhi Huang, 2017-05-10 21:50:45]

Patchset #2 (id:40001) has been deleted

[Zhi Huang, 2017-05-10 21:52:09]

zhihuang@webrtc.org changed reviewers:
+ sakal@webrtc.org

[Zhi Huang, 2017-05-10 21:52:10]

I think it's time to pick this CL up.
Please take a look. Thanks.

[Zhi Huang, 2017-05-10 21:52:42]

Description was changed from

==========
Enable to build DataChannel only WebRTC.

Create the PeerConnectionFactoryBase without library and different subclasses
can load different library according to the requirements.

BUG=webrtc:7613
==========

to

==========
Enable to build DataChannel only WebRTC.

Create the PeerConnectionFactoryBase without library and different subclasses
can load different libraries according to the requirements.

BUG=webrtc:7613
==========

[Zhi Huang, 2017-05-11 02:21:47]

Patchset #3 (id:80001) has been deleted

[Taylor Brandstetter, 2017-05-11 10:17:12]

https://codereview.webrtc.org/2767643002/diff/100001/webrtc/sdk/android/BUILD.gn
File webrtc/sdk/android/BUILD.gn (right):

https://codereview.webrtc.org/2767643002/diff/100001/webrtc/sdk/android/BUILD...
webrtc/sdk/android/BUILD.gn:178:
"api/org/webrtc/PeerConnectionFactoryDatachannelOnly.java",
nit: I'd call the file "...DataChannelOnly.java", since "DataChannel" is
normally capitalized like that.

https://codereview.webrtc.org/2767643002/diff/100001/webrtc/sdk/android/api/o...
File webrtc/sdk/android/api/org/webrtc/PeerConnectionFactoryDatachannelOnly.java
(right):

https://codereview.webrtc.org/2767643002/diff/100001/webrtc/sdk/android/api/o...
webrtc/sdk/android/api/org/webrtc/PeerConnectionFactoryDatachannelOnly.java:19:
public class PeerConnectionFactoryDatachannelOnly extends
PeerConnectionFactoryBase {
Could the class still be called "PeerConnectionFactory", so that an application
could switch to the "datachannel_only" build targets without having to change
any code?

https://codereview.webrtc.org/2767643002/diff/100001/webrtc/sdk/android/api/o...
webrtc/sdk/android/api/org/webrtc/PeerConnectionFactoryDatachannelOnly.java:22:
System.loadLibrary("jingle_peerconnection_datachannel_only_so");
Is the only difference this line of code? If so, why not just have a
"PeerConnectionLibary" class with a single method, "getLibraryName", which
PeerConnectionFactory calls? Then the build targets would either compile a
"PeerConnectionLibrary.java" or "PeerConnectionLibaryDataChannelOnly.java", and
each of those files would be really small. Or is there a reason this wouldn't
work?

[Zhi Huang, 2017-05-12 00:35:47]

zhihuang@webrtc.org changed reviewers:
+ magjed@webrtc.org, sakal@webrtc.org

[Zhi Huang, 2017-05-12 00:35:48]

Please take a look. Thanks.

https://codereview.webrtc.org/2767643002/diff/100001/webrtc/sdk/android/BUILD.gn
File webrtc/sdk/android/BUILD.gn (right):

https://codereview.webrtc.org/2767643002/diff/100001/webrtc/sdk/android/BUILD...
webrtc/sdk/android/BUILD.gn:178:
"api/org/webrtc/PeerConnectionFactoryDatachannelOnly.java",
On 2017/05/11 10:17:11, Taylor Brandstetter wrote:
> nit: I'd call the file "...DataChannelOnly.java", since "DataChannel" is
> normally capitalized like that.

Done.

[magjed_webrtc, 2017-05-12 10:45:06]

I'm not ok with this approach because it's not modular and it won't scale if we
also want to have e.g. audio or video only, or different combinations of these.
Why does the so file for datachannel-only has to have a different name? Can't
you use the existing name jingle_peerconnection_so and avoid changing anything
here?

[Zhi Huang, 2017-05-12 18:09:07]

Description was changed from

==========
Enable to build DataChannel only WebRTC.

Create the PeerConnectionFactoryBase without library and different subclasses
can load different libraries according to the requirements.

BUG=webrtc:7613
==========

to

==========
Enable the Java wrapper to load different .so library.


BUG=webrtc:7613
==========

[sakal, 2017-06-26 05:56:35]

sakal@webrtc.org changed reviewers:
- sakal@webrtc.org