Changed DnsPinger to use the system default DNS if linkprops doesn't
have a dns. This mirrors the behavior of the system overall.
Minor changes to wifiWatchdogService settings.
Change-Id: I8de73cf5bd24bc69343c7d9dc999d198195ec0ec
Complete rewrite of WifiWatchdogService.java. Checking for connectivity and managing wifi upon failure detection.
Change-Id: Ifcb8b5d7e0112cbc2f2282d76fdc93ea15527a44
DNS based techniques dont always work. Some hotspots
redirect on data fetch on IP. Use a known pattern match
on URL to detect a walled garden instead.
Also, added gservices capability to turn off the feature
or change the URL & the pattern to match
Bug: 4378442
Change-Id: I78b4208d3ea3ace20069169e7c01ed769892d94d
Use multiple DNS resolutions to the same IP address
as an indication to launch a web view for authentication
Bug: 4378442
Change-Id: Id3cf1e3c5b5bee4468665d0459ac945e5b12e730
When dealing with any kind of limited operating system resource,
we should ensure that we properly close everything that we
open, rather than relying on the system garbage collector.
Change-Id: Ic71f710eb85ac71a91b7a1215647c75010d37643
Killing the WifiWatchdogService thread from
WifiService can cause messages to be handled on
a dead thread. Quit the thread on the broadcast
instead.
A couple of more fixes:
- Do an asynchronous bring up of Wifi. This will
allow WifiWatchdogServiceThread to be immediately
brought up, instead of relying on an update.
- There is no need to listen on supplicant connection
in wifiwatchdog anymore. We kill the thread when
supplicant connection is no more.
Bug: 2546756
Change-Id: I15a188e031bc79856c55aabdd271287b0df0377d
We currently disable networks upon too many reconnects. This leads to asking
the user input for reconnects. Blacklist it instead.
Bug: 2129037
Change-Id: I23d69daf3964c066ed7f70d32fefb81016f19aa2
