Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
10915043:
[Android] Improve NetworkChangeNotifier granularity (Closed)
|
Created:
8 years, 3 months ago by gone Modified:
8 years, 3 months ago CC:
chromium-reviews, cbentzel+watch_chromium.org, darin-cc_chromium.org Base URL:
ssh://gerrit-int.chromium.org:29419/clank/chromium@master Visibility:
Public. |
Description[Android] Improve NetworkChangeNotifier granularity
The NetworkChangeNotifier for Android currently cannot identify what type
of connection exists; all it can do is determine whether it's currently got
one. This CL patches it so that we pass this information back from the Java
side, allowing us to properly use NetworkChangeNotifier::ConnectionType.
The connection types (2G, 3G, etc.) are differentiated between using
classifications from Android's TelephonyManager.
BUG=136984
Patch Set 1 #Patch Set 2 : Rebasing #
Total comments: 11
Patch Set 3 : Addressing comments #Patch Set 4 : Rebasing #
Total comments: 2
Patch Set 5 : Fixing unknown case #Patch Set 6 : Mirror Telephonymanager.java #
Total comments: 2
Patch Set 7 : Change logic around to clean it up #
Total comments: 6
Patch Set 8 : Nit fixing #
Total comments: 1
Patch Set 9 : Rebasing #Patch Set 10 : Changing base url #Patch Set 11 : Base url change again #
Messages
Total messages: 20 (0 generated)
Hey Ben, I'm currently working on upstreaming some changes we made to the MetricsService, but we need finer granularity on the connection types reported by the NetworkChangeNotifier to do it. Seems like you were the last guy to work on these files; could you take a look? Thanks! Dan
Thanks Dan! Please make sure the NetworkChangeNotifierTest is still passing with this change. http://codereview.chromium.org/10915043/diff/2001/net/android/java/src/org/ch... File net/android/java/src/org/chromium/net/NetworkChangeNotifier.java (right): http://codereview.chromium.org/10915043/diff/2001/net/android/java/src/org/ch... net/android/java/src/org/chromium/net/NetworkChangeNotifier.java:24: public static final int CONNECTION_UNKNOWN = 0; // A connection exists, but type is unknown. Don't think the comments on the ints are necessary as they're in the native side. http://codereview.chromium.org/10915043/diff/2001/net/android/java/src/org/ch... File net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java (left): http://codereview.chromium.org/10915043/diff/2001/net/android/java/src/org/ch... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:90: if (intent.getBooleanExtra(ConnectivityManager.EXTRA_NO_CONNECTIVITY, false)) { NetworkChangeNotifierTest.java uses this intent extra to simulate us receiving a "network disconnected" intent, so I think it's still needed? http://codereview.chromium.org/10915043/diff/2001/net/android/java/src/org/ch... File net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java (right): http://codereview.chromium.org/10915043/diff/2001/net/android/java/src/org/ch... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:82: if (activeNetworkInfo == null) nit: braces http://codereview.chromium.org/10915043/diff/2001/net/android/network_change_... File net/android/network_change_notifier_android.cc (right): http://codereview.chromium.org/10915043/diff/2001/net/android/network_change_... net/android/network_change_notifier_android.cc:45: switch (connection_type) { looks like we can just return connection_type? http://codereview.chromium.org/10915043/diff/2001/net/base/network_change_not... File net/base/network_change_notifier.h (right): http://codereview.chromium.org/10915043/diff/2001/net/base/network_change_not... net/base/network_change_notifier.h:36: CONNECTION_UNKNOWN = 0, // A connection exists, but its type is unknown. I think you only need to seed the first value in the enum, if any of them? Or is this just to make the Java/native mapping explicitly clear?
Ran the test locally; it'll have to be upstreamed with all of its numerous dependencies in a separate CL, though. PTAL. https://chromiumcodereview.appspot.com/10915043/diff/2001/net/android/java/sr... File net/android/java/src/org/chromium/net/NetworkChangeNotifier.java (right): https://chromiumcodereview.appspot.com/10915043/diff/2001/net/android/java/sr... net/android/java/src/org/chromium/net/NetworkChangeNotifier.java:24: public static final int CONNECTION_UNKNOWN = 0; // A connection exists, but type is unknown. On 2012/09/04 20:32:09, benm wrote: > Don't think the comments on the ints are necessary as they're in the native > side. Done. https://chromiumcodereview.appspot.com/10915043/diff/2001/net/android/java/sr... File net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java (left): https://chromiumcodereview.appspot.com/10915043/diff/2001/net/android/java/sr... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:90: if (intent.getBooleanExtra(ConnectivityManager.EXTRA_NO_CONNECTIVITY, false)) { On 2012/09/04 20:32:09, benm wrote: > NetworkChangeNotifierTest.java uses this intent extra to simulate us receiving a > "network disconnected" intent, so I think it's still needed? I've put this back in, but it seems like it's not exactly what we want to be testing against. There's a note in the downstream test that makes it seem a bit fragile, which makes me want to just rewrite it with a mocked ConnectivityManager... https://chromiumcodereview.appspot.com/10915043/diff/2001/net/android/java/sr... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:90: if (intent.getBooleanExtra(ConnectivityManager.EXTRA_NO_CONNECTIVITY, false)) { On 2012/09/04 20:32:09, benm wrote: > NetworkChangeNotifierTest.java uses this intent extra to simulate us receiving a > "network disconnected" intent, so I think it's still needed? Hrm... I've added it back in, but I'm a bit hazy on exactly when Android fires it. https://chromiumcodereview.appspot.com/10915043/diff/2001/net/android/java/sr... File net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java (right): https://chromiumcodereview.appspot.com/10915043/diff/2001/net/android/java/sr... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:82: if (activeNetworkInfo == null) On 2012/09/04 20:32:09, benm wrote: > nit: braces Done. https://chromiumcodereview.appspot.com/10915043/diff/2001/net/android/network... File net/android/network_change_notifier_android.cc (right): https://chromiumcodereview.appspot.com/10915043/diff/2001/net/android/network... net/android/network_change_notifier_android.cc:45: switch (connection_type) { On 2012/09/04 20:32:09, benm wrote: > looks like we can just return connection_type? The compiler won't allow it. This is actually converting between the two types and uses the mapping I explicitly made between the Java and Native sides. https://chromiumcodereview.appspot.com/10915043/diff/2001/net/base/network_ch... File net/base/network_change_notifier.h (right): https://chromiumcodereview.appspot.com/10915043/diff/2001/net/base/network_ch... net/base/network_change_notifier.h:36: CONNECTION_UNKNOWN = 0, // A connection exists, but its type is unknown. On 2012/09/04 20:32:09, benm wrote: > I think you only need to seed the first value in the enum, if any of them? Or is > this just to make the Java/native mapping explicitly clear? This is just to make it explicit. If someone adds a new value in between somewhere it can screw up the mapping.
http://codereview.chromium.org/10915043/diff/10001/net/android/java/src/org/c... File net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java (right): http://codereview.chromium.org/10915043/diff/10001/net/android/java/src/org/c... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:109: case TelephonyManager.NETWORK_TYPE_UNKNOWN: should this map to NetworkChangeNotifier.CONNECTION_UNKNOWN?
https://chromiumcodereview.appspot.com/10915043/diff/10001/net/android/java/s... File net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java (right): https://chromiumcodereview.appspot.com/10915043/diff/10001/net/android/java/s... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:109: case TelephonyManager.NETWORK_TYPE_UNKNOWN: On 2012/09/06 17:08:41, benm wrote: > should this map to NetworkChangeNotifier.CONNECTION_UNKNOWN? Yeah, nice catch. I've gone ahead and reordered it to better match TelephonyManager.java; the unknown case falls under "default" there.
http://codereview.chromium.org/10915043/diff/10002/net/android/java/src/org/c... File net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java (right): http://codereview.chromium.org/10915043/diff/10002/net/android/java/src/org/c... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:126: int newConnectionType; nit: this uninitialised local feels a bit odd to me, would something like: boolean noConnectivity = intent.getBooleanExtra(ConnectivityManager.EXTRA_NO_CONNECTIVITY, false); int newConnectionType = noConnectivity ? CONNECTION_NONE : currentConnection(context); be clearer? wdyt?
https://chromiumcodereview.appspot.com/10915043/diff/10002/net/android/java/s... File net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java (right): https://chromiumcodereview.appspot.com/10915043/diff/10002/net/android/java/s... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:126: int newConnectionType; On 2012/09/06 21:06:54, benm wrote: > nit: this uninitialised local feels a bit odd to me, would something like: > > boolean noConnectivity = > intent.getBooleanExtra(ConnectivityManager.EXTRA_NO_CONNECTIVITY, false); > int newConnectionType = noConnectivity ? CONNECTION_NONE : > currentConnection(context); > > be clearer? wdyt? Agreed; swapped over. Indentation is a bit wacky because of the line limit, but should still be better overall.
Adding OWNERs for net/base/network_change_notifier.h, please take a look.
Paul and Szymon have been working in this area recently, sending it off to them.
lgtm. https://chromiumcodereview.appspot.com/10915043/diff/10004/net/android/networ... File net/android/network_change_notifier_android.cc (right): https://chromiumcodereview.appspot.com/10915043/diff/10004/net/android/networ... net/android/network_change_notifier_android.cc:46: case CONNECTION_UNKNOWN: I suggest: switch (connection_type) { case CONNECTION_UNKNOWN: case CONNECTION_ETHERNET: .... case CONNECTION_NONE: return connection_type; default: NOTREACHED(); } https://chromiumcodereview.appspot.com/10915043/diff/10004/net/base/network_c... File net/base/network_change_notifier.h (right): https://chromiumcodereview.appspot.com/10915043/diff/10004/net/base/network_c... net/base/network_change_notifier.h:42: CONNECTION_NONE = 6 // No connection. nit: align comment with above. This is adding mental tax when adding new types, but I'm assuming you want to be explicit because you have to be explicit in Java.
drive by comment nit based on frequent mark@ nits :) https://chromiumcodereview.appspot.com/10915043/diff/10004/net/android/java/s... File net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java (right): https://chromiumcodereview.appspot.com/10915043/diff/10004/net/android/java/s... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:94: // We've got mobile network of some sort. Use information from TelephonyManager to nit: Don't use "We" in comments
Thanks! I've addressed the nits as well as I could. https://chromiumcodereview.appspot.com/10915043/diff/10004/net/android/java/s... File net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java (right): https://chromiumcodereview.appspot.com/10915043/diff/10004/net/android/java/s... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:94: // We've got mobile network of some sort. Use information from TelephonyManager to On 2012/09/06 22:13:06, Ryan Sleevi wrote: > nit: Don't use "We" in comments Done. https://chromiumcodereview.appspot.com/10915043/diff/10004/net/android/networ... File net/android/network_change_notifier_android.cc (right): https://chromiumcodereview.appspot.com/10915043/diff/10004/net/android/networ... net/android/network_change_notifier_android.cc:46: case CONNECTION_UNKNOWN: On 2012/09/06 22:01:27, szym wrote: > I suggest: > switch (connection_type) { > case CONNECTION_UNKNOWN: > case CONNECTION_ETHERNET: > .... > case CONNECTION_NONE: > return connection_type; > default: > NOTREACHED(); > } Doesn't work because it's converting an int to a ConnectionType, unfortunately. https://chromiumcodereview.appspot.com/10915043/diff/10004/net/base/network_c... File net/base/network_change_notifier.h (right): https://chromiumcodereview.appspot.com/10915043/diff/10004/net/base/network_c... net/base/network_change_notifier.h:42: CONNECTION_NONE = 6 // No connection. On 2012/09/06 22:01:27, szym wrote: > nit: align comment with above. > > This is adding mental tax when adding new types, but I'm assuming you want to be > explicit because you have to be explicit in Java. Yeah, this was intentionally spelled out to make the mapping explicit. If someone adds a new type in between the numbering would go awry.
lgtm Thanks Dan!
Seems fine to me besides my one qualm. http://codereview.chromium.org/10915043/diff/7003/net/android/java/src/org/ch... File net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java (right): http://codereview.chromium.org/10915043/diff/7003/net/android/java/src/org/ch... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:110: case TelephonyManager.NETWORK_TYPE_HSPAP: I don't know much about the subject but is HSPA+ considered 4G? T-Mobile seems to market it as such, PC Mag seems to think it is (http://www.pcmag.com/article2/0,2817,2374564,00.asp) and more to the point I think the ITU (where the NetworkChangeNotifier's enum came from) also may considers it to be: http://www.itu.int/net/pressoffice/press_releases/2010/48.aspx when they refer to "evolved 3G" I think they may be referring to HSPA+ which is also known as "Evolved High-Speed Packet Access"
On 2012/09/07 13:07:52, pauljensen wrote: > Seems fine to me besides my one qualm. > > http://codereview.chromium.org/10915043/diff/7003/net/android/java/src/org/ch... > File net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java > (right): > > http://codereview.chromium.org/10915043/diff/7003/net/android/java/src/org/ch... > net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:110: > case TelephonyManager.NETWORK_TYPE_HSPAP: > I don't know much about the subject but is HSPA+ considered 4G? > T-Mobile seems to market it as such, PC Mag seems to think it is > (http://www.pcmag.com/article2/0%2C2817%2C2374564%2C00.asp) and more to the point I > think the ITU (where the NetworkChangeNotifier's enum came from) also may > considers it to be: > http://www.itu.int/net/pressoffice/press_releases/2010/48.aspx > when they refer to "evolved 3G" I think they may be referring to HSPA+ which is > also known as "Evolved High-Speed Packet Access" The classification comes from Android code, which has a comment saying that they classify conservatively when it isn't clear (https://github.com/android/platform_frameworks_base/blob/master/telephony/jav... line 613). I'm fine with diverging from their classifications, if it makes sense to do so.
On 2012/09/07 15:38:37, dfalcantara wrote: > On 2012/09/07 13:07:52, pauljensen wrote: > > Seems fine to me besides my one qualm. > > > > > http://codereview.chromium.org/10915043/diff/7003/net/android/java/src/org/ch... > > File > net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java > > (right): > > > > > http://codereview.chromium.org/10915043/diff/7003/net/android/java/src/org/ch... > > > net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:110: > > case TelephonyManager.NETWORK_TYPE_HSPAP: > > I don't know much about the subject but is HSPA+ considered 4G? > > T-Mobile seems to market it as such, PC Mag seems to think it is > > (http://www.pcmag.com/article2/0%252C2817%252C2374564%252C00.asp) and more to the > point I > > think the ITU (where the NetworkChangeNotifier's enum came from) also may > > considers it to be: > > http://www.itu.int/net/pressoffice/press_releases/2010/48.aspx > > when they refer to "evolved 3G" I think they may be referring to HSPA+ which > is > > also known as "Evolved High-Speed Packet Access" > > The classification comes from Android code, which has a comment saying that they > classify conservatively when it isn't clear > (https://github.com/android/platform_frameworks_base/blob/master/telephony/jav... > line 613). I'm fine with diverging from their classifications, if it makes > sense to do so. Going to leave it as is for now so that I can work on landing the unit tests. If we need to diverge from the Android classifications, we can do it in a follow-up CL; I'll be working on upstreaming our code in this area for a while.
On 2012/09/10 17:41:05, dfalcantara wrote: > On 2012/09/07 15:38:37, dfalcantara wrote: > > On 2012/09/07 13:07:52, pauljensen wrote: > > > Seems fine to me besides my one qualm. > > > > > > > > > http://codereview.chromium.org/10915043/diff/7003/net/android/java/src/org/ch... > > > File > > net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java > > > (right): > > > > > > > > > http://codereview.chromium.org/10915043/diff/7003/net/android/java/src/org/ch... > > > > > > net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:110: > > > case TelephonyManager.NETWORK_TYPE_HSPAP: > > > I don't know much about the subject but is HSPA+ considered 4G? > > > T-Mobile seems to market it as such, PC Mag seems to think it is > > > (http://www.pcmag.com/article2/0%25252C2817%25252C2374564%25252C00.asp) and more > to the > > point I > > > think the ITU (where the NetworkChangeNotifier's enum came from) also may > > > considers it to be: > > > http://www.itu.int/net/pressoffice/press_releases/2010/48.aspx > > > when they refer to "evolved 3G" I think they may be referring to HSPA+ which > > is > > > also known as "Evolved High-Speed Packet Access" > > > > The classification comes from Android code, which has a comment saying that > they > > classify conservatively when it isn't clear > > > (https://github.com/android/platform_frameworks_base/blob/master/telephony/jav... > > line 613). I'm fine with diverging from their classifications, if it makes > > sense to do so. > > Going to leave it as is for now so that I can work on landing the unit tests. > If we need to diverge from the Android classifications, we can do it in a > follow-up CL; I'll be working on upstreaming our code in this area for a while. Blarg; I couldn't fix the base URL with git cl baseurl, so I had to re-upload to https://chromiumcodereview.appspot.com/10913175/. Closing this one.
On 2012/09/10 18:35:32, dfalcantara wrote: > On 2012/09/10 17:41:05, dfalcantara wrote: > > On 2012/09/07 15:38:37, dfalcantara wrote: > > > On 2012/09/07 13:07:52, pauljensen wrote: > > > > Seems fine to me besides my one qualm. > > > > > > > > > > > > > > http://codereview.chromium.org/10915043/diff/7003/net/android/java/src/org/ch... > > > > File > > > net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java > > > > (right): > > > > > > > > > > > > > > http://codereview.chromium.org/10915043/diff/7003/net/android/java/src/org/ch... > > > > > > > > > > net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:110: > > > > case TelephonyManager.NETWORK_TYPE_HSPAP: > > > > I don't know much about the subject but is HSPA+ considered 4G? > > > > T-Mobile seems to market it as such, PC Mag seems to think it is > > > > (http://www.pcmag.com/article2/0%2525252C2817%2525252C2374564%2525252C00.asp) > and more > > to the > > > point I > > > > think the ITU (where the NetworkChangeNotifier's enum came from) also may > > > > considers it to be: > > > > http://www.itu.int/net/pressoffice/press_releases/2010/48.aspx > > > > when they refer to "evolved 3G" I think they may be referring to HSPA+ > which > > > is > > > > also known as "Evolved High-Speed Packet Access" > > > > > > The classification comes from Android code, which has a comment saying that > > they > > > classify conservatively when it isn't clear > > > > > > (https://github.com/android/platform_frameworks_base/blob/master/telephony/jav... > > > line 613). I'm fine with diverging from their classifications, if it makes > > > sense to do so. > > > > Going to leave it as is for now so that I can work on landing the unit tests. > > If we need to diverge from the Android classifications, we can do it in a > > follow-up CL; I'll be working on upstreaming our code in this area for a > while. > > Blarg; I couldn't fix the base URL with git cl baseurl, so I had to re-upload to > https://chromiumcodereview.appspot.com/10913175/. Closing this one. Hi guys. I came across this CL. I only took a brief look but I believe that the threading guarantees might be a bit brittle. They are not clear at least. NetworkChangeNotifier::GetCurrentConnectionType() is called from the network thread. However the Android implementation of NetworkChangeNotifier::GetCurrentConnectionType() calls some Java code (still from the network thread). This Java class is a singleton which is not only used by the native side of the NetworkChangeNotifier. We do use NetworkChangeNotifier (from the UI thread) too on the app side. This looks unsafe at a glance although I might be wrong. What do you guys think? I became fairly paranoiac since Ryan reviewed my Android Proxy Config Service CL :)
> Hi guys. I came across this CL. I only took a brief look but I believe that the > threading guarantees might be a bit brittle. They are not clear at least. > > NetworkChangeNotifier::GetCurrentConnectionType() is called from the network > thread. > However the Android implementation of > NetworkChangeNotifier::GetCurrentConnectionType() calls some Java code (still > from the network thread). This Java class is a singleton which is not only used > by the native side of the NetworkChangeNotifier. > We do use NetworkChangeNotifier (from the UI thread) too on the app side. > This looks unsafe at a glance although I might be wrong. What do you guys think? > I became fairly paranoiac since Ryan reviewed my Android Proxy Config Service CL > :) Not sure, Philippe. This CL only changed what information was being passed back, so whatever issue could have been there before would have been carried over. You should probably open another bug on this (separate from 6708211) so we can move discussion over to that.
On 2012/09/13 18:03:05, dfalcantara wrote: > Not sure, Philippe. This CL only changed what information was being passed > back, so whatever issue could have been there before would have been carried > over. You should probably open another bug on this (separate from 6708211) so > we can move discussion over to that. Well spotted Philippe. I think you're right that there's a threading issue here (since, AIUI, JNI should only be done on the UI thread). This issue looks to be pre-existing, but it does seem like it needs to be fixed. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
