2012-08-14 12 views
15

La mia università ha un punto di accesso Wi-Fi aperto, tuttavia richiede di inserire la tua e-mail prima che ti permetta di utilizzare il web. Il mio problema è che la connessione Wifi è stupida in quanto sembra che la mia connessione si interrompa e mi costringa a inserire di nuovo la mia e-mail ogni 10 minuti.Android - Rileva se il Wi-Fi richiede l'accesso al browser

Volevo creare la mia app che posso utilizzare per eseguire automaticamente questo passaggio per me, ma non riesco a trovare alcuna documentazione per un modo semplice e facile per rilevare se un punto di accesso Wi-Fi ha una pagina di accesso del browser. C'è un modo in Android per ottenere queste informazioni, o è solo per vedere se la mia connessione a qualcosa viene sempre reindirizzata a 1.1.1.1?

+0

Invia una richiesta HTTP a google.com e vedere cosa succede. – SLaks

risposta

15

Vedere la sezione "Gestione della rete Sign-On" di the HttpUrlConnection documentation:

Alcune reti Wi-Fi bloccare l'accesso a Internet fino a quando l'utente fa clic attraverso un sign-on pagina. Tali pagine di accesso vengono in genere presentate utilizzando reindirizzamenti HTTP. È possibile utilizzare getURL() per verificare se la connessione è stata reindirizzata in modo imprevisto. Questo controllo non è valido fino a dopo la ricezione delle intestazioni di risposta, che è possibile attivare chiamando getHeaderFields() o getInputStream().

Hanno uno snippet di codice di esempio. Non so se questo copra il tuo particolare AP WiFi, ma vale la pena provarlo.

+1

L'ho implementato e funziona bene quando il redirect cambia il nome dell'host, ma altri no. Ad esempio, questo router Belkin lascia tutto ciò che è stato digitato nel browser così com'è, ma mostra comunque la propria pagina. urlConnection.getUrl(). getHost() restituisce ciò che dovrebbe a causa di questo. Qualche suggerimento in quel caso? In che modo Android rileva la connettività stessa? Cioè le icone arancione vs bianco Wifi/dati. – Flyview

+0

Non c'è altro modo per convalidare questo? Questo approccio è soggetto a errori. Nell'esempio è descritto ciò che @Flyview ha descritto. Il suo approccio di seguito è anche soggetto a errori (vedere i commenti sulla risposta sotto). – neteinstein

+0

@NeTeInStEiN: "Questo approccio è soggetto ad errori" - ciò dipende dalle circostanze, immagino. Per definizione, non è possibile gestire lo scenario di Flyview in generale, poiché una risposta '200 OK' dal captive portal per l'URL è indistinguibile (di nuovo, in generale) da una risposta' 200 OK' dal sito reale colpito. Con HTTPS, puoi verificare i certificati per vedere se è o meno il server giusto e questo dovrebbe essere un test più definitivo. – CommonsWare

3

Ping un indirizzo IP esterno (come google.com) per vedere se risponde.

try { 
     Runtime runtime = Runtime.getRuntime(); 
     Process proc = runtime.exec("ping -c 1 " + "google.com"); 
     proc.waitFor();  
     int exitCode = proc.exitValue(); 
     if(exitCode == 0) { 
      Log.d("Ping", "Ping successful!"; 
     } else { 
      Log.d("Ping", "Ping unsuccessful."); 
     } 
    } 
    catch (IOException e) {} 
    catch (InterruptedException e) {} 

L'unico inconveniente è questo sarebbe anche indicare che un account di accesso web è necessaria quando semplicemente non c'è connettività internet sul punto di accesso Wi-Fi.

@CommonsWare Credo che questa sia una risposta migliore dell'apertura di un UrlConnection e del controllo dell'host, poiché l'host non cambia sempre anche quando si visualizza la pagina di reindirizzamento. Ad esempio, ho provato su un router Belkin e lascia tutto quello che hai digitato nel browser così com'è, ma mostra ancora la sua pagina. urlConnection.getUrl(). getHost() restituisce ciò che dovrebbe a causa di questo.

+0

Anche questo non risolve il problema visto che quando ti connetti potresti ancora dover effettuare il login, ma dopo un po ' effettua il login tramite la pagina web, e quando lo fai non ricevi alcun evento per avvertirti che qualcosa è cambiato per te per testare nuovamente la tua connettività ... – neteinstein

0

Il problema potrebbe essere - almeno oggi - che le versioni Android più recenti (5.1+?) Mantengono attiva la connessione 3G/4G finché il login wifi non porta effettivamente a una connessione wifi pienamente funzionante.

Non l'ho provato, ma forse con il valore enum CAPTIVE_PORTAL_CHECK di NetworkInfo s DetailedState si può provare a rilevare correttamente una tale modalità?

+1

Il CAPTIVE_PORTAL_CHECK è uno stato transitorio e lo stato finale sarà COLLEGATO anche se sei connesso a un Captive Wifi. Il modo (che ha funzionato per me) per verificare la presenza di Captive Wifi è provare a connettersi a un sito Web e verificare se vieni reindirizzato a un altro URL. – rsc

1

Penso che @FlyWheel sia sulla strada giusta, ma vorrei usare http://clients1.google.com/generate_204 e se non ottieni un 204, sai di essere dietro un captive portal. È possibile eseguire questo in un ciclo fino a quando non si ottiene un 204 nel qual caso si sa che non si è più dietro un captive portal.

@FlyWheel ha scritto: L'unico svantaggio è che ciò significherebbe anche che è richiesto un accesso Web quando non c'è semplicemente la connettività Internet sul punto di accesso WiFi.

È possibile risolvere questo registrando un ricevitore per android.net.conn.CONNECTIVITY_CHANGE. È possibile verificare se il Wi-Fi è attivo ed è connesso osservando lo stato supplicante della connessione.

Ecco un frammento, ma non ho eseguirlo:

WifiManager wm = (WifiManager) context.getSystemService(Context.WIFI_SERVICE); 
WifiInfo wifiInfo = wm.getConnectionInfo(); 
SupplicantState suppState = wifiInfo.getSupplicantState(); 

if (wm.isWifiEnabled()) { 
    if (suppState == SupplicantState.COMPLETED){ 
     // TODO - while loop checking generate_204 (FlyWheels code)Using intent service. 
    } 
} 

non riesco a ricordare se il SupplicantState è completato o associati, si dovrà verificare che. È necessario utilizzare IntentService per verificare il generate_204 poiché i ricevitori di trasmissione hanno una vita breve.