Consider the following scenario where a captive portal requires an SMS based auth:

(1) Connect to the Wi-Fi. Android will display a system notification that says "Sign in to Wi-Fi network".
(2) Try signing in. The portal wants to send an SMS to your phone number before allowing internet access.
(3) Enter your phone number and get an auth code via SMS.
(4) There is now no apparent way to sign in to the portal again, because tapping the notification previously made it disappear. Android won't probe the portal soon, as it implements a backs off.

Assuming the user then visits an HTTPS URL, Chrome should call reportNetworkConnectivity to hint Android to probe the portal again. A name-mismatch SSL error is a good place to do this, as that's what most well-behaved captive portal interceptions should manifest.

 

Consider the following scenario where a captive portal requires an SMS based auth on a device with a cellular and Wi-Fi connections (captive portal is on Wi-Fi):

(1) Connect to the Wi-Fi. Android will display a system notification that says "Sign in to Wi-Fi network".
(2) Try signing in. The portal wants to send an SMS to your phone number before allowing internet access.
(3) Enter your phone number and get an auth code via SMS.
(4) There is now no apparent way to sign in to the portal again, because tapping the notification previously made it disappear. Android won't probe the portal soon, as it implements a backs off. Chrome only knows about the good network (cellular) so it can't show a captive portal interstitial.

Chrome should call reportNetworkConnectivity to hint Android to probe the portal again. This will trigger the "Sign in to Wi-Fi" notification again so that the user can login. A name-mismatch SSL error is a good place to do this, as that's what most well-behaved captive portal interceptions should manifest.