Use Travis Android support

[WonderCsabo]

This is a WIP. I did not squash the commits, so you can see exactly what steps I did while experimenting.

This PR:

• uses native Travis Android
• Travis Docker infrastructure
• enables caching
• enables integration tests
• upgrades emulator to 22
• cleans up .travis.yml
• changes Morseflash to use Espresso

Unfortunately the Morseflash test fails sometimes, because the emulator is not unlocked despite it is instructed to. To debug this I print the build log and save the screenshots to a repo. Any help is appreciated to fix this last problem.

[mosabua]

Imho we should pull this in. And maybe improve the plugin to only kick off instrumentaiton

[mosabua]

Also this migrates from using robotium to espresso so we might have to update some docs. Do we still need a robotium example? Maybe not. Wdyt @simpligility/android-maven-plugins-core-committers

[WonderCsabo]

Imho we should pull this in.

Well, the build fails lots of times because of the problem i described. I asked about it on adt-dev for help.

Also this migrates from using robotium to espresso

No, this migrates from plain instrumentation tests to Espresso.

And maybe improve the plugin to only kick off instrumentaiton

I do not understand.

[WonderCsabo]

Also, do not pull this as is, it clearly needs a rebasing (i think), as i wrote in the OP.

[mosabua]

Sure.. you can rebase and fix it up. But in general I like the content ..definitely an improvement and it fixes issue #495

[WonderCsabo]

Thanks for the feedback. I agree the content is good. :) But this unlock screen thing really annoys me.

[mosabua]

Maybe we can ensure via some sort of api call that it is unlocked before we start the tests. I vaguely remember we had something like that in the past.

[WonderCsabo]

I found this method. However, this seems to be deprecated. Also in comments it is said that the current method is more reliable... Finally, this would add noise to the sample app. But we can try it anyway.

[mosabua]

We used to use this.

https://github.com/simpligility/android-maven-plugin/blob/master/wait_for_emulator

[mosabua]

The unlock device thing seems horrible with code and manifest requirements. Surely there is some better way.. maybe a config on how to start up the emulator or something.

[WonderCsabo]

@mosabua that script is used to wait for the emulator to start, and block until. It has nothing to do with the lock screen. Actually this PR also use that (a modified version). The lock screen is dismissed with this command (which was completely missing before).

[WonderCsabo]

I asked this on adt-dev, but i am being ignored. @mosabua please ask this directly if you can...

[malachid]

The script that Manfred was talking about was always an unreliable pain
because it was timing specific. It we turned on debug logging, it would
behave differently.

It sounds like you are trying to find something to unlock the lockscreen
once the emulator is running. Looking on Stack Exchange, it seems that the
different adb methods (like sending the menu key) are specific to certain
OS releases. What about programmatically sending a wake lock?

Alternatively, if we start up an emulator, configure it to never go to
sleep... Maybe we can take a snapshot and reuse it rather than starting a
new one?

On Fri, Jun 26, 2015, 12:39 AM Csaba Kozák [email protected] wrote:

I asked this on adt-dev
https://groups.google.com/forum/#!topic/adt-dev/19XXQ1kC15g, but i am
being ignored. @mosabua https://github.com/mosabua please ask this
directly if you can...

—
Reply to this email directly or view it on GitHub
#641 (comment)
.

[WonderCsabo]

Maybe we can take a snapshot and reuse it rather than starting a new one?

That would mean saving the snapshot image into the repository, not something i would prefer. Or how much data it means?

The script that Manfred was talking about was always an unreliable pain because it was timing specific.

We still use that script (modified version), unfortunately there is no better solution. But that script is okay, at least it works reliably.

What about programmatically sending a wake lock?

I think i wake lock is not enough, you have to disable the lock screen also. I already linked this method, hinted by the official Android doc, but it is deprecated and horrible.

[mosabua]

Can we maybe create a emulator image that has no lock screen functionality at all?

[WonderCsabo]

@mosabua i Googled for this for an hour (literally) and i did not found any remedy.

[mosabua]

It seems ridiculous .. is nobody using emulators in CI usage? Any hints on how to get around the lock screen for CI usage running integration tests @JakeWharton @orrc @kingargyle @ducrohet

[WonderCsabo]

@mosabua maybe i am a noob, but this is very annoying indeed.

[JakeWharton]

Use adb to send keyevent 82. See:
https://github.com/JakeWharton/NotRxAndroid/blob/master/.travis.yml

On Fri, Jun 26, 2015, 10:27 AM Csaba Kozák [email protected] wrote:

@mosabua https://github.com/mosabua maybe i am a noob, but this is very
annoying indeed.

—
Reply to this email directly or view it on GitHub
#641 (comment)
.

[JakeWharton]

Can also have test runner unlock and wake up the device:
https://github.com/JakeWharton/u2020/blob/master/src/androidTestInternal/java/com/jakewharton/u2020/U2020TestRunner.java

On Fri, Jun 26, 2015, 10:38 AM Jake Wharton [email protected] wrote:

Use adb to send keyevent 82. See:
https://github.com/JakeWharton/NotRxAndroid/blob/master/.travis.yml

On Fri, Jun 26, 2015, 10:27 AM Csaba Kozák [email protected]
wrote:

@mosabua https://github.com/mosabua maybe i am a noob, but this is
very annoying indeed.

—
Reply to this email directly or view it on GitHub
#641 (comment)
.

[WonderCsabo]

@JakeWharton Thanks! We already use that, and it turned out sometimes that command does not unlock the emulator. At least the screenshots says that.

[WonderCsabo]

I try the second approach ASAP.

[mosabua]

Thanks @JakeWharton ... @WonderCsabo maybe it is working and the screenshots are just a timing issue. Maybe if we get it to pass consistently, even without screenshots, that would be good.

[WonderCsabo]

@mosabua the screenshots are fine i think. Actually our tests are failing, because Espresso is complaining about the unfocused window. The window is unfocused because the lock screen is on top and not our Activity.

[WonderCsabo]

This is the failure we get beause of the locked screen.

[malachid]

I saw others had the same problem a year ago on another project and
contributed a fix

https://github.com/finn-no/android_emulator_hacks

Malachi de Ælfweald
http://www.google.com/profiles/malachid

On Fri, Jun 26, 2015 at 10:46 AM, Csaba Kozák [email protected]
wrote:

This
https://travis-ci.org/WonderCsabo/maven-android-plugin/builds/67328053#L3875
is the failure we get beause of the locked screen.

—
Reply to this email directly or view it on GitHub
#641 (comment)
.

[WonderCsabo]

@mosabua it seems it fixed our problem, thanks to @JakeWharton. However, we had to add two permissions to the app manifest. I remember you did not like that. Are you okay with it? If not do you have an idea to not add this to the app manifest directly?

[mosabua]

Lets just add it and get this merged. For production usage I would not like that but you could always modify the manifest in a profile or whatever. Lets not worry about this though.

[WonderCsabo]

@mosabua let me clean up the commit history, then you can merge it.

[mosabua]

Sounds good. Alternatively I can merge it manually and squash it. Or you can create a new branch off it that does that and a new pull request ;-)

If you want me to squash it just let me know the details for the commit summary...

[WonderCsabo]

I am rebasing this branch.

[mosabua]

Sounds good.

[mosabua]

Ping me when you are happy and want me to merge. Dont forget the changelog entry ;-)

[WonderCsabo]

Done, i hope you the change grouping is okay. Let's wait for the CI.

[WonderCsabo]

@mosabua i think this is finished.

[mosabua]

You rock @WonderCsabo ;-)

[mosabua]

Check it out @simpligility/android-maven-plugins-core-committers

[mosabua]

And now master builds and we are green ;-)

[malachid]

Sweet. Great job Csaba.

On Fri, Jun 26, 2015, 4:14 PM Manfred Moser [email protected]
wrote:

And now master builds and we are green ;-)

—
Reply to this email directly or view it on GitHub
#641 (comment)
.