I wish to detect if a user has enabled both background data (settings->accounts and sync->background data) and packet data (settings->wireless and network->mobile networks->use packet data) so I can inform the user how to enable them.
This link says how to test the background data but it has been deprecated. The recommendation says to use getActiveNetworkInfo() but this might return the WIFI connection and therefore not display if background data is enabled or not.
I have not found any links on how to detect if packet data is enabled or not.
I had this exact same question and I had to start a bounty to get the answer. Cost me a third of my reputation, but well worth it.
boolean mobileDataEnabled = false; // Assume disabled
ConnectivityManager cm1 = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
try {
Class cmClass = Class.forName(cm1.getClass().getName());
Method method = cmClass.getDeclaredMethod("getMobileDataEnabled");
method.setAccessible(true); // Make the method callable
// get the setting for "mobile data"
mobileDataEnabled = (Boolean)method.invoke(cm1);
} catch (Exception e) {
// Some problem accessible private API
// TODO do whatever error handling you want here
}
As I say, I cant claim credit for know this, my question was answered by https://stackoverflow.com/users/769265/david-wasser
but it cost me, so if you want to accept this as an answer I can start to get me some of my reputation points back! :)
Related
I created a function that returns a boolean based on the presence of an internet connection, this function it is called different times from different java classes.
The only way that I find to use it is to use the StrictMode.setThreadPolicy (i know that it's not a good practice).
How I can solve my problem ?
public boolean checkConnection() {
boolean response = false;
try {
//StrictMode.setThreadPolicy(new StrictMode.ThreadPolicy.Builder().permitAll().build());
ConnectivityManager connectivityManager = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
if (connectivityManager != null) {
NetworkInfo networkInfo = connectivityManager.getActiveNetworkInfo();
if (networkInfo != null && networkInfo.isConnected()) {
URL url = new URL(databaseManagement.getSettingValue("urlCheckConnection", context));
HttpURLConnection httpURLConnection = (HttpURLConnection) url.openConnection();
httpURLConnection.setConnectTimeout(3000);
httpURLConnection.setReadTimeout(3000);
httpURLConnection.connect();
response = httpURLConnection.getResponseCode() == 200;
httpURLConnection.disconnect();
httpURLConnection.getInputStream().close();
}
}
} catch (Exception e) {
response = false;
wil.WriteFile("checkConnection - Exception: " + e.getMessage(), context);
}
return response;
}
It is possible that this method will block the calling thread for up to 3 seconds. Generally speaking you should not do network or file I/O on the main (UI) thread because that can cause the app to appear non-responsive (and Android will generate an ANR exception in that case). There are various alternatives you could use, depending on your situation. Here are two:
Don't ever call this method on the main (UI) thread. Always perform your Internet connectivity checks on background threads
Make the method asynchronous and provide a callback interface. The caller would then call the method (which will return immediately after launching the connectivity check on a background thread) and then the callback would be triggered when the connectivity check is completed. If this must be done on the main (UI) thread, you should show a progress dialog or similar while you are executing the connectivity check so that the user doesn't think the app is stuck.
Your question is a bit unclear.
Here is how internet connection is checked in my app:
private fun isConnected(): Boolean {
val connMgr = context.getSystemService(Context.CONNECTIVITY_SERVICE) as ConnectivityManager
val networkInfo: NetworkInfo? = connMgr.activeNetworkInfo
return networkInfo?.isConnected == true
}
It still should be tested on the latest Android APIs as there are known changes, e.g. lack of options to emulate network on\off programmatically from tests since some specific version of Android API.
On another hand StrictMode is used to force you and all the rest software developers to write correct programs. Your code which operates with network and data storages should not be executed in the main thread (which is done by default), it should be run in the separate thread. StrictMode tracks this and notify you about violation of this practice either by warning message in logs or by crashing your app (I prefer second one as it is more obvious).
However sometimes you depend on 3rd party library which violates this good practices and keeping yourStrictMode enabled prevents you from using this library.
In any cases StrictMode is usually enabled only for development stage like this:
if (BuildConfig.DEBUG) {
// TODO enable StrictMode policies
}
I am currently using a background IntentService in my Android App to connect to my server to fetch some data and update the App only if connection is available. If the device is connected to mobile network data or a authenticated wifi connection or open wifi connection it works perfectly.
The problem occurs when the device does not have access to Mobile Data Network and is connected to a Wifi source that requires authentication and the connection is not authenticated yet, the service force closes since it is unable to transfer any data through the unauthenticated connection.
My check to the entry point to connect to the server and do the background task is the check below.
ConnectivityManager conMgr = (ConnectivityManager)getSystemService(Context.CONNECTIVITY_SERVICE);
if((conMgr.getActiveNetworkInfo() != null &&
conMgr.getActiveNetworkInfo().isAvailable() &&
conMgr.getActiveNetworkInfo().isConnected()) || WifiConnected() == true){
//do background processing
}
The WifiConnected() method looks like this below.
private boolean WifiConnected() {
ConnectivityManager connMgr = (ConnectivityManager) getSystemService(Context.CONNECTIVITY_SERVICE);
NetworkInfo networkInfo = connMgr.getNetworkInfo(ConnectivityManager.TYPE_WIFI);
SupplicantState supState;
WifiManager wifiManager = (WifiManager) getSystemService(Context.WIFI_SERVICE);
WifiInfo wifiInfo = wifiManager.getConnectionInfo();
supState = wifiInfo.getSupplicantState();
return (networkInfo != null && networkInfo.isConnected() && supState.toString().contentEquals("COMPLETED"));
}
So basically what I am checking before doing the background task is whether the device has active network connectivity and is connected or if the connection is wifi, if that connection is authentication complete so that data transfer is possible.
This doesn't seem to work and fails too making the service still force close.
What is the right way to do this check for network connectivity when wifi authentication is involved and then do the background processing?
Thanks.
A good example of this problem is when you are in any starbucks nationwide your android device will automatically connect to attwifi and the wifi status changes to connected because i check isConnected returns true but you will notice that the attwifi at starbucks will not let you transfer any data until you pseudo sign in by navigating to a browser page and accepting their terms of usage and agreement
Method conMgr.getActiveNetworkInfo() calls into ConnectivityService and the result of this call can be null. In the statement (conMgr.getActiveNetworkInfo() != null && conMgr.getActiveNetworkInfo().isAvailable() && conMgr.getActiveNetworkInfo().isConnected()) you call three times. I suspect there can be NPE here, as one of these calls can return null if network changes from 3g to WiFi at that time. What if you get NetworkInfo instance first, and them call isAvailable() and isConnected() on it (similar to how you did it in WifiConnected())?
You could move the connectivity check in your activity (or wherever else you have the context) and start the service from there.
Thus you won't have the force close constraint of the intentService and it should work fine.
Edit:
Ok got it! Here's what you can do to be sure that the user has access to Internet:
private boolean hasInternetAccess() {
boolean hasInternetAccess = false;
try {
//I set google but you can try anything "reliable"...
//isReachable(1) the timeout in seconds
hasInternetAccess = InetAddress.getByName("www.google.com").isReachable(1);
} catch (UnknownHostException e) {
// TODO Auto-generated catch block
e.printStackTrace();
} catch (IOException e) {
// TODO Auto-generated catch block
e.printStackTrace();
}
return hasInternetAccess;
}
So your check becomes:
If(WifiConnected() && hasInternetAccess()){
//Do background Work...
}
This is does some sort of ping to ensure the user has internet.
Don't forget that this method needs to be executed in a separate thread or it'll throw a NetworkOnMainthreadException. Here you're safe since you are in an IntentService that has its own thread. But I precise for the ones that might see this thread. By the way I suggest you to change the title of the this thread since the actual problem is not really related to the service but the access to internet.
Here's the reference: Test Internet Connection Android
I hope this helps.
or you can write a receiver for Connectivity change. It would be the best in your case.
<action android:name="android.net.conn.CONNECTIVITY_CHANGE" />
Just a quick background I'm Running CM7 on a rooted Nexus one.
I am trying to detect when an outgoing call is actually connected: has stopped ringing and the person you are calling has answered. Looking through the forums this seems to be a tough and perhaps unanswered question. I'd really appreciate any insight into this.
In my searching the best I could find was in:
Android : How to get a state that the outgoing call has been answered?
#PattabiRaman said: "instead of detecting the outgoing call connection state, it is easy to get the duration of the last dialed call."
Does he mean that one should get the duration of the last dialed call as the call is in progress? And when that duration goes over 0 then you know?
The class com.android.internal.telephony.CallManager should have information about when the call actually is answered. It has a public static method getInstance() which returns the CallManager instance, and a public method getActiveFgCallState() which returns the current call state as a Call.State enum.
So in theory something like this might work:
Method getFgState = null;
Object cm = null;
try {
Class cmDesc = Class.forName("com.android.internal.telephony.CallManager");
Method getCM = cmDesc.getMethod("getInstance");
getFgState = cmDesc.getMethod("getActiveFgCallState");
cm = getCM.invoke(null);
} catch (Exception e) {
e.printStackTrace();
}
And then repeatedly poll the state:
Object state = getFgState.invoke(cm);
if (state.toString().equals("IDLE")) {
...
} else if (state.toString().equals("ACTIVE")) {
// If the previous state wasn't "ACTIVE" then the
// call has been established.
}
I haven't verified that this actually works. And even if it does you'll have to keep in mind that the API could change, since this isn't something that app developers are supposed to rely on.
I have looked into the code.
It will always give null unless you instantiate a Phone object and set it as default Phone.
But instantiating it needs some System permissions allowed only to system aps.
By using this method:
com.android.internal.telephony.PhoneFactory# public static void makeDefaultPhones(Context context) {
http://grepcode.com/file/repository.grepcode.com/java/ext/com.google.android/android/4.0.4_r1.2/com/android/internal/telephony/PhoneFactory.java
My university has an open wifi access point, however it requires you to enter your e-mail before it allows you to use the web. My problem is that the Wifi is stupid in that it seems to drop my connection and force me to enter my e-mail again every 10 minutes.
I wanted to create my own app that I can use to automatically do this step for me, but I cannot seem to find any documentation for a nice and easy way to detect if a Wifi access point has a browser login page. Is there a way in Android to get this information, or is it just to see if my connection to something is always redirected to 1.1.1.1?
See the "Handling Network Sign-On" section of the HttpUrlConnection documentation:
Some Wi-Fi networks block Internet access until the user clicks through a sign-on page. Such sign-on pages are typically presented by using HTTP redirects. You can use getURL() to test if your connection has been unexpectedly redirected. This check is not valid until after the response headers have been received, which you can trigger by calling getHeaderFields() or getInputStream().
They have a snippet of sample code there. Whether this will cover your particular WiFi AP, I can't say, but it is worth a shot.
Ping an external IP address (like google.com) to see if it responds.
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) {}
The only downside is this would also indicate that a web login is required when there is simply no internet connectivity on the WiFi access point.
#CommonsWare I believe this is a better answer than opening a UrlConnection and checking the host, since the host doesn't always change even when displaying the redirect page. For example, I tested on a Belkin router and it leaves whatever you typed in the browser as is, but still displays its own page. urlConnection.getUrl().getHost() returns what it should because of this.
I think #FlyWheel is on the right path, but I would use http://clients1.google.com/generate_204 and if you don't get a 204, you know you are behind a captive portal. You can run this in a loop until you do get a 204 in which case you know you are not behind a captive portal anymore.
#FlyWheel wrote: The only downside is this would also indicate that a web login is required when there is simply no internet connectivity on the WiFi access point.
You can solve this by registering a receiver to android.net.conn.CONNECTIVITY_CHANGE. You can check if Wifi is ON and is connected by looking at the Supplicant State of the connection.
Here is a snippet, but I didn't run it:
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.
}
}
I can't remember if the SupplicantState is COMPLETED or ASSOCIATED, you will have to check that. You should use an IntentService for checking the generate_204 since broadcast receivers have a short lifetime.
I used the following code using google's 204 endpoint.
private boolean networkAvailable() {
ConnectivityManager mManager = (ConnectivityManager) getApplicationContext().getSystemService(Context.CONNECTIVITY_SERVICE);
if(mManager != null) {
NetworkInfo activeNetwork = mManager.getActiveNetworkInfo();
if(activeNetwork== null || !activeNetwork.isConnectedOrConnecting()){
return false;
}
}
OkHttpClient client = new OkHttpClient();
Request request = new Request.Builder()
.url("http://clients1.google.com/generate_204")
.build();
try {
Response response = client.newCall(request).execute();
if(response.code() != 204)
return false; // meaning it either responded with a captive html page or did a redirection to captive portal.
return true;
} catch (IOException e) {
return true;
}
}
Many applications including Google Chrome use http://clients1.google.com/generate_204 to verify that the the connection is not locked under captive portal.
The issue might rather be - today at least - that newer Android versions (5.1+?) keep the 3G/4G connection up and running until the wifi login actually leads to a fully functional wifi connection.
I haven't tried it, but maybe with the enum value CAPTIVE_PORTAL_CHECK of NetworkInfos DetailedState one can try to detect such a mode properly?
In my code I am using requestRouteToHost() method:
Does this routing means changing the WIFI to 3G or vice versa??
My code is not working...
public static boolean isHostAvailable(Context context, String urlString) throws UnknownHostException, MalformedURLException {
boolean ret = false;
int networkType = ConnectivityManager.TYPE_WIFI;
ConnectivityManager cm = (ConnectivityManager) context.getSystemService(Context.CONNECTIVITY_SERVICE);
if(cm != null){
NetworkInfo nf = cm.getActiveNetworkInfo();
if(nf != null){
networkType = nf.getType();
}
URL url = new URL(urlString);
InetAddress iAddress = InetAddress.getByName(url.getHost());
ret = cm.requestRouteToHost(networkType, ipToInt(iAddress.getHostAddress()));
}
return ret;
}
public static int ipToInt(String addr) {
String[] addrArray = addr.split("\\.");
int num = 0;
for (int i=0;i<addrArray.length;i++) {
int power = 3-i;
num += ((Integer.parseInt(addrArray[i])%256 * Math.pow(256,power)));
}
return num;
}
Thanks
I think this is an extremely poorly documented method, and while an above comment saying "consider it a ping" might be a reasonable interpretation, I don't think it's correct. The fact that it takes an int as a host address suggests it is a much lower-level method than that, and the comment in the JavaDoc This method requires the caller to hold the permission CHANGE_NETWORK_STATE is another clue, suggesting that this makes a change in the internal routing table of the device. This link provides a better explanation:
requestRouteToHost() doesn't establish connectivity on any network, it
only ensures that any traffic for the specified host will be routed
via the specified network type (wifi or mobile). Connectivity must
already exist on the specified network.
This explanation makes MUCH more sense, considering the permission required. It also appears that it will not work with WiFi. So, it appears what this method is useful for is the following: You wish to ensure that the connection made to a particular host will be made via a SPECIFIC interface and that interface is not WiFi. This might make sense for a long-term, low traffic, battery efficient connection, such as when you wish to keep a socket open to a server and wait for the server to send the occasional message. The mobile data interface would make more sense than WiFi, since you wouldn't need to keep the WiFi radio active the whole time, and the mobile network radio is always on anyway. Incidentally, this is EXACTLY how an iPhone's server "push" mechanism works: It keeps a socket to an Apple server constantly connected over the mobile data interface, waiting for the server to say something.
So, in opposition to the (currently chosen) correct answer, I suggest that the answer to the asker's question: Does this routing means changing the WIFI to 3G or vice versa?? is actually, "Yes, sort of!" If the method returns true, the caller is assured that connections to that IP address will happen over the indicated interface.
And to Google: Boo on you for not documenting some of your APIs better!
Method requestRouteToHost() does not change wifi to 3G or vice versa!
Official Documentation :
public boolean requestRouteToHost (int networkType, int hostAddress)
Ensure that a network route exists to deliver traffic to the specified host via the specified network interface. An attempt to add a route that already exists is ignored, but treated as successful.
Parameters
networkType the type of the network over which traffic to the specified host is to be routed
hostAddress the IP address of the host to which the route is desired
Returns
true on success, false on failure