I have content management application that uses TCP/IP to fetch data. I would like to test this application for several network problems like packet loss and connection lost.
Is there some easy way to emulate network problems to test Android application?
In DDMS there is some connection and latency setting for device, hovewer it looks like this is not working. I can set denied or unregistered but fetching from server is untouched. I'm using Windows for development.
I have tried so far:
F8 - 3G icon disappears, however I'm still able to download data.
DDMS, Change of Telephony status - 3G icon disappears, however I'm still able to download data.
Settings, Mobile networks, Data enabled false - 3G icon disappears, however I'm still able to download
Airplane mode - 3G icon disappears, however I'm still able to download
Dev tools - Wifi toggle - I'm getting errors:
09-27 16:43:31.353: ERROR/Connectivity(518): EVENT_TOGGLE_WIFI
09-27 16:43:31.363: ERROR/WifiService(62): Failed to load Wi-Fi driver.
for testing the lost of internet connexion for example , you can desactivate the 3G connection from your emulator by pressing F8. for example; launch your application , and then while downloading data, try to disable the connection by pressing F8 , and then you can see the reaction of your app
I don't think you have to worry about packet loss with a TCP connection given that the delivery is reliable (lost packets are already handled and re-sent). If you are using an emulator you can set the latency in the Telephony Status section of the Emulator Control tab in DDMS.
You can use Android Dev Tools App.
It's by default on Emulator, and you can copy/install it on real device.
It has option (among others) to toggle Wifi periodically by some given times.
Related
I'm developing an app that uses the server in the wifi network (A), which has no internet connection. I use another wifi connection (B) with the internet for normal use. When I debug my app, I switch my android phone to the wifi connection A.
but the wifi network automatically changes to B, while I'm still debugging my app which has no programmatic functionality to change the wifi connection. If I change it back to A, after a few seconds or about in one-two minutes it automatically changes back to B. This is not an expected behavior to me since I can't properly debug my app.
I tried to change the network & internet settings, but no option was found to prevent automatic wifi network switching. What I can guess is my wifi B is selected by android O/S because it has an internet connection. I can forget that connection, but it's not practical because I use both connections in short time periods.
I wonder if any other developer solved this kind of problem in any programmatic or manual way while debugging. I really do not want to include any wifi switching functionality in my app, just need to keep my wifi connection A connected while debugging with Android Studio.
My Android O/S version is 10, Nokia 3.1
Any help would be highly appreciated.
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.
how can I execute HTTP requests or open a socket on Android Wear? I used to think that's impossible but the Web Browser for Android Wear app says the folloing:
"[..] works even when your phone is off if you have a smartwatch with Android Wear 5.1 and WiFi"*.
I tested it and that app CAN connect the internet when the paired phone is powered off.
Whenever I open a socket or try HTTP requests on Android Wear I always get a ConnectException saying failed to connect to http://foo.com (similar stack trace here). So I'm doing something different then that app is doing and I'd like to understand what that is.
Context: I'm working on proof-of-concept and just want to be able to execute HTTP requests and open sockets. I'd love to know if there's any way to do that. Even if it includes rooting the watch and doing some adb magic.
To clarify: I know about the Data Layer API and i'd still like to be able to just do HTTP requests and open sockets.
If your watch has Wifi and it is set up correctly, then you can make network calls on your watch when your watch is disconnected from the phone; when you connect to your phone via BT, wifi will be disabled. While it is enabled, you should be able to treat that as a usual network connectivity and make network calls. But keep in mind that if you write an app that relies on this, your app will fail to work when it gets connected to a phone so you need to handle that case and provide an alternative for your app to get the same data (i.e. using the phone's connectivity).
I have installed the Android TV SDK Developer preview for Windows. I am in a corporate intranet environment. I can start the Emulator, but the main screen endlessly loops with the "Preparing Recommendations" animation. I can navigate to the Settings and see that there is no network (no wired and no ethernet).
I suspect this might be a proxy issue. I have tried launching the Emulator with the following command:
C:\Eclipse_w_Android\adt-bundle-windows-x86-20140624\sdk\tools>emulator -avd AVD_for_Android_TV_1080p_by_Google_X86 -http-proxy http://MY_PROXY_IP:8080
(MY_PROXY_IP is replaced with my company's IP address)
It launches the Emulator but doesn't seem to have any effect on the network.
Has anyone else been able to get the Android TV Emulator to fully load in a heavily firewalled / proxied environment?
I thought I was experiencing this issue as well (and had originally commented as such), but I later realized that there was no actually connectivity problem. Two things to note:
"Preparing Recommendations" will appear indefinitely, and I presume this is simply because there are no apps by default feeding recommendations to populate this screen.
Both the Ethernet and Wireless items will show that they are not connected. However, if you run an app that uses the network (a simple WebView is sufficient as long as the app has INTERNET permissions), you'll see that it connects just fine.
I would suggest trying a test app to check connectivity, as there is no other indicator I can find suggesting that it is working properly. I suspect you'll find that all is well.
you probably forgot the first part username password # server port
your company probably has the ip setup with username password
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.