Fix issues with NetworkMonitor singleton when used by multiple clients.

Fix issues with NetworkMonitor singleton when used by multiple clients.

When you create multiple "PeerConnectionFactory"s, they end up using
the same NetworkMonitor singleton. But the second one's
"AndroidNetworkMonitor" class (in C++) wasn't getting the expected
network list update, and as a result it wasn't binding sockets to
networks successfully, acting as if the networks didn't exist.

The solution is just to move "updateActiveNetworkList" to
"startMonitoring". This CL also does some other minor
cleanup/refactoring, and fixes a more corner-casey issue where, if the
first PeerConnection is destroyed, the second one would stop receiving
network updates.

BUG=webrtc:7946
Review-Url: https://codereview.webrtc.org/2990693002
Cr-Commit-Position: refs/heads/master@{#19156}
Committed: https://chromium.googlesource.com/external/webrtc/+/54c721541d1c29ba3404705e8cb81d3efa7e5db2

[Taylor Brandstetter, 2017-07-26 02:37:18]

Description was changed from

==========
Fix issues with NetworkMonitor singleton when used by multiple clients.

When you create multiple "PeerConnectionFactory"s, they end up using
the same NetworkMonitor singleton. But the second one's
"AndroidNetworkMonitor" class (in C++) wasn't getting the expected
network list update, and as a result it wasn't binding sockets to
networks successfully, acting as if the networks didn't exist.

The solution is just to move "updateActiveNetworkList" to
"startMonitoring". This CL also does some other minor
cleanup/refactoring, and fixes a more corner-casey issue where, if the
first PeerConnection is destroyed, the second one would stop receiving
network updates.

BUG=
==========

to

==========
Fix issues with NetworkMonitor singleton when used by multiple clients.

When you create multiple "PeerConnectionFactory"s, they end up using
the same NetworkMonitor singleton. But the second one's
"AndroidNetworkMonitor" class (in C++) wasn't getting the expected
network list update, and as a result it wasn't binding sockets to
networks successfully, acting as if the networks didn't exist.

The solution is just to move "updateActiveNetworkList" to
"startMonitoring". This CL also does some other minor
cleanup/refactoring, and fixes a more corner-casey issue where, if the
first PeerConnection is destroyed, the second one would stop receiving
network updates.

BUG=webrtc:7946
==========

[Taylor Brandstetter, 2017-07-26 02:39:06]

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

[Taylor Brandstetter, 2017-07-26 02:39:07]

PTAL

https://codereview.webrtc.org/2990693002/diff/1/webrtc/sdk/android/api/org/we...
File webrtc/sdk/android/api/org/webrtc/NetworkMonitor.java (left):

https://codereview.webrtc.org/2990693002/diff/1/webrtc/sdk/android/api/org/we...
webrtc/sdk/android/api/org/webrtc/NetworkMonitor.java:83: }
This method is only called by tests, and *should* only ever be called by tests,
so I turned it into "createAutoDetectorForTest()".

[sakal, 2017-07-26 12:47:27]

lgtm

[Taylor Brandstetter, 2017-07-26 18:27:22]

The CQ bit was checked by deadbeef@webrtc.org

[commit-bot: I haz the power, 2017-07-26 18:27:34]

CQ is trying da patch.

Follow status at:
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.webrtc.org/...

[commit-bot: I haz the power, 2017-07-26 18:56:49]

CQ is committing da patch.

Bot data: {"patchset_id": 1, "attempt_start_ts": 1501093642575480, "parent_rev":
"8e245561f21aeef2ac99cf3752b060f56d4d5357", "commit_rev":
"54c721541d1c29ba3404705e8cb81d3efa7e5db2"}

[commit-bot: I haz the power, 2017-07-26 18:56:58]

Description was changed from

==========
Fix issues with NetworkMonitor singleton when used by multiple clients.

When you create multiple "PeerConnectionFactory"s, they end up using
the same NetworkMonitor singleton. But the second one's
"AndroidNetworkMonitor" class (in C++) wasn't getting the expected
network list update, and as a result it wasn't binding sockets to
networks successfully, acting as if the networks didn't exist.

The solution is just to move "updateActiveNetworkList" to
"startMonitoring". This CL also does some other minor
cleanup/refactoring, and fixes a more corner-casey issue where, if the
first PeerConnection is destroyed, the second one would stop receiving
network updates.

BUG=webrtc:7946
==========

to

==========
Fix issues with NetworkMonitor singleton when used by multiple clients.

When you create multiple "PeerConnectionFactory"s, they end up using
the same NetworkMonitor singleton. But the second one's
"AndroidNetworkMonitor" class (in C++) wasn't getting the expected
network list update, and as a result it wasn't binding sockets to
networks successfully, acting as if the networks didn't exist.

The solution is just to move "updateActiveNetworkList" to
"startMonitoring". This CL also does some other minor
cleanup/refactoring, and fixes a more corner-casey issue where, if the
first PeerConnection is destroyed, the second one would stop receiving
network updates.

BUG=webrtc:7946

Review-Url: https://codereview.webrtc.org/2990693002
Cr-Commit-Position: refs/heads/master@{#19156}
Committed:
https://chromium.googlesource.com/external/webrtc/+/54c721541d1c29ba3404705e8...
==========

[commit-bot: I haz the power, 2017-07-26 18:56:59]

Committed patchset #1 (id:1) as
https://chromium.googlesource.com/external/webrtc/+/54c721541d1c29ba3404705e8...