Get the adapter type information from Android OS.

talk/app/webrtc/java/jni/androidnetworkmonitor_jni.cc

Index: talk/app/webrtc/java/jni/androidnetworkmonitor_jni.cc
diff --git a/talk/app/webrtc/java/jni/androidnetworkmonitor_jni.cc b/talk/app/webrtc/java/jni/androidnetworkmonitor_jni.cc
index 1716c19cf8be84344a3ef1bff3f7bebf8a7d5647..edb565965083e97400be7ae540601f7b5670bbb9 100644
--- a/talk/app/webrtc/java/jni/androidnetworkmonitor_jni.cc
+++ b/talk/app/webrtc/java/jni/androidnetworkmonitor_jni.cc
@@ -71,6 +71,29 @@ static NetworkType GetNetworkTypeFromJava(JNIEnv* jni, jobject j_network_type) {
   return NetworkType::NETWORK_UNKNOWN;
 }
 
+static rtc::AdapterType NetworkTypeToAdapterType(NetworkType network_type) {
+  switch (network_type) {

[pthatcher1, 2016/01/19 02:13:07]

I'd prefer AdapterTypeFromNetworkType

[honghaiz3, 2016/01/21 21:38:36]

Done.

+    case NETWORK_UNKNOWN:
+      RTC_DCHECK(false) << "Unknown network type ";
+      return rtc::ADAPTER_TYPE_UNKNOWN;
+    case NETWORK_ETHERNET:
+      return rtc::ADAPTER_TYPE_ETHERNET;
+    case NETWORK_WIFI:
+      return rtc::ADAPTER_TYPE_WIFI;
+    case NETWORK_4G:
+    case NETWORK_3G:
+    case NETWORK_2G:
+      return rtc::ADAPTER_TYPE_CELLULAR;
+    case NETWORK_BLUETOOTH:
+      // There is no corresponding mapping for bluetooth networks.
+      // Map it to VPN for now.
+      return rtc::ADAPTER_TYPE_VPN;

[pthatcher1, 2016/01/19 02:13:07]

Would UNKNOWN be a better map?  What does bluetooth have to do with a VPN?

[honghaiz3, 2016/01/21 21:38:35]

It has nothing to do with VPN, except perhaps, VPN and Bluetooth may have
similar priority ranks compared to other networks. The integer value of the enum
will be used for representing the network priority. 

I have never seen BLUETOOTH shown up as a network/connection type even if I
tried to set up a bluetooth connectivity. 

In the unlikely situation that Bluetooth network shows up, putting it as a VPN
type may give it similar rank of priority levels.

In fact, perhaps, we should just remove the whole AdapterType and use connection
type. That is what Chrome has done. WDYT?  

+    default:
+      RTC_DCHECK(false) << "Invalid network type " << network_type;
+      return rtc::ADAPTER_TYPE_UNKNOWN;
+  }
+}
+
 static rtc::IPAddress GetIPAddressFromJava(JNIEnv* jni, jobject j_ip_address) {
   jclass j_ip_address_class = GetObjectClass(jni, j_ip_address);
   jfieldID j_address_id = GetFieldID(jni, j_ip_address_class, "address", "[B");
@@ -186,7 +209,37 @@ void AndroidNetworkMonitor::Start() {
   jmethodID m =
       GetMethodID(jni(), *j_network_monitor_class_, "startMonitoring", "(J)V");
   jni()->CallVoidMethod(*j_network_monitor_, m, jlongFromPointer(this));
-  CHECK_EXCEPTION(jni()) << "Error during NetworkMonitor.startMonitoring";
+  CHECK_EXCEPTION(jni()) << "Error during CallVoidMethod";
+
+  UpdateNetworkInfos();
+}
+
+void AndroidNetworkMonitor::UpdateNetworkInfos() {
+  std::vector<NetworkInformation> network_infos;
+  GetAllNetworkInfos(&network_infos);
+  for (NetworkInformation& info : network_infos) {
+    // This method is already on the worker thread.
+    OnNetworkAvailable_w(info);

[Taylor Brandstetter, 2016/01/20 01:51:57]

This will add networks to the maps, but not remove them; is that intentional?

[honghaiz3, 2016/01/21 21:38:36]

Partially it was because we do not have the signaling of removing them yet. 
It was not critical because most likely it will be overwritten by a new network
info. 
And if it was not, it does not create issues except that the binding will fail.

Now I have changed to add the signaling and removing the network information.

+  }
+}
+
+void AndroidNetworkMonitor::GetAllNetworkInfos(
+    std::vector<NetworkInformation>* network_infos) {
+  RTC_CHECK(thread_checker_.CalledOnValidThread());
+  network_infos->clear();
+  jmethodID m = GetMethodID(
+      jni(), *j_network_monitor_class_, "getAllNetworkInfos",
+      "()[Lorg/webrtc/NetworkMonitorAutoDetect$NetworkInformation;");
+  jobjectArray j_network_infos = static_cast<jobjectArray>(
+      jni()->CallObjectMethod(*j_network_monitor_, m));
+  CHECK_EXCEPTION(jni()) << "Error during CallObjectMethod";
+  size_t num_infos = jni()->GetArrayLength(j_network_infos);
+  for (size_t i = 0; i < num_infos; ++i) {
+    jobject j_network_info = jni()->GetObjectArrayElement(j_network_infos, i);
+    CHECK_EXCEPTION(jni()) << "Error during GetObjectArrayElement";
+    network_infos->push_back(
+        GetNetworkInformationFromJava(jni(), j_network_info));
+  }
 }
 
 void AndroidNetworkMonitor::Stop() {
@@ -208,6 +261,7 @@ void AndroidNetworkMonitor::Stop() {
   CHECK_EXCEPTION(jni()) << "Error during NetworkMonitor.stopMonitoring";
 
   network_info_by_address_.clear();
+  adapter_types_.clear();
 }
 
 int AndroidNetworkMonitor::BindSocketToNetwork(int socket_fd,
@@ -266,11 +320,21 @@ void AndroidNetworkMonitor::OnNetworkAvailable(
 void AndroidNetworkMonitor::OnNetworkAvailable_w(
     const NetworkInformation& network_info) {
   LOG(LS_INFO) << "Network available: " << network_info.ToString();
+  adapter_types_[network_info.interface_name] =
+      NetworkTypeToAdapterType(network_info.type);
   for (rtc::IPAddress address : network_info.ip_addresses) {
     network_info_by_address_[address] = network_info;
   }

[Taylor Brandstetter, 2016/01/20 01:51:57]

It seems redundant to have two data structures that store the same information.
You could just store a vector of NetworkInformations, and have helper methods
like "GetNetworkInformationForAddress(...)",
"GetNetworkInformationForInterface(...)" as needed.

[honghaiz3, 2016/01/21 21:38:36]

I used two structures so speed up the lookup. But perhaps you are right
considering that the size of the vector is typically small even if considering
that one network may have more than one IP addresses.
After second thought, I think we should still two maps. One for updating. Using
a map of network info keyed by handle makes it much easier to update the map. 
The other map adapter type by the name is kept because it can hold the
information longer. It is unlikely that the adapter type will change when the
network goes up and down. 

[Taylor Brandstetter, 2016/01/26 02:35:09]

Ah; so the second map exists so you can remember the adapter type even if the
network is currently down. Understood.

 }
 
+rtc::AdapterType AndroidNetworkMonitor::GetAdapterType(
+    const std::string& if_name) {
+  if (adapter_types_.find(if_name) == adapter_types_.end()) {
+    UpdateNetworkInfos();

[Taylor Brandstetter, 2016/01/20 01:51:57]

Why is UpdateNetworkInfos necessary here? Won't nativeNotifyOfNetworkConnect
ensure that the cached information is up-to-date?

[honghaiz3, 2016/01/21 21:38:36]

There might be some short-term inconsistency between Android Java and the
native. 
Occasionally, the native code may find the network but the adapter type is not
populated yet. 
But this is heavy weighted, sometimes when network switches, this can take
100ms. 
So I am removing this, but we do not delete the mapping from name to type once
it is found. 

+  }
+  return adapter_types_[if_name];

[pthatcher1, 2016/01/19 02:13:07]

You can avoid too lookups by storing the result of adapter_types_.find.

[honghaiz3, 2016/01/21 21:38:36]

I am removing the update here. 
It was a little complicated here because UpdateNetowrkInfos may change the map
if it is called. 

+}
+
 rtc::NetworkMonitorInterface*
 AndroidNetworkMonitorFactory::CreateNetworkMonitor() {
   return new AndroidNetworkMonitor();