AndroidDriver

[Mirko Nasato]

Hi all,

I was looking for an AndroidDriver, and found a wiki page and some
code in the old repository

http://code.google.com/p/selenium/wiki/AndroidDriver
http://code.google.com/p/webdriver/source/detail?r=1161

but nothing in the new repository

http://code.google.com/p/selenium/source/browse/#svn/trunk

Anybody knows what's the state of that driver?

Thanks

Mirko

[Miki]

Hello Mirko,

> but nothing in the new repository
>  http://code.google.com/p/selenium/source/browse/#svn/trunk
>
> Anybody knows what's the state of that driver?

Have a look at http://code.google.com/p/selenium/source/browse/#svn/webdriver/branches/android
Some documentation at http://code.google.com/p/selenium/wiki/AndroidDriver

HTH,
--
Miki

[Simon Stewart]

The branch for the android driver hasn't been moved yet, so it's still
in the old location. Over the next week or two, I shall be reviewing
all the branches in the webdriver tree and either deleting or moving
them.

Regards,

Simon

> --
>
> You received this message because you are subscribed to the Google Groups "webdriver" group.
> To post to this group, send email to webd...@googlegroups.com.
> To unsubscribe from this group, send email to webdriver+...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/webdriver?hl=en.
>
>
>

[Mirko Nasato]

Thanks. I was basically wondering if that Android branch was actively
maintained or had been abandoned.

I've just given it a try, but I couldn't get it to work in an hour or
so. The wiki page lists a number preliminary installation steps
anyway. I was hoping to find something you can just point to your
Android SDK, and will start the emulator if it's not running, install
itself and run, in the same way you can start your Android apps from
Eclipse.

I may investigate an alternative approach in the next few days.

Kind regards

Mirko

On Dec 15, 6:47 pm, Simon Stewart <simon.m.stew...@gmail.com> wrote:
> The branch for the android driver hasn't been moved yet, so it's still
> in the old location. Over the next week or two, I shall be reviewing
> all the branches in the webdriver tree and either deleting or moving
> them.
>
> Regards,
>
> Simon
>

[Simon Stewart]

Yeah, the goal is to get to that point. For now, it's a bit of an
uphill struggle. Right now it's composed of three pieces:

1) An android apk that controls a webview
2) A WAR that communicates with the app from 1
3) iJetty, to host the WAR

Once those moving pieces are in place, things tick along quite nicely.
Right now, I've only ever seen it run on about 3 devices, and all of
them took waaaay too much effort to get running. Hopefully we'll boil
everything down to a single app in the end.

Simon

[Mirko Nasato]

Maybe it could use instrumentation instead of iJetty + war?

http://developer.android.com/reference/android/app/Instrumentation.html

Kind regards

Mirko

On Dec 21, 9:56 pm, Simon Stewart <simon.m.stew...@gmail.com> wrote:
> Yeah, the goal is to get to that point. For now, it's a bit of an
> uphill struggle. Right now it's composed of three pieces:
>
> 1) An android apk that controls a webview
> 2) A WAR that communicates with the app from 1
> 3) iJetty, to host the WAR
>
> Once those moving pieces are in place, things tick along quite nicely.
> Right now, I've only ever seen it run on about 3 devices, and all of
> them took waaaay too much effort to get running. Hopefully we'll boil
> everything down to a single app in the end.
>
> Simon
>

[Simon Stewart]

The main reason for going with the approach we have is that it means
that the client-side piece comes "for free". Our plan is that anything
that is out of process should use the remote webdriver protocol. Since
we're not going down the route of auto-generating the language
bindings (which is what we did in Selenium 1) this means we have a
better chance of getting parity between the languages.

In the end, I imagine we'll end up implementing a really simple HTTP
server that only understands enough HTTP for webdriver clients to
connect (and not the entire spec) for Android.

Simon

[Mirko Nasato]

I see. I haven't actually used WebDriver in a while so I'll have some
catchup to do, e.g. regarding RemoteWebDriver.

In any case, I had a quick a look at how Android unit tests are run by
the Eclipse plugin, because that clearly involves some sort of
communication with the emulator/device, which may be useful for
AndroidDriver as well.

It uses ddmlib.jar which is shipped with the Android SDK, basically a
wrapper for adb. It makes it very easy to install an app into Android,
launch it (possibly with instrumentation), send intents to it, read
back any output, take screenshots, etc. For example a quick snippet
that connects to an emulator/device and launches the browser at the
given URL is

AndroidDebugBridge.init(false);
AndroidDebugBridge bridge = AndroidDebugBridge.createBridge
(ANDROID_HOME + "/tools/adb", false);
while (!bridge.isConnected()) {
Thread.sleep(100);
}
IDevice device = bridge.getDevices()[0];
device.executeShellCommand("am start -a android.intent.action.VIEW -
d http://www.google.com", new NullOutputReceiver());
AndroidDebugBridge.terminate();

This could be used as the main communication channel, with the driver
sending commands to the Android browser as intents, and reading back
responses from the OutputReceiver, like the RemoteAndroidTestRunner.
Or it could be used only to detect emulators/devices and install an
Android app that then listens for HTTP commands, I don't know, but in
any case this ddmlib looks useful.

Kind regards

Mirko

On Dec 23, 12:14 pm, Simon Stewart <simon.m.stew...@gmail.com> wrote:
> The main reason for going with the approach we have is that it means
> that the client-side piece comes "for free". Our plan is that anything
> that is out of process should use the remote webdriver protocol. Since
> we're not going down the route of auto-generating the language
> bindings (which is what we did in Selenium 1) this means we have a
> better chance of getting parity between the languages.
>
> In the end, I imagine we'll end up implementing a really simple HTTP
> server that only understands enough HTTP for webdriver clients to
> connect (and not the entire spec) for Android.
>
> Simon
>

[Simon Stewart]

Wow, that does look useful. I'm not sure if the people looking into
supporting android have had a look at this yet, so I'll forward this
to them. I'm still very keen to avoid using a different communication
protocol because it adds considerably to the amount of effort it takes
to support the driver with a different language binding; although
implementing the RemoteWebDriver's JSON over HTTP protocol in the
driver is a PITA, it only needs to be done in one place.

Regards,

Simon

[Mirko Nasato]

Thanks. Shame that the others interested in the AndroidDriver are not
following this group. I'm keen to have a way to automate web testing
on Android, so I'd be willing to contribute, but I don't want to
duplicate efforts either.

BTW here's a couple of related projects: http://code.google.com/p/autoandroid/
and http://code.google.com/p/robotium/

Kind regards

Mirko

On Dec 24, 7:42 pm, Simon Stewart <simon.m.stew...@gmail.com> wrote:
> Wow, that does look useful. I'm not sure if the people looking into
> supporting android have had a look at this yet, so I'll forward this
> to them. I'm still very keen to avoid using a different communication
> protocol because it adds considerably to the amount of effort it takes
> to support the driver with a different language binding; although
> implementing the RemoteWebDriver's JSON over HTTP protocol in the
> driver is a PITA, it only needs to be done in one place.
>
> Regards,
>
> Simon
>

> On Wed, Dec 23, 2009 at 5:18 PM, Mirko Nasato <mirko.nas...@gmail.com> wrote:
> > I see. I haven't actually used WebDriver in a while so I'll have some
> > catchup to do, e.g. regarding RemoteWebDriver.
>
> > In any case, I had a quick a look at how Android unit tests are run by
> > the Eclipse plugin, because that clearly involves some sort of
> > communication with the emulator/device, which may be useful for
> > AndroidDriver as well.
>
> > It uses ddmlib.jar which is shipped with the Android SDK, basically a
> > wrapper for adb. It makes it very easy to install an app into Android,
> > launch it (possibly with instrumentation), send intents to it, read
> > back any output, take screenshots, etc. For example a quick snippet
> > that connects to an emulator/device and launches the browser at the
> > given URL is
>
> >                AndroidDebugBridge.init(false);
> >                AndroidDebugBridge bridge = AndroidDebugBridge.createBridge
> > (ANDROID_HOME + "/tools/adb", false);
> >                while (!bridge.isConnected()) {
> >                        Thread.sleep(100);
> >                }
> >                IDevice device = bridge.getDevices()[0];
> >                device.executeShellCommand("am start -a android.intent.action.VIEW -

> > dhttp://www.google.com", new NullOutputReceiver());

[Mirko Nasato]

For the record, I eventually tried with Selenium 1.0 and managed to
get it to work with the Android Browser. Details at
http://mirkonasato.blogspot.com/2010/01/android-browser-testing-with-selenium.html

Kind regards

Mirko

[Julian Harty]

Mirko,
Congratulations on managing to get Selenium RC to work with Android.
Even though - as you say - it may be experimental, you've managed to
create a working proof-of-concept.

I am one on the people who has worked on the Android Driver, mainly in
terms of helping sort out the configuration, testing the initial
implementation and writing some of the documents - I'm not a hard code
developer... Anyway, here are my current thoughts on your suggestion
of creating a custom implementation using ADB and instrumentation:

1. The current implementation is probably more convoluted and relies
on more moving parts (including dependencies) than I'd like. So
finding ways to streamline it would be good...

2. The Remote WebDriver protocol provides a fairly effective interface
between clients and servers, so I'd prefer to use it at some point in
the chain (even if it becomes the 'front-end' for an ADB-driven
implementation).

3. The current design decouples the Android device (and driver
implementation) from the client machine, and potentially the Android
device could be in a remote location. I don't know whether ADB could
be used reliably over a remote connection, if not, using ADB can
potentially limit some deployment options - however I expect only a
subset of users would be interested in remote deployments (although
we're one company who might :)

4. I'd be willing to help review, test and document an ADB-driven
implementation if you are willing to contribute code.

FWIW I'm also working on another Android project
http://code.google.com/p/android-daisy-epub-reader/ but there's not
much overlap with this project in terms of technologies, etc.

Julian Harty

2010/1/3 Mirko Nasato <mirko....@gmail.com>:

[Mirko Nasato]

Hi Julian,

Thanks for you comments.

I think what my experiments with Selenium RC show is that at least
it's possible to drive the Android browser using JavaScript injection.

I had a more in-depth look at the existing AndroidDriver before
resorting to Selenium 1.0. There's something else that I don't fully
understand and that could have big implications. WebView[1] doesn't
provide access to the page DOM natively. The driver currently
interacts with the page by sending JavaScript commands via
WebView.loadUrl("javascript:..."). Is that enough to implement all the
required WebDriver functionality? I suspect we'd need a way to
interact with the page more closely.

Kind regards

Mirko

[1] http://developer.android.com/reference/android/webkit/WebView.html

> FWIW I'm also working on another Android projecthttp://code.google.com/p/android-daisy-epub-reader/but there's not

> much overlap with this project in terms of technologies, etc.
>
> Julian Harty
>

> 2010/1/3 Mirko Nasato <mirko.nas...@gmail.com>:

>
> > For the record, I eventually tried with Selenium 1.0 and managed to
> > get it to work with the Android Browser. Details at

> >http://mirkonasato.blogspot.com/2010/01/android-browser-testing-with-...

[Alex Bergman]

Hi Mirko,

As a main developer of Android WebDriver I'd like to explain a bit
about its implementation and answer your questions / concerns:

- As Julian said already the reason for implementing Android client as
two
separated apps, while making deployment a bit complicated, has
numerous
advantages: it follows the same JSON remote protocol as the rest of
remote
clients and reuses most of the remote server code (with only a tiny
wrapper).
Additionally, it separates the business login for a specific UI from
the communication
medium, thus making it easy to support other methods/protocols of
communication
and to alter each part separately. For example, last week I submitted
another
version of the UI (a simple, fast, single-session version) without
changing the
webapp at all.

- The approach of using HTTP server to communicate instead of ADB
interface
has one more advantage: the ADB interface is available only with
emulator or via
USB cable connection to ADB-enabled host computer. It's not always the
case
(at least not for our internal usage of Android WebDriver).

- The Android branch hasn't been integrated into trunk yet. I'm
working with
Simon on doing this soon. Anyway, this branch is being actively
developed by me
and, at least, another Google engineer. Our goal is to support the
full
WebDriver functionality.

- Few words regarding the implementation: you're right when saying
that WebView
control doesn't provide access to DOM at this moment. However it
provides the ability
to introduce you own JavaScript classes implemented in Java (take a
look at the
CustomJavaScriptInterface class in SessionListActivity). This way I
can get back
results of any JavaScript query (you can see it in onActionRequest
method).

Please reply if you have any other questions.

Best Regards,
Alex.

> > FWIW I'm also working on another Android projecthttp://code.google.com/p/android-daisy-epub-reader/butthere's not

[Mirko Nasato]

Hi Alex,

Good to hear that the AndroidDriver is still being actively developed,
and thanks for your explanations.

Yes I do understand the advantages of HTTP now. My hope is that the
installation steps will be simplified when the driver is more
complete, e.g. by using ADB to install the app (at least as an
option), and maybe embed iJetty into a single app.

My doubts about WebView were due to seeing that e.g. WebElement.click
() (if I remember correctly) said "not implemented" and thinking that
maybe that was because of a limitation in the current approach. But
I'll happily leave that to you. :)

My main goal was to find a way to test webapps in Android, and it
seems that Selenium 1.0 sort of works, so I'll stick with that for
now.

Kind regards

Mirko