WiFiAfterConnect
WiFiAfterConnect copied to clipboard
sashavasko
Does not work w/ Android 5.0 Lollipop and Nexus 5
I've encountered the same on my Nexus 6 and Lollipop as well. And there is a workaround that I'm testing to see if it works permanently. When you pick the native OS captive portal login notification, there is a settings menu in upper right I have just found and you can pick "use network as-is" and when you do that, Android disables the new captive portal support in Lollipop so this app can take over. I'm waiting to see if the change persists next time I get a captive portal on the same SSID.
Another workaround is to disable cellular data.
This is new a feature now in Lollipop which is really good if you're NOT using this app. When you connect to a captive wifi, the OS hides this connection from the apps and leaves active the cell connection. Any apps including browser will continue to use cellular network and that includes this app, which thinks connection is fine (other apps I've tried don't even say wifi is connected).
The captive portal notification appears to launch a special browser that only it alone can access the wifi network. Once you authenticate that special browser leaves and only then do apps see wifi connection and can use it.
I'm not sure whether or not there is any new API in Lollipop that lets an app see the wifi point and use wifi network before the native captive portal block is lifted.
The "use network as-is" option on the native captive portal app is a one-time fix. I can't find a way for it to persist, or a way to disable Android's native captive portal detection. We can just hope there exists some API that lets apps see the wifi connection while the captive portal check is added or some quick 5.0.1 update that lets you disable captive portal checking preferably by SSID.
I think the App should use ConnectivityManager.
See here for code examples to make it work for Lolipop: https://github.com/pawitp/muwifi-autologin/commit/f045fe36f1fd98a106ea652e2d56f7ddfc871760
I see and understand the code and what it is doing. I see now that Android provides ample APIs to do what's needed. Since the author doesn't seem to be active I'll give this a try. Last time I did Android I targeted Gingerbread so it might be a bit until I'm set back up.
Native captive portal detection Is a major pain in a butt even in 4.2. I could not find any way to reliably disable it - system configuration keys differ from version to version and vendor to vendor ands require rooted phone. Judging by the code changes from 4.0 to 4.2 I was very certain that by 5.0 it will become an unsurmountable obstacle and did not have much hope for developing the app past Android 4.3. I myself do not have access to 5.0 device but from your comments I gather that my suspicions were correct. Anyway if anybody figures out a way to overcome I'll be happy to merge or even add as a developer to the project.
Thank you all for your support. I wish I could be more active, but sadly have not much time available.
That's OK, I will try it out. I see you already have code using ConnectivityManager, and ConnectivityManager has a way for you to select which network is being used. Essentially the device has multiple routes so we just need to pick one. You're targeting API 17, which has setNetworkPreference, deprecated in Lollipop. I don't know if setting that to wifi will let the app work under captive portal situation or not, but API 21 (Lollipop) seems to has the methods @stephankn mentioned.
My goal today is to build the project and install it on my phone.
I was able to build the app and I'm trying two changes:
- isWifiConnected returns true if WIFI is anything but DISCONNECTED detailed state (this is based on the fact that when wifi is disconnected, it shows disconnected. I need to see state when wifi is on but no access points in range).
- CheckRedirectService uses setProcessDefaultNetwork if API 21+, else uses setNetworkPreference
I have an IT background but am not a developer (anymore). If needed, I will be glad to help testing a new version IRL.
I've committed and pushed the changes I'm testing to gillius/WiFiAfterConnect branch lollipop. I've also included Gradle build files compatible with Android Studio, which requires Gradle to build (It can't use the Eclipse format). I tried to make two commits on two branches but somehow 2 commits on one branch came out. I'm fairly new to git...
I'll have to wait until I can reach the captive portal again to really confirm that this works.
My code works to keep the app on the wifi network and it sees the captive portal, but wifi state shows as disconnected so app doesn't try to authenticate and also WifiBroadcastReceiver receives no events that I can tell. I changed the "background" check that is normally called with auth type "None" to "IfNeeded" and then when opening the app, it triggers the check and then tries to auth. It works after that. So I'll need to figure out how to get the app to do it automatically -- to find out what event occurs when wifi connects to captive portal.
I have this working now for me, but I don't think in the best way (code's not pushed to GH yet but I can if people care before I get my final version). The WifiManager sends broadcasts which include the true wifi state but ConnectivityManager will continue to show wifi network as disconnected, so while I can trigger on the WifiManager event, the UI and wifi connection check will think wifi is off. So I change it to say Wifi is connected if the network is available, but then I believe app will show wifi as on and blocked when wifi is on but not associated yet. I need to test that still and find a workaround for tracking wifi state (probably I'll need to cache last WifiManager event)
When I said I had it working for me, I only thought I did... The app does do its job in that it detects captive portal and logs into it. But the native captive portal blocker never goes away. What I didn't realize is while it's around the default network remains cellular even though wifi is logged in. I hoped in worst case scenario native blocker would poll occasionally to recheck the portal but it doesn't. So far I can't find any way to fix this. I looked at the Android code -- the captive portal activity it sends an Intent, but I can't send the same Intent even if I wanted to because it requires the network ID as an "extra", which is not something the app can get as its an internal variable. If anyone knows a proper way to get the OS to bypass or recheck, let me know. So far the only thought I've had is to try disconnecting and reconnecting the wifi, but that might not work universally.
OK, I've committed the code that I've been using but I won't say that it's the efficient way to what I wanted to do. It's very conservative in triggering when it thinks wifi has changed to check for a portal. But I have been using it for some months now. It does work as I described earlier -- it authenticates the device but Android's native captive portal check notification remains and default network remains cell. But, at least I just need to click the notification and it goes away and I don't actually have to type in my login credentials, since activating the notification causes Android to recheck the connection. If anyone knows a way to activate that notification or trigger Android to recheck, let me know but I'm not an Android dev so I'm not even sure if it's possible.
My code is on lollipop branch, currently, gillius/WiFiAfterConnect@3eb5bdd9aa5e2cd9db16e4e2919dbc900fcb6943
Hi i've been fiddling with the captive portal detection of Lollipop as well because i wanted to request network on detected captive portals but i've ran into situations where i cut network avaialability system wide when using setProcessDefaultNetwork. Did you have similar expeirience?
I haven't seen any issues with my Nexus 6 and using setProcessDefaultNetwork that affect the system beyond the app itself.
maybe if its called from a service its affecting the app that started the service...
That would make sense, because in Android the app is all in the same process. So a service making that call would affect its associated activities (and other services, listeners, etc.)