Chromium Code Reviews
|
|
Chromium Code Reviews
Issue
2486393004:
Expose API to detect when captive portal probe was blocked on Android (Closed)
|
Created:
4 years, 1 month ago by tbansal1 Modified:
4 years ago Reviewers:
pauljensen CC:
chromium-reviews, cbentzel+watch_chromium.org, agrieve+watch_chromium.org Target Ref:
refs/pending/heads/master Project:
chromium Visibility:
Public. |
DescriptionExpose API to detect when captive portal probe was blocked on Android
This CL exposes an API which returns if the captive portal probe is
currently blocked.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester
BUG=476386
Committed: https://crrev.com/a7581d86b0e969c54b50045e5b0c6cabecc6407c
Cr-Commit-Position: refs/heads/master@{#434364}
Patch Set 1 : ps #Patch Set 2 : pauljensen comments #
Total comments: 15
Patch Set 3 : Move back to network library from NCN #
Total comments: 13
Patch Set 4 : Addressed pauljensen comments #Patch Set 5 : Add permission to AndroidManifest.xml for running the unittest #
Messages
Total messages: 53 (30 generated)
Description was changed from ========== Add API to detect when captive portal probe was blocked BUG= ========== to ========== Expose API to detect when captive portal probe was blocked on Android This CL exposes an API which returns if the captive portal probe is currently blocked. CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester BUG=476386 ==========
Patchset #1 (id:1) has been deleted
tbansal@chromium.org changed reviewers: + pauljensen@chromium.org
pauljensen, I think this is what we discussed last week. Please let me know what you think. I tried it on a captive portal network, and it was returning correct result. Thanks!!
The CQ bit was checked by tbansal@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: linux_android_rel_ng on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/linux_androi...)
The CQ bit was checked by tbansal@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
Patchset #1 (id:20001) has been deleted
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)
I thought you were going to use the data compression proxy canary URL probe to see if there is a captive portal in place? Why do you care about *any* network having a captive portal in place? If Android is smart enough to keep the default network on a non-captive-portal (e.g. cellular), then why do we care if other networks that Chrome isn't using (e.g. WiFi on a captive portal) have captive portals in place? I imagine it shouldn't affect Chrome if non-default networks have captive portals in place.
On 2016/11/10 13:43:25, pauljensen wrote: > I thought you were going to use the data compression proxy canary URL probe to > see if there is a captive portal in place? That's already in place, and if the URL probe fails, Chrome stops using secure DRP proxies (it only uses http port 80 proxy which the captive portal should be able to intercept). However, if Chrome is started with an intent on Android, the failure of the URL probe happens after the first request goes off on HTTPS DRP proxy. If the captive portal is blackholing HTTPS packets, then that request will take a long time to timeout. Even though the URL probe fails quickly afterwards, we have no way to restart the request via HTTP proxies. In those cases, this check (from this CL) would come handy. When the first request comes in (and the probe URL is still pending), DRP will check the presence of captive portal, and will stop using HTTPS proxies if there is a captive portal in place. > Why do you care about *any* network having a captive portal in place? If > Android is smart enough to keep the default network on a non-captive-portal > (e.g. cellular), then why do we care if other networks that Chrome isn't using > (e.g. WiFi on a captive portal) have captive portals in place? I imagine it > shouldn't affect Chrome if non-default networks have captive portals in place. I agree, and I was not sure what exactly to do here. API getAllNetworks() is available on Lollipop and above. getActiveNetwork is on M and above. I went with the first one to get more API coverage at the cost of slightly inaccurate result. This slightly inaccurate result is fine with DRP use case (we would just end up not using secure proxies if at least one network had CP). But, we will get more API coverage, and fewer blackholed navigations. wdyt?
On 2016/11/10 16:42:16, tbansal1 wrote: > On 2016/11/10 13:43:25, pauljensen wrote: > > I thought you were going to use the data compression proxy canary URL probe to > > see if there is a captive portal in place? > That's already in place, and if the URL probe fails, Chrome stops > using secure DRP proxies (it only uses http port 80 proxy which > the captive portal should be able to intercept). > > However, if Chrome is started with an intent on Android, the failure > of the URL probe happens after the first request goes off on HTTPS > DRP proxy. If the captive portal is blackholing HTTPS packets, then that > request will take a long time to timeout. Even though the URL probe fails > quickly afterwards, we have no way to restart the request via HTTP > proxies. Seems like you could just cancel it and restart over HTTP. > In those cases, this check (from this CL) would come handy. > When the first request comes in (and the probe URL is still pending), > DRP will check the presence of captive portal, and will stop using > HTTPS proxies if there is a captive portal in place. > > > Why do you care about *any* network having a captive portal in place? If > > Android is smart enough to keep the default network on a non-captive-portal > > (e.g. cellular), then why do we care if other networks that Chrome isn't using > > (e.g. WiFi on a captive portal) have captive portals in place? I imagine it > > shouldn't affect Chrome if non-default networks have captive portals in place. > I agree, and I was not sure what exactly to do here. API getAllNetworks() > is available on Lollipop and above. getActiveNetwork is on M and above. > I went with the first one to get more API coverage at the cost of slightly > inaccurate result. This slightly inaccurate result is fine with > DRP use case (we would just end up not using secure proxies if at least > one network had CP). But, we will get more API coverage, and fewer blackholed > navigations. wdyt? Use getDefaultNetId(): https://cs.chromium.org/chromium/src/net/android/java/src/org/chromium/net/Ne... You may want to make a tiny refactor to make it return a Network instead of a NetID.
On 2016/11/11 13:57:49, pauljensen wrote: > On 2016/11/10 16:42:16, tbansal1 wrote: > > On 2016/11/10 13:43:25, pauljensen wrote: > > > I thought you were going to use the data compression proxy canary URL probe > to > > > see if there is a captive portal in place? > > That's already in place, and if the URL probe fails, Chrome stops > > using secure DRP proxies (it only uses http port 80 proxy which > > the captive portal should be able to intercept). > > > > However, if Chrome is started with an intent on Android, the failure > > of the URL probe happens after the first request goes off on HTTPS > > DRP proxy. If the captive portal is blackholing HTTPS packets, then that > > request will take a long time to timeout. Even though the URL probe fails > > quickly afterwards, we have no way to restart the request via HTTP > > proxies. > > Seems like you could just cancel it and restart over HTTP. Thanks for the help. How would DRP go about cancelling it? DRP has both NetworkDelegate and ProxyDelegate hooks, but those classes do not provide a way to cancel in-flight requests. DRP can do something more intrusive by keeping track of in-flight requests in some data structure, but that's probably not a good approach. > > > In those cases, this check (from this CL) would come handy. > > When the first request comes in (and the probe URL is still pending), > > DRP will check the presence of captive portal, and will stop using > > HTTPS proxies if there is a captive portal in place. > > > > > Why do you care about *any* network having a captive portal in place? If > > > Android is smart enough to keep the default network on a non-captive-portal > > > (e.g. cellular), then why do we care if other networks that Chrome isn't > using > > > (e.g. WiFi on a captive portal) have captive portals in place? I imagine it > > > shouldn't affect Chrome if non-default networks have captive portals in > place. > > I agree, and I was not sure what exactly to do here. API getAllNetworks() > > is available on Lollipop and above. getActiveNetwork is on M and above. > > I went with the first one to get more API coverage at the cost of slightly > > inaccurate result. This slightly inaccurate result is fine with > > DRP use case (we would just end up not using secure proxies if at least > > one network had CP). But, we will get more API coverage, and fewer blackholed > > navigations. wdyt? > > Use getDefaultNetId(): > https://cs.chromium.org/chromium/src/net/android/java/src/org/chromium/net/Ne... > You may want to make a tiny refactor to make it return a Network instead of a > NetID.
On 2016/11/11 13:57:49, pauljensen wrote: > On 2016/11/10 16:42:16, tbansal1 wrote: > > On 2016/11/10 13:43:25, pauljensen wrote: > > > I thought you were going to use the data compression proxy canary URL probe > to > > > see if there is a captive portal in place? > > That's already in place, and if the URL probe fails, Chrome stops > > using secure DRP proxies (it only uses http port 80 proxy which > > the captive portal should be able to intercept). > > > > However, if Chrome is started with an intent on Android, the failure > > of the URL probe happens after the first request goes off on HTTPS > > DRP proxy. If the captive portal is blackholing HTTPS packets, then that > > request will take a long time to timeout. Even though the URL probe fails > > quickly afterwards, we have no way to restart the request via HTTP > > proxies. > > Seems like you could just cancel it and restart over HTTP. > > > In those cases, this check (from this CL) would come handy. > > When the first request comes in (and the probe URL is still pending), > > DRP will check the presence of captive portal, and will stop using > > HTTPS proxies if there is a captive portal in place. > > > > > Why do you care about *any* network having a captive portal in place? If > > > Android is smart enough to keep the default network on a non-captive-portal > > > (e.g. cellular), then why do we care if other networks that Chrome isn't > using > > > (e.g. WiFi on a captive portal) have captive portals in place? I imagine it > > > shouldn't affect Chrome if non-default networks have captive portals in > place. > > I agree, and I was not sure what exactly to do here. API getAllNetworks() > > is available on Lollipop and above. getActiveNetwork is on M and above. > > I went with the first one to get more API coverage at the cost of slightly > > inaccurate result. This slightly inaccurate result is fine with > > DRP use case (we would just end up not using secure proxies if at least > > one network had CP). But, we will get more API coverage, and fewer blackholed > > navigations. wdyt? > > Use getDefaultNetId(): > https://cs.chromium.org/chromium/src/net/android/java/src/org/chromium/net/Ne... > You may want to make a tiny refactor to make it return a Network instead of a > NetID. Done. Now, using the NCN plumbing to get the default network.
pauljensen: ptal at PS# 2. Thanks.
On 2016/11/11 18:04:01, tbansal1 wrote: > On 2016/11/11 13:57:49, pauljensen wrote: > > On 2016/11/10 16:42:16, tbansal1 wrote: > > > On 2016/11/10 13:43:25, pauljensen wrote: > > > > I thought you were going to use the data compression proxy canary URL > probe > > to > > > > see if there is a captive portal in place? > > > That's already in place, and if the URL probe fails, Chrome stops > > > using secure DRP proxies (it only uses http port 80 proxy which > > > the captive portal should be able to intercept). > > > > > > However, if Chrome is started with an intent on Android, the failure > > > of the URL probe happens after the first request goes off on HTTPS > > > DRP proxy. If the captive portal is blackholing HTTPS packets, then that > > > request will take a long time to timeout. Even though the URL probe fails > > > quickly afterwards, we have no way to restart the request via HTTP > > > proxies. > > > > Seems like you could just cancel it and restart over HTTP. > Thanks for the help. How would DRP go about cancelling it? > DRP has both NetworkDelegate and ProxyDelegate hooks, but those classes > do not provide a way to cancel in-flight requests. > > DRP can do something more intrusive by keeping track of in-flight > requests in some data structure, but that's probably not a > good approach. I don't know much about how DRP works. You can always cancel URLRequests via Cancel().
https://codereview.chromium.org/2486393004/diff/60001/net/android/java/src/or... File net/android/java/src/org/chromium/net/NetworkChangeNotifier.java (right): https://codereview.chromium.org/2486393004/diff/60001/net/android/java/src/or... net/android/java/src/org/chromium/net/NetworkChangeNotifier.java:101: * Returns true if the captive portal probe was blocked for the current network. current->current default https://codereview.chromium.org/2486393004/diff/60001/net/android/java/src/or... net/android/java/src/org/chromium/net/NetworkChangeNotifier.java:104: * Only available on Lollipop and newer releases. Mention what is returned on older releases. https://codereview.chromium.org/2486393004/diff/60001/net/android/java/src/or... net/android/java/src/org/chromium/net/NetworkChangeNotifier.java:104: * Only available on Lollipop and newer releases. Lollipop->Marshmallow https://codereview.chromium.org/2486393004/diff/60001/net/android/java/src/or... File net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java (right): https://codereview.chromium.org/2486393004/diff/60001/net/android/java/src/or... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:224: * Returns the current default network. Returns null if no current default network null->{@code null} https://codereview.chromium.org/2486393004/diff/60001/net/android/java/src/or... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:228: Network getDefaultNet() { private https://codereview.chromium.org/2486393004/diff/60001/net/android/java/src/or... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:228: Network getDefaultNet() { Net->Network https://codereview.chromium.org/2486393004/diff/60001/net/android/java/src/or... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:277: * Only available on Lollipop and newer releases. Mention what is returned on older releases. https://codereview.chromium.org/2486393004/diff/60001/net/android/java/src/or... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:277: * Only available on Lollipop and newer releases. Lollipop->Marshmallow NET_CAPABILITIES was only added in Marshmallow. https://codereview.chromium.org/2486393004/diff/60001/net/android/java/src/or... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:279: @TargetApi(Build.VERSION_CODES.LOLLIPOP) LOLLIPOP->MARSHMALLOW https://codereview.chromium.org/2486393004/diff/60001/net/android/java/src/or... net/android/java/src/org/chromium/net/NetworkChangeNotifierAutoDetect.java:849: if (Build.VERSION.SDK_INT < Build.VERSION_CODES.LOLLIPOP) { LOLLIPOP->MARSHMALLOW https://codereview.chromium.org/2486393004/diff/60001/net/base/network_change... File net/base/network_change_notifier.h (right): https://codereview.chromium.org/2486393004/diff/60001/net/base/network_change... net/base/network_change_notifier.h:331: // Returns true if the captive portal probe was blocked for the current "the captive portal probe was blocked for"->"the system detected a captive portal was present on" https://codereview.chromium.org/2486393004/diff/60001/net/base/network_change... net/base/network_change_notifier.h:332: // network. May incorrectly return true if the user has signed into the network->default network https://codereview.chromium.org/2486393004/diff/60001/net/base/network_change... net/base/network_change_notifier.h:334: // Lollipop and newer releases. Lollipop->Marshmallow https://codereview.chromium.org/2486393004/diff/60001/net/base/network_change... net/base/network_change_notifier.h:334: // Lollipop and newer releases. Mention it's only available on Android https://codereview.chromium.org/2486393004/diff/60001/net/base/network_change... net/base/network_change_notifier.h:334: // Lollipop and newer releases. Mention what is returned if unavailable
Patchset #3 (id:80001) has been deleted
pauljensen: ptal. I moved the API back to AndroidNetworkLibrary.java to minimize the plumbing. Since the API is now targeted for Marshmallow and above, it should be okay to keep it in AndroidNetworkLibrary.java. Let me know what you think. Thanks for the review.
On 2016/11/16 15:45:14, pauljensen wrote: > On 2016/11/11 18:04:01, tbansal1 wrote: > > On 2016/11/11 13:57:49, pauljensen wrote: > > > On 2016/11/10 16:42:16, tbansal1 wrote: > > > > On 2016/11/10 13:43:25, pauljensen wrote: > > > > > I thought you were going to use the data compression proxy canary URL > > probe > > > to > > > > > see if there is a captive portal in place? > > > > That's already in place, and if the URL probe fails, Chrome stops > > > > using secure DRP proxies (it only uses http port 80 proxy which > > > > the captive portal should be able to intercept). > > > > > > > > However, if Chrome is started with an intent on Android, the failure > > > > of the URL probe happens after the first request goes off on HTTPS > > > > DRP proxy. If the captive portal is blackholing HTTPS packets, then that > > > > request will take a long time to timeout. Even though the URL probe fails > > > > quickly afterwards, we have no way to restart the request via HTTP > > > > proxies. > > > > > > Seems like you could just cancel it and restart over HTTP. > > Thanks for the help. How would DRP go about cancelling it? > > DRP has both NetworkDelegate and ProxyDelegate hooks, but those classes > > do not provide a way to cancel in-flight requests. > > > > DRP can do something more intrusive by keeping track of in-flight > > requests in some data structure, but that's probably not a > > good approach. > > I don't know much about how DRP works. You can always cancel URLRequests via > Cancel(). Yes, but cancelling the request will require DRP to keep a list of in-flight requests. I think that's a bit intrusive since the net APIs (NetworkDelegate and ProxyDelegate) do not support this. mmenke@ has in the past commented that keeping track of requests is a bad idea, so I am currently going by that. See mmenke's comment here: https://bugs.chromium.org/p/chromium/issues/detail?id=662137 "Beyond the fact that tracking requests has historically proven problematic...". Let me know your thoughts.
pauljensen: ping. Thanks.
lgtm modulo comments https://codereview.chromium.org/2486393004/diff/100001/net/android/java/src/o... File net/android/java/src/org/chromium/net/AndroidNetworkLibrary.java (right): https://codereview.chromium.org/2486393004/diff/100001/net/android/java/src/o... net/android/java/src/org/chromium/net/AndroidNetworkLibrary.java:200: * Returns true if the captive portal probe was blocked for the current network. The method captive->system's captive current->current default data https://codereview.chromium.org/2486393004/diff/100001/net/android/java/src/o... net/android/java/src/org/chromium/net/AndroidNetworkLibrary.java:201: * would return false if the captive portal probe was not blocked on the current network, the would->will https://codereview.chromium.org/2486393004/diff/100001/net/android/java/src/o... net/android/java/src/org/chromium/net/AndroidNetworkLibrary.java:201: * would return false if the captive portal probe was not blocked on the current network, the remove "on the current network" https://codereview.chromium.org/2486393004/diff/100001/net/android/java/src/o... net/android/java/src/org/chromium/net/AndroidNetworkLibrary.java:219: // later versions. Can we move this comment up to right before line 209? https://codereview.chromium.org/2486393004/diff/100001/net/android/network_li... File net/android/network_library.h (right): https://codereview.chromium.org/2486393004/diff/100001/net/android/network_li... net/android/network_library.h:74: // Returns true if the captive portal probe was blocked for the current network. Same comments as in previous file https://codereview.chromium.org/2486393004/diff/100001/net/android/network_li... File net/android/network_library_unittest.cc (right): https://codereview.chromium.org/2486393004/diff/100001/net/android/network_li... net/android/network_library_unittest.cc:13: namespace { Remove the anonymous namespace
https://codereview.chromium.org/2486393004/diff/100001/net/android/java/src/o... File net/android/java/src/org/chromium/net/AndroidNetworkLibrary.java (right): https://codereview.chromium.org/2486393004/diff/100001/net/android/java/src/o... net/android/java/src/org/chromium/net/AndroidNetworkLibrary.java:200: * Returns true if the captive portal probe was blocked for the current network. The method On 2016/11/24 00:11:19, pauljensen wrote: > captive->system's captive > current->current default data Done. https://codereview.chromium.org/2486393004/diff/100001/net/android/java/src/o... net/android/java/src/org/chromium/net/AndroidNetworkLibrary.java:201: * would return false if the captive portal probe was not blocked on the current network, the On 2016/11/24 00:11:19, pauljensen wrote: > would->will Done. https://codereview.chromium.org/2486393004/diff/100001/net/android/java/src/o... net/android/java/src/org/chromium/net/AndroidNetworkLibrary.java:201: * would return false if the captive portal probe was not blocked on the current network, the On 2016/11/24 00:11:19, pauljensen wrote: > remove "on the current network" Done. https://codereview.chromium.org/2486393004/diff/100001/net/android/java/src/o... net/android/java/src/org/chromium/net/AndroidNetworkLibrary.java:219: // later versions. On 2016/11/24 00:11:19, pauljensen wrote: > Can we move this comment up to right before line 209? Done. https://codereview.chromium.org/2486393004/diff/100001/net/android/network_li... File net/android/network_library.h (right): https://codereview.chromium.org/2486393004/diff/100001/net/android/network_li... net/android/network_library.h:74: // Returns true if the captive portal probe was blocked for the current network. On 2016/11/24 00:11:19, pauljensen wrote: > Same comments as in previous file Done. https://codereview.chromium.org/2486393004/diff/100001/net/android/network_li... File net/android/network_library_unittest.cc (right): https://codereview.chromium.org/2486393004/diff/100001/net/android/network_li... net/android/network_library_unittest.cc:13: namespace { On 2016/11/24 00:11:19, pauljensen wrote: > Remove the anonymous namespace Done. Is this a //net specific guideline? A cursory search on chromium-dev suggests that it is okay (if not preferable) to put tests in anonymous namespaces. https://groups.google.com/a/chromium.org/d/msg/chromium-dev/MwPIo2BnVhM/wvZxl... https://groups.google.com/a/chromium.org/d/msg/chromium-dev/pKY2G4GHcu0/398sq...
The CQ bit was checked by tbansal@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
lgtm https://codereview.chromium.org/2486393004/diff/100001/net/android/network_li... File net/android/network_library_unittest.cc (right): https://codereview.chromium.org/2486393004/diff/100001/net/android/network_li... net/android/network_library_unittest.cc:13: namespace { On 2016/11/24 00:43:09, tbansal1 wrote: > On 2016/11/24 00:11:19, pauljensen wrote: > > Remove the anonymous namespace > > Done. Is this a //net specific guideline? > A cursory search on chromium-dev suggests that it is okay (if not preferable) to > put tests in anonymous namespaces. > > https://groups.google.com/a/chromium.org/d/msg/chromium-dev/MwPIo2BnVhM/wvZxl... > > https://groups.google.com/a/chromium.org/d/msg/chromium-dev/pKY2G4GHcu0/398sq... I don't feel strongly. There are pros and cons to both.
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: android_n5x_swarming_rel on master.tryserver.chromium.android (JOB_FAILED, https://build.chromium.org/p/tryserver.chromium.android/builders/android_n5x_...)
The CQ bit was checked by tbansal@chromium.org to run a CQ dry run
Dry run: CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Dry run: Try jobs failed on following builders: blimp_linux_dbg on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL) cast_shell_linux on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL) chromeos_amd64-generic_chromium_compile_only_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL) chromeos_daisy_chromium_compile_only_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL) chromeos_x86-generic_chromium_compile_only_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL) linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL) linux_chromium_chromeos_compile_dbg_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL) linux_chromium_chromeos_ozone_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL) linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL) linux_chromium_compile_dbg_ng on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL)
The CQ bit was checked by tbansal@chromium.org
The patchset sent to the CQ was uploaded after l-g-t-m from pauljensen@chromium.org Link to the patchset: https://codereview.chromium.org/2486393004/#ps140001 (title: "Add permission to AndroidManifest.xml for running the unittest")
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: blimp_linux_dbg on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL)
The CQ bit was checked by tbansal@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
The CQ bit was unchecked by commit-bot@chromium.org
Try jobs failed on following builders: chromium_presubmit on master.tryserver.chromium.linux (JOB_TIMED_OUT, no build URL)
The CQ bit was checked by tbansal@chromium.org
CQ is trying da patch. Follow status at https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...
CQ is committing da patch.
Bot data: {"patchset_id": 140001, "attempt_start_ts": 1480009808012280,
"parent_rev": "432dfb78f6f47a622bd51012a0bcccb7460679ed", "commit_rev":
"38a2d9243a0111a86fab468e25c7c27a55d043cc"}
Message was sent while issue was closed.
Description was changed from ========== Expose API to detect when captive portal probe was blocked on Android This CL exposes an API which returns if the captive portal probe is currently blocked. CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester BUG=476386 ========== to ========== Expose API to detect when captive portal probe was blocked on Android This CL exposes an API which returns if the captive portal probe is currently blocked. CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester BUG=476386 ==========
Message was sent while issue was closed.
Committed patchset #5 (id:140001)
Message was sent while issue was closed.
Description was changed from ========== Expose API to detect when captive portal probe was blocked on Android This CL exposes an API which returns if the captive portal probe is currently blocked. CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester BUG=476386 ========== to ========== Expose API to detect when captive portal probe was blocked on Android This CL exposes an API which returns if the captive portal probe is currently blocked. CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.android:android_cronet_tester BUG=476386 Committed: https://crrev.com/a7581d86b0e969c54b50045e5b0c6cabecc6407c Cr-Commit-Position: refs/heads/master@{#434364} ==========
Message was sent while issue was closed.
Patchset 5 (id:??) landed as https://crrev.com/a7581d86b0e969c54b50045e5b0c6cabecc6407c Cr-Commit-Position: refs/heads/master@{#434364} |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
