How to track touch actions on screen during test automation with Appium - android

I am using appium to run automated tests for a mobile app. the app is on both android and ios and my tests are written in ruby.
In my test code, I tap specific coordinates on the screen however I am not able to verify that the correct position was tapped if no action resulted from the tap.
What I would like is some kinda of visual cue so that I can tell where on the screen was tapped, pressed, swiped, etc. Is there any way to do with appium?
On android, in the settings under developer options I can select "show taps" which will temporarily display a circle where I tap on the screen but this doesn't seem to work while running tests. I'd like to know if there are any ways to do this on either android or ios. Any help would be appreciated.

For Android you should enable Show touches and Pointer location too from developer option, It will show the pointer location of Click/Swipe/Tap. It's working fine for me during automation.

Related

SOTI MobiControl Kiosk Mode

We are trying to use the Kiosk mode feature of SOTI MobiControl to run our application on a kiosk. We are currently testing on a Zebra TC52 (an Android device) until we get our Elo kiosks.
We’ve set up a profile for our app that uses the Lockdown configuration. It “kind of” works, but isn’t quite doing what we expect.
When we power on the machine, it comes up in the normal startup screen. If I swipe up, then it takes us to our app screen. However, the status bar is showing, and can be pulled down.
However, if I click on the Home button, then the status bar goes away, and we’re closer to where we wanted to be. There is still a back button at the bottom of the screen.
We were hoping:
That when the machine starts, it would immediately go to our app screen, instead of requiring someone to swipe up to get the app to start.
That there would be no status bar, or bottom icons.
This app will be customer facing, so we want our app, and only our app, to ever show on the screen.
I’m not sure if any of these limitations are specifically because we’re using a TC52 instead of an actual kiosk device, but to my mind, they’re both just Android devices.
I have included screen shots of our configuration and the results on the device.
Can anyone see anything we are missing? Or are we expecting too much from the SOTI configuration for kiosks?
at least to disable the Lock Screen you can use the free Zebra StageNow tool (https://www.zebra.com/de/de/support-downloads/software/utilities/stagenow.html).
You can create a lot of device specific setting, just check https://techdocs.zebra.com/mx/ for the setting to disable the swipe lock screen.
in StageNow you can, after finish the Profile, export the Config for MDM
(upper right corner)
In Soti Mobicontrol u can use a script within Packages, Filesync, or direct on Device
mxconfig /sdcard/yoursetting.xm
to import the Setting to the Devices.
Depending on your Soti MC Version there are also some Settings available in the Lockdown Setting Profile to disable the Notification Bar, maybe also u can find some other usefull Settings in the MX Matrix..
Oliver

Click on android permission in browser when using browserstack automate with selenium and appium

We are making an automated test suite with browserstack automate with our tests in selenium with appium.
For this test we need to play DRM protected content, while this works on all desktop platforms, we are having some trouble testing for android (and ios).
Since we need to tap on the allow button of the popup that appears when video tries to load.
We've been attempting to click this button, but without much success.
We've tried fiddling around with the coordinates of the tap, but it does not seem to work/register.
We've noticed that either the context switch or the click cause the device to go to the home screen, since that is what we see in the recorded video. However the screenshots show the browser and the content without going to the homescreen (and the popup is gone too, but the video does not work)
This is the code we've been using to perform the tap action:
androidDriver.context("NATIVE_APP");
int x = androidDriver.manage().window().getSize().width - 100;
int y = androidDriver.manage().window().getSize().height / 2 + 50;
new TouchAction<>(androidDriver).tap(PointOption.point(913, 1245)).perform();
androidDriver.context("CHROMIUM");
Input capabilities:
Browser capabilities:
Any help would be greatly appreciated, since we can't figure it out how to get it to work...
Since you are switching to native context, you can find the allow button and click it. Based on the details and screenshot you shared, the following code snippet should do the trick:
//switch to native context
driver.context("NATIVE_APP");
//find element with text attribute ALLOW and click it
driver.findElement(By.xpath("//android.widget.Button[#text='ALLOW']")).click();
//switch back to chrome context
driver.context("CHROMIUM");
You can also use this capability for android as well. This automatically allow all android permissions.
cap.setCapability("autoGrantPermissions", "true");
The #text='ALLOW' is not working, try to find by the resource-id like:
driver.findElement(By.xpath("//android.widget.Button[#resource-id='android:id/button1']")).click();

Simulate android shake

Is there an API method that can be used to simulate shaking an Android device? My reason for wanting to do this -
I had been experimenting with using HockeyApp to provide an in-app feedback facility for my beta testers. Whilst it works I find that in my hybrid Cordova app it displays an ugly feedback screen which
stays put till I hit the Back button
at which point it restarts the app - I suspect because it uses the WebView to display the feedback screen so in effect the app's own screen has to reload later
TestFairy provide a much sleeker UX when offering feedback and their "shake for feedback" concept is very nice. However, it may not be apparent to all my beta testers so I would like to provide a button which I can then use to simulate the shake gesture from the custom Cordova plugin that I am also writing for the app.

Can I enable mouse/desktop-like text selection behavior in an Android app?

I'm using ARC Welder to turn my Android app into a Chrome OS app. Most of it works perfectly, except that text selection with a mouse behaves like it would on a touch device, requiring long-clicking or double-clicking on words, and then dragging the ends. Is there a way around this?
As CommonsWare points out, this is the Android behavior.
Feel free to file a bug even for a feature request.
We are open to allowing the behavior to be changed, but it also seems like something that should be left up to the end user (how do they expect to interact with an Android app on a Chromebook?)

Android app on Chrome using ARC, keep back button on top enabled

developer.chrome.com/apps/getstarted_arc#bestpractices
The ARC allows you to execute native android apps through the chrome browser by wrapping a chrome app around it.(As far as I can tell)
I am re-factoring an Android app to work well on Chrome. The first thing I need to do is to make the back arrow enabled at all times on the top left as shown below.
This is the program that allows Native android apps to run through chrome. I think the answer to my question lies somewhere in "Additional Metadata", or in the source code?
Add {"disableAutoBackButton": "true"} to the metadata. That will enable the back button within an activity. I've found that with my app that has multiple activities, though, it doesn't work to return to my main activity from my settings activity. It could be that I'm doing something wrong with the way I'm handling activities, I guess, but it works on all physical devices.
{"sleepOnBlur":false,"disableAutoBackButton":true}
please supply the above metadata before you download the zip or launch app from the arc welder
the first param prevents excessive pause/resume and also supposed to fix short black screen flash occurring occassionally in some of the apps.
the second params adds persistance back button on top left hence helping to avoid extra code required because of absence of back button in some screens(mostly the first screen)

Categories

Resources