>>Yvette Nameth: Next up, we have Anurag from Intel talking about testing wearable devices.
[ Applause ] >>Anurag Routroy: Good afternoon, everybody.
I am Anurag.
I work for Intel.
I work for a team called Test Enablers.
We focus on all kinds of functional and nonfunctional automation on mobile products.
So now today I'm here to speak on automation on wearable devices, smart watches.
Thank you, Google, for the selection.
And as we all know, with the rise of the technology, of this wearable technology in both business
and personal use, all the companies which have a solid space in the Android or iOS world
have switched their focus to this wearable technologies and have developed their apps
or support for these smart watches.
So this increases the effort of our testing on those devices.
Hence, automation comes into the picture to reduce the effort and increase efficiency.
Now let's see.
So, basically, the smart watches, they're kind of -- there are three kinds of scenario
of connections.
One would be on an actual device and on an actual wearable or a smart watch.
The second scenario would be actual real device and an emulator, Android Wear emulator.
And a third would be both the things would be emulator.
So now let's see how we can establish debugging sessions with the smart watches and the phones
so that we can start writing test scripts and do the automation.
Let's go to the first scenario.
Here is the device where both the things are the real devices on the real emulator.
So for this, what we need to do, first we need to have a device of Android 4.4.2 and
above, which supports our Android Wear.
We need to store the Android Wear application on that.
Then we enable Bluetooth debugging on the Android Wear app.
And as well as on the wearable.
Then we connect the wearable device to the phone using the Android Wear wrap.
After we do the connection, we open up command prompt and run the following command.
Okay.
So this is a port forwarding command which will allow the Android Wear device to list
up in the Samsung -- list up in the ADB devices list.
Once we do that in the Android Wear app, if you go to the settings, there are two things,
host connected and target connected.
So both the status of this host and target should be connected, or else the Android watch
or the smart watch doesn't show up in the ADB devices list.
So then we can see here, when this is done, you can see the top one is the smartphone,
and the second one, local host 4.4 is the device, or the smart watch device.
So once we get the context of this, then we're able to write any automation scripts or your
automation code on these watches.
Now, the second thing is the actual device and the Wear emulator.
This is my favorite thing for doing the automation, because it is pretty stable.
So now here, what we do, first we create an emulator device for an Android Wear, as shown
in the image.
So as we see here, we need to select the device as Android Wear.
There are different kind of sizes available for the target.
But you can select any of them.
Then you need to select the target, API 21 or above.
Then your Android Wear smart watch emulator is ready.
Then you go to the command prompt again and do a port forwarding again.
So you run this command.
Then your smart watch will show up in the Android list, Android devices list.
And then you have to go to the Android Wear app on the device, and you need to just click
on select the option connect to emulator, instead of connect to device option.
Now, you see here the -- this is for our application.
We get this thing.
Connected.
Now, the third scenario is device emulator and the Wear emulator.
Here, as you see, the arrow zero.
This is the problem which I face, which has only one-way communication, which means the
notifications from the device emulator will appear on the Wear, but not vice-versa.
For example, if you have an app which is doing something which you can send a command from
your watch to the device, that scenario is not able to test it due to some limitations.
The command doesn't go from the watch to the Wear.
So here we need to see how we can connect it.
Here, we need to create an emulator here.
Note that we need to create a Google API image.
While creating the device emulator, we need to select the Google API image, this one here,
not the Google image, which this has the support for these wearable devices.
Then we create a smart watch emulator.
Then we need to connect to the TELNET board of the device, and we need to do a port redirection
again.
As you see, we can run these commands here under the port redirection.
Once you get the status okay, then you can get this emulator connected.
Now we are good to go for automation.
But the other problem would be only that features -- one-way features can be tested.
Now, the second -- Now we have the context of the watches on our code.
Then we can start writing our automation thing.
We can use any tool, but here, the example is with the Appium.
So here, Appium on multiple devices at the same time, if you want to execute or write
a test case, you need to have multiple sessions, which each session is tied to a particular
device.
And while starting each session of the server, you need to mention the overwrite option as
true so that it can use the existing session instead of creating a new session every time.
Then this is a code snippet where you start the Appium servers for the different board
numbers for both the devices.
Here is pseudocode to get the driver.
This driver is for the smartphone.
And here is the driver for the smart watch.
So here you see we have to give the parameters as a device name with the device IDs of the
smart watch, and here is the device ID of the wearable.
Then here, once we get these drivers, we can write our clicks, drags, drops, anything you
want.
So this is the kind of framework what we have for our automation part.
Here we have the Appium thing, setting, which all the sessions of the servers are connected.
And we have the smart watches, all the emulators connected to the phones.
And here's a driver which runs our -- all our automation.
So here is a video which shows two automation execution of two features.
One is from the phone.
There is a notification.
The smart watch, there's a command which will go to the phone.
And you execute some steps on the phone.
Then again we -- I installed one malicious application on the phone, and we get the notification
on the watch.
And then we can open that particular notification on the phone itself.
And you see the notification has been opened on the phone.
So this is a both-way notification from the device to the smart watch, and smart watch
to the device.
Yes.
A few things to -- the problem areas what we faced.
The problem -- first problem area is when we have an actual device and a -- an actual
wearable.
Once we established this USB -- Bluetooth debugging session, so on the smart watch,
there is a sticky notification which appears, "Bluetooth debugging enabled."
It doesn't go off.
It always stays on the screen.
So when we want to test actual notification, we should pop up on the smart watch, as it
is a critical notification from the phone.
So that always lies beneath the Bluetooth notification, debugging Bluetooth notification.
So you need to either flick it or do something to see the next one.
It appears, but you will not be able to test the scenario that it should always top up
on any other notification, (indiscernible) system notification.
That is one other issue.
The other issue, as I said, is with emulator, when both are emulators, this one-way communication
happens.
These are the two issues which is -- currently we have.
But the actual device and the real -- and the emulator Wear is the best one until now.
Yeah.
So that's it from my side.
We can have some questions.
[ Applause ] >>Yvette Nameth: Thank you.
So do you have a similar solution for iOS devices?
>>Anurag Routroy: This is from past three months when we started with this Android thing.
So iOS, probably we should be able to do that.
But we haven't deep dived into the iOS stuff yet.
iOS smart watch, it's very costly to get it for testing.
>>Yvette Nameth: How did you test the Intel Edison?
>>Anurag Routroy: We don't test Intel Edison.
First of all, I don't know what Intel Edison is.
[ Laughter ] I test on this product called McAfeeMobile
Security, which we have -- in the last release, we had this wearable feature.
(indiscernible) picture, like whatever notification we have, like, virus notification, or if there
is a Wi-Fi attack on your connected network to your phone, you get all those alerts on
the devices.
So we started testing the automation of that, because this is a (indiscernible) big feature
to do that, and automation was really helping.
>>Yvette Nameth: Why did you use Appium instead of UIAutomator?
>>Anurag Routroy: Just as I said, we can use any tool.
This is Appium.
It's just a pseudocode, like, how we can use the automation here for Android devices.
The main thing was here how to get the context and how to establish the USB debugging session.
Once that is done, any tool you can use to do that, it's not Appium.
Anything you can use.
The main thing is once it gets listed in the debugging session, USB debugging session.
>>Yvette Nameth: Is the use of emulator slow?
>>Anurag Routroy: Yes.
I had the same question, I think, to the Uber team there.
They suggested -- like, they're really slow, but some Junior -- some new thing.
But that was just really -- Junior Motion (indiscernible).
But, yeah, the emulators are really slow.
(indiscernible) the Google AP image for our thing, it's, again, very slow than the actual
one.
>>Yvette Nameth: All right.
And somebody's asking, isn't testing notifications on a smart watch the same as testing the smart
watch itself?
>>Anurag Routroy: No.
Here we are testing the features of the application, which has to appear on the watch.
It may happen that a watch is working perfectly fine but the notification doesn't appear on
the phone.
We had that kind of thing in our release (indiscernible) -- before our release, we found that kind
of thing where the notification was not appearing on the phone.
>>Yvette Nameth: And that is all of the questions for you.
>>Anurag Routroy: Thank you.
>>Yvette Nameth: So thank you very much.
>>Anurag Routroy: Thank you.
[ Applause ]