I have an issue with an application I'm developing for Android 2.3.3.
It's connected to a Wi-Fi access point, and at the same time it is supposed to download some data, but this has to be done using 3G.
I tried searching for this, and found some relevant stuff but could not make it work. I checked out the setNetworkPreference method of the ConnectivityManager, and, even when set to use 3G, it does not download the data and ends up downloading it via Wi-Fi.
Any other ideas how I can do this without disconnecting from the Wi-Fi access point?
I literally just came across this on another forum. It looks like the solution to your question.
ICS tends to automatically add proxys to APN info which sometimes makes apps not work on 3G.
Thread says the following...
"This helped a couple of people on a Dutch forum, don't know if it's provider or country-related and if there even are users here that have these issues, but still wanted to let you know:
I have just fixed why some apps work only with WiFi but not on 3G. ICS apparently automatically added Proxy-settings to your APN, in my case Vodafone (NL). This is not necesarry to even make use of mobile internet, and it also prevents some apps from accessing the internet. I removed the Proxy-settings et voila, it works perfectly again!
Fix: Settings -> Press 'Mobile Network' (not Off-On!) -> Names accespoints -> Click your provider -> Remove 'Proxy' and 'Port'"
Hope it helps.
Related
Hello there long time reader of Stack Overflow but first time poster,
I am a bit new to android development but we decided to build a Xamarin.Forms app which consumes our ASP.NET REST service. When running the app on an emulator on my computer, connected via ethernet, I am able to connect to the service. However, when running on a tablet or phone that is connected on our work wifi, the connection just hangs and times out.
Interesting enough, when the device is switched to mobile data it can connect to the endpoints again, and iPhones can connect to the endpoints on mobile data or wifi.
I'm curious what I'm missing here. Please let me know what you think or additional information I should include.
While this thread has been opened for some time, we have found our problem resolved: it was a mixture of our network support changing some settings on our routers (though I can unfortunately not remember what settings) and also our tablets do a system update.
I am not sure which of these factors was the cause of our success now but the issue is done. I just wanted to post this in case anyone else ran into something similar.
Cracked my head for an entire day figuring out what was the issue, tried replacing the firebase .json file and everything but it wouldn't connect to the database via WIFI. Went to shower and thought of ways to solve this, came out of a hot shower with an idea of maybe i should connect via 4G mobile network and it works completely fine!
Did anyone else came across this issue?
(sorry if its kinda vague, would be happy to answer anything related to this problem)
The solution for me was to replace the internet service provider SIM card as I'm using 4G access point in my home.
It seems like the operator is blocking some services. when I switched to another SIM card it worked like charm!
Please see: https://github.com/firebase/firebase-android-sdk/issues/1258
The short answer is, it's something in the Android networking stack that causes RTDB to not be able to connect to specific WiFi routers (in my case for older Android devices).
If resetting the router doesn't work and cellular is not an option, the only fix I have found is having the user plug a known working router (set to access point mode with DHCP disabled) into a LAN port of their existing router and then connecting the Android device to that access point. In my case I use a TP Link N300 Nano Router and it works well. I imagine replacing the router entirely will also do the trick.
<uses-permission android:name="android.permission.ACCESS_NETWORK_STATE"/>
<uses-permission android:name="android.permission.CHANGE_WIFI_STATE"/ >
i am trying to connect two android devices using WIFI direct and i was successful. But the problem is the second device has to accept the a connection prompt after the other device initiates the connection. It is undesirable for what i am trying to achieve. I saw a few post here in stack overflow itself saying that currently its not possible. But came across an app called SUPERBEAM which user WIFI direct but without the prompt. A search in google gave me the following link from xda forum which says
SuperBeam creates an access point using Android's WiFi direct API's.
This essentially works like hotspot mode in old devices, but it is
guaranteed to work on newer devices like Nexus 7. Moreover, this mode
allows older devices to connect and receive files without having to
support WiFi direct's peer-to-peer connections and, more importantly, it
gets rid of the annoying "accept connection" prompt.
But no where i found information on how to implement this. Can anybody help me. Here is the link
http://forum.xda-developers.com/showthread.php?t=2177133
You could indeed simply use the createGroup function from the API to create a group, which also makes the access point. The first problem here is that the access point name & password are set automatically, and you can not change them.
So, you do need to pass the info to the connecting party, and for this, I would suggest using the local service advertising, and using the instance name there.
Did make simple test app for this and you can find it from Github under DrJukka/MyWifiMesh, also some discussions on the topic can be found from my blog
This can be achieve using Xposed framework. You need add the code and install the App. The phone needs to be rooted in order for it to work. I have tested it on multiple Samsung phones and it works.
Check this answer for details: How to auto-accept Wi-Fi Direct connection requests in Android
I need a fix for this strange problem appearing in android. Sometimes I notice that even I have full cellular network, data network is lost.(Not able to connect to internet although have all set properly). This possibly occurs after I leave wifi. A quick fix to make it working is toggle 2G/3G option in settings --> Mobile Networks, which probably clears the network stack and makes it all working.
But for my application, which requires always to be connected to internet, I need a fix programatically. I cannot toggle that from code ? Or can I ?
I read and tried a fix by rewriting APN settings, but that do not solve the issue entirely, as we move out from wifi connectivity.
Do anyone have any fix for this from code ?
Because of the way Android networking and security work, there's no way to toggle 2G/3G-4G without going into settings. Some "rooted" phones were once able to do this, but that was disabled in 2.1 and higher.
There's no solution for this programatically. You need to toggle the network option which normally cannot be done without user intervention.
I am testing a database storage after retrieving data from the internet, I would like to be able to start the emulator with internet working, and then, while it is running, stop internet access to force it using the database as a source to display data.
Is that possible?
You can also use F8 to set the cell network on/off.
See here
Disconnect your development machine from the network.
To test offline functionality in my Android emulator, I use the phone's settings to put the emulator in Airplane Mode, or shut off both cellular and WiFi.
Taking one step further the line of reasoning of disconnecting the development machine.
I've found, when faced with the same intent as the original question (test data persistence) that the easiest approach was to make my development server error out.
This approach has the extra benefit off making you think about dealing with server errors, since from the client standpoint being offline because of poor cellular network reception may be the same as i.e. the server being unreachable because of DNS configuration issues.
Of course it will not technically resemble airplane mode, or allow for any other complex connectivity testing based behaviour, but it may fit the same purpose.