How to handle Alert windows in Amazon Device Farm /w Appium - appium-ios

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.

Related

How to get rid of/resolve "invalid" status of emulator in DevEcoStudio

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.

How can I disable the Android 11 media notification for my application when using ExoPlayer's media2 extension?

I have an application that plays videos using ExoPlayer. A notification is created using the PlayerNotificationManager and MediaDescriptionAdapter from ExoPlayer.
On Android 11 on a Pixel 5 (but not a Pixel 3 XL) or any Samsung device I see two notifications: one that I see on all other OS versions, and one that appears in the settings tray on a Pixel, or the Media section (and lock screen) on Samsung devices.
At some point, I would like to support that notification properly, but for now, having two notifications is a bug, and it seems like the easiest fix should be to disable the new notification.
The linked documentation says
To be discoverable your app must provide a MediaBrowserService, typically using the MediaBrowserServiceCompat library from Android Jetpack.
My app has an androidx.media2.MediaSessionService, which hides the MediaBrowserService. I have tried returning null from the onGetSession() method, but the notification still appears. It seems like I need a way to do the equivalent of returning null from onGetRoot().
Is there anything I can do to opt out of this notification without rewriting all of my MediaSession/MediaSessionService code to use the older compat equivalents?

When is sessionReachabilityDidChange(_:) called on a watch WCSessionDelegate?

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.

Firebase Remote Config A/B testing shows no results after 24 hours

I configured Firebase Remote Config A/B testing for Android, and we did rollout on at least 10K devices.
For some reason, I see "0 users" in my A/B test after more than 24 hours.
Firebase GMS version is: 11.8.0
Should it show A/B participants in real-time or it's ok to see 0 users after 24 hours?
P.S: We are able to get AB test variants on test devices through Firebase Instance Id, it works well.
The simplest experiment which is running has only app package as a target, with no additional filters. And it shows 0 users as well.
Finally, we found an answer!
Maybe somebody will find it helpful:
For now, it happens (no data in Firebase remote config A/B test experiment) if you have an activation event configured for A/B test experiment.
If you have 2 different experiments, both will fail to get results even if you have "activation event" configured only in 1 of them.
Additionally, remote config will not work as well, you'll be able to get only default values.
We already reported to Google about, so they'll fix it at some point I hope.
Another useful info which is really hard to get:
How long is it ok to see "0 Total Users" in experiment I've just
started?
It takes many hours before you can see any data in your experiment. We were able to see results only after 21 hours after experiment start, so if you configured everything well, don't worry and wait for at least 24 hours. It will show 0 "Total Users" for many hours after the start.
Should I use app versionName or versionCode in "Version" field of
experiment setup?
You should use versionName.
Some useful info from support:
Firebase SDK
Make sure your users have the version of your app with the latest SDK.
Since your experiment is with Remote Config
When activateFetched() is called, all events from that point on will be tagged with the experiment. If you have a goal or activation event that happens before activateFetched(), such as automatic events like first_open, session_start, etc., the experiment setup might be wrong.
Are you using an Activation Event?
Make sure to call fetch() and activateFetched() before the activation event occurs.
Experiment ID of the experiments (if support asks you about)
It's the number at the end of the URL while viewing experiment results.
This debugging log could be useful to get what is going on
Also:
The good way to check if your experiment is working now is to set it to a specific version you didn't publish yet and check logs from remote config with the fresh app install(or erase all app data & restart).
It should show different variant every time you reinstall the app, since your Firebase Instance ID changes after app reinstall/app data erase.
If you see variants change - then A/B test is running well.
In your "build.graddle": don't forget to set the same versionName which you set in experiment setup.
In my case, I was receiving results of A/B testing but suddenly, it stopped to appear. It had continued for 7 days and then results appeared. Firebase Support manager said:
what I suspected here is just a delay in showing the result in the
experiments
Additionally, she said that
With that, I would suggest always using the latest SDK version and
enabling Google Analytics data sharing.
In my case, I used I wasn't using the latest SDK version, but Google Analytics was enabled for "Benchmarking", "Technical Support", "Account Specialists" except for "Google products & services". I believe these settings were enabled by default (the screenshot from Google Analytics):

Turn off 'cloud-based' based mode for visual studio load test

This is sort of a part two of the question here
VisualStudio cloud-based load test socket exception 100% of requests - webtest alone works OK
In short, my loadtest fails all requests with a weird socketexception, but only when it is run as a 'cloud based' test.
So, my load test somehow (dunno how) is no longer a 'team services cloud based' unit test, but a regular one - and I see that it runs fine.
However, when I add a new cloud-based test and then click on the 'location' setting in my old test and pick anything (or not pick, doesn't matter), VS connects to my TeamServices account, the test becomes cloud-based and it is launched in a different looking tab, with 100% request fails.
So, the question is - how do I turn off/toggle the 'cloud-based' mode for an existing loadtest?
Open the testsettings file in your solution/project, you should be able to change the Test run location from VSTS to local computer:

Resources