Is there way to stop iOS simulator from rebooting with appium? So every test simulator is rebooted. It takes a lot of time. I tries noReset option as true, but did not help. I have macmini with latest os (10.12.6) and latest appium (1.2.7), XCode (9.2). What can I do?
desired_caps = {
'platformName': 'iOS',
'platformVersion': '11.2',
'deviceName': 'iPad Air',
'browserName': "Safari",
'nativeWebTap': True,
'safariIgnoreFraudWarning': True,
'showXcodeLog': True,
'clearSystemFiles': True,
'newCommandTimeout': 600,
'wdaLocalPort': 8100,
'launchTimeout': 120000,
'wdaLaunchTimeout': 120000,
'sessionOverride': True
}
Tried to add noReset=True and fullReset=False options but it did not change anything.
It seems like it's done on purpose and can not be disabled, unfortunatelly. I have rather not so fast computer, and restarting ios simulator takes a lot of time.
Sim Resetting
By default, this driver will create a new iOS simulator and run tests on it, deleting the simulator afterward.
If you specify a specific simulator using the udid capability, this driver will boot the specified simulator and shut it down afterwards.
If a udid is provided and the simulator is already running, this driver will leave it running after the test run.
In short, this driver tries to leave things as it found them.
You can use the noReset capability to adjust this behavior. Setting noReset to true will leave the simulator running at the end of a test session.
https://www.npmjs.com/package/appium-xcuitest-driver . THIS MAY HELP YOU.
Related
In order to test any HMOS app in the emulator in DevEcoStudio IDE, we have to the emulator via Tools->Device Manager. Seldom, devices show "invalid" status due to which cannot launch the emulator. It stays in the same state for longer, sometimes for hours.
Is there any workaround for the above issue?
Thanks,
Kanak
As the error popup says, currently All device instances are busy/in-use. So No device available at the moment.
There is no way we have to wait and try again later some time.
Currently, remote emulators do not work in some regions. Unfortunately there is no way around this.
Huawei is working to fix the problem, but I don't know the ETA.
Apple's documentation says this in the discussion section of the method description:
This method is called to let the
current process know that its counterpart session’s reachability
changed.
The description of the isReachable property says this: WatchKit
extension. The iOS device is within range, so communication can occur
and the WatchKit extension is running in the foreground, or is running
with a high priority in the background (for example, during a workout
session or when a complication is loading its initial timeline data).
I am assuming this would mean that if the watch moves out of or into range of the iOS device, the WatchKit extension would be launched and the WCSessionDelegate's sessionReachabilityDidChange() method would be called, and the WCSession's isReachable would be true if the iOS device just came into range and false if it just when out of range.
I have not found a way to verify this in xcode. For example I put a log message in sessionReachabilityDidChange(_:) and walked out of range, but xcode simply says the app lost connection with the iphone and can no longer debug it. Can someone verify this or point me to some documentation that better describes this?
I think you cannot verify this in Xcode.
I have an app on iOS and watchOS. To check this kind of situation, I can enable debug alerts on iOS and watchOS. When func sessionReachabilityDidChange(session: WCSession) is triggered, I display a debug alert.
Now, if I run (not under Xcode) my watch extension, and then switch off the paired iPhone, the debug alert is shown on the watch.
This shows that sessionReachabilityDidChange is actually called as expected.
Apparently, under Xcode a connected iOS device is always reachable.
EDIT:
To check the situation when the watch extension is not in foreground, I did the following:
Instead of showing a debug alert, I set now the complication to a unique value that is not possible otherwise. I launched the watch extension and put it into background by showing the watch face with the complication.
When I now switch off the iPhone, the complication is not updated.
This indicates to me that sessionReachabilityDidChange is not called in background.
As I am new to real-time device testing, I need your support in resolving an issue which I am facing since long now. I have following issues with iOS devices and simulators:
I am able to run my script in the simulator but not on the real-time device.
Unable to see WebDriverAgentRunner app on the device, however, I have built that app multiple times.
My Scrip is able to interact with Appium, it gets installed also but never gets open (In Eclipse it gets failed with error: No element found)
Please find the attached appium logs and desired capabilities below:
Desired Capabilities:
IOSDriver wd = null;
DesiredCapabilities capabilities = new DesiredCapabilities();
System.out.println(" ");
capabilities.setCapability("appium-version", "1.7.2");
capabilities.setCapability("automationName", "XCUITest");
capabilities.setCapability("platformName", "iOS");
capabilities.setCapability("udid", “UDID”); //6Plus
//capabilities.setCapability("noReset", "true");
capabilities.setCapability("platformVersion", "11.2.6");
capabilities.setCapability("deviceName", "iPhone 6”);
capabilities.setCapability("app",
“<Path of builded Application.app>”);
capabilities.setCapability("bundleID", “<com.bundel id>”);
wd = new IOSDriver(new URL("http://0.0.0.0:4723/wd/hub"),
capabilities);
Also in the simulator, I am able to run only on one device.
Appium Logs Are present in this link
I currently trying out Amazon Device Farm and was able to get a dummy app to work.
However, when I tried getting the actual App I want to get working on Amazon device farm, I'm unable to do so. I'm able to upload the .ipa file, and zip up and upload the py.tests/appium tests with their dependencies, however the tests fail.
What I think might be happening is ADF is not recognizing some of the Desired_capabilities to autodismiss the Alerts for Notifications and GPS coordinates.
My setup is very similar to the setup I used with the dummy app in my initial tests. (these worked with amazon device farm)
https://github.com/dlai0001/appium-spike-running-tests-oncloud
Only thing that is really different is I'm using a real production app, where 2 alert windows popup upon launch. In Appium it will cause the test to crash if I don't have the autodismiss or autoaccept alerts enabled in the desired capabilities.
Harness 00:00.0 1295 Info Starting 00001 with device c00e8ab68437161b894395e438ba8935a672bac0
Harness 00:00.0 1295 Info Using test content version 0.1.0
Harness 00:00.1v1295 Info Using image version ami-778b7c17
I work for the Amazon Device Farm team.
It appears that you are relying on desired capabilities to dismiss the alert window. Currently, Device farm has support for a very limited set of desired capabilities namely app name, package name and osversion. These are available to the application without having the user required to set it.
Appium runs with autoAcceptAlerts=true on Device Farm. This should handle the alert windows, if any, unless it is a system pop up which autoAcceptAlert cannot handle. You should check if your tests can handle the alert windows using autoAcceptAlerts=true with Appium pre launch mode locally.
If it can handle it then device farm should behave the same way.
Sometimes it may be the case that the alert window appears before the appium session is established in which case adding a delay can help.
When you test is locally please use Appium version 1.4.16 since this is the version being used on device farm right now.
Does anybody know what happened with event-listener for location changed for WI-FI provider. I saw a lot of questions about this but no proper answer.
I'm doing everything fine and it is working for older versions of android, but now I updated my SAMSUNG GALAXY TAB 10.1 to ICS and it is not working anymore. Maybe this is a SAMSUNG (or my mobile provider) bug when they implemented their UI into ICS...
I'm registering eventlistener like this (have in mind that it works good in prevous versions of android and I also enabled all location services in settings):
locationManager.requestLocationUpdates(LocationManager.NETWORK_PROVIDER, 0, 0, loclistener);
//refresh time and distance are to 0 so it should trigger location change event
After this request I checked if network provider is enabled and it shows like it is.
Code:
if (locationManager.isProviderEnabled(LocationManager.NETWORK_PROVIDER)) {
Toast.makeText(this, "NETWORK PROVIDER enabled!", Toast.LENGTH_LONG).show();
}
If someone has an idea please help me...
This is known issue:
After device reboot the network location provider works fine but after some time it stops updating.
https://code.google.com/p/android/issues/detail?id=57707
Unfortunately without solution yet.
To track how often the network provider is updating, I modified the onLocationChanged() method to the following:
public void onLocationChanged(Location location) {
dummyText.setText(location.toString() + "\n" + "Elapsed Time (ms): " + (lastTime - location.getTime()));
lastTime = location.getTime();
}
And added:
long lastTime = 0;
...as a global variable.
This will print out the time between updates in milliseconds (after the first fix - first fix will just print the negative time value from the first Location).
I ran the above code on my Samsung Galaxy S3, and the network provider updates around every 20 seconds, so the code seems fine.
I also ran this on a Samsung Dart (from T-mobile, but not activated) on WiFi, and the network provider updates around every 45 seconds.
I also ran this on a Samsung Nexus S 4G (from Sprint, but not activated) on WiFi, and the network provider at first didn't update at all. Restarting the device seemed to fix the problem, and now its updating roughly every 20 seconds.
Based on your comments and my experience, it looks like this issue varies between OEMs and even between device models of the same OEM. It might be another quirk of the lack of the strict enforcement of LocationListener behavior prior to Android Jelly Bean 4.1. Strict enforcement of LocationListener behavior only recently started in Android Jelly Bean 4.1, which is mentioned in the Android developer docs here in under the first requestLocationUpdates method signature:
http://developer.android.com/reference/android/location/LocationManager.html
Prior to Jellybean, the minTime parameter was only a hint, and some location provider implementations ignored it. From Jellybean and onwards it is mandatory for Android compatible devices to observe both the minTime and minDistance parameters.
Also, from my experience, the refresh interval of the NETWORK_PROVIDER location updates on devices that do update is pretty fixed at around 20-30 seconds across many different devices. So, the minTime parameter you pass into the locationManager.requestLocationUpdates() method is likely to be ignored.
Having to reboot the device to get a network provider location is likely due to not getting a response from the Google server that provides this location info. Not sure why rebooting fixes it.
I had the same problem with the NETWORK_PROVIDER. The reason is that when you request for updates, the NETWORK_PROVIDER does not create a callback for the method onLocationChanged(). You also need to call getLastKnownLocation(NETWORK_PROVIDER) in order for it to start updating the location.
The weird thing is that for the GPS_PROVIDER this is not neccessary.
I hope this helps.
Ok. So now I got it working. It is really strange. I restarted all my devices and now it updates. I don't know what happened and I would really like to know what is the reason for this strange behavior. Thank you #barbeau for all your time and help.