Complete Android build work

[mattheworiordan]

We've updated the project structure and the current status is in https://github.com/ably/ably-java/tree/project-struct-update

The aim of the update is to split the builds for the android and java versions of the library so that the appropriate toolchain is used for each. This means that we can provide artifacts in the most appropriate format (ie .aar for Android) and in future will enable us to add platform-specific implementations of new features.

Current status is:

• most of the library code and tests are in a new, common, core subproject
• a java subproject builds the jar files for the Java Runtime Environment (JRE) and includes the associated test tasks;
• an android subproject is an android library project, builds the .aar, and includes an androidTest task to build a test .apk;
• the java library builds and the tests run.

The work needed now is to:

• ensure that the android build works and the android tests run; at a minimum this should work on a target connected device and ideally also in Travis.
• Android tests should include the common core tests and the structure should allow for the Android Suites to be extended to include Android-specific tests.
• Java and Android library artifacts should be separately available in jcenter.
• the README should be updated to reflect any changes in building, running and running tests.

Please note that once this work is complete, the PRs #128 and #125 should be reviewed and any functionality introduced should be extracted and rebased onto this work.

[mattheworiordan]

Please note if you have any questions, please speak with @paddybyers in the #client-libraries channel

[dsvishchov]

So all in all after working on this for some time there are some questions and things to discuss.

Questions:

1. according to the latest commit of @paddybyers there is no task to build a test .apk, or I am I missing something?

My vision of how it has to work ideally (please review and confirm/adjust/ask):

1. since we split into Java and Android we need to ideally have 3 different jobs in Travis (if possible, still investigating), two of them for JDK7 and JDK8 and a separate one for Android;
2. we need to build a separate test .apk which links against library and might contain Android-specific tests (I'd create one just for test purposes);
3. while doing connectedCheck we need to deploy actual apk to device/emulator and run core tests (currently two suites) + Android specific tests;

Currently I have Travis script running both Java jobs successfully (testing on a separate account) and also Android environment being setup and emulator running under Travis.

As of now there are issues related to Travis script to split jobs Java/Android which I'm still investigating.

@paddybyers ping me on Slack please once you're available to discuss further in a bit more details

[mattheworiordan]

@dsvishchov I will see if we can get @paddybyers to respond. He is flat out on a serious bug we have discovered in the system which is causing intermittent delays. I'll see if he can spare some time quickly.

[paddybyers]

1. according to the latest commit of @paddybyers there is no task to build a test .apk, or I am I missing something?

Isn't this already done by the standard android:assembleAndroidTest task?

since we split into Java and Android we need to ideally have 3 different jobs in Travis (if possible, still investigating), two of them for JDK7 and JDK8 and a separate one for Android;

ok

we need to build a separate test .apk which links against library and might contain Android-specific tests (I'd create one just for test purposes);

I think building the test apk already part of the android-library gradle framework. But yes, for verification purposes it would be a good idea to invent an android-specific test and include it and show that it gets included.

while doing connectedCheck we need to deploy actual apk to device/emulator and run core tests (currently two suites) + Android specific tests;

Doesn't connectedCheck already do this?

[paddybyers]

I should add that we can merge this work as soon as we have Travis support for JDK7, and we can successfully run (ie pass) connectedCheck on the desktop with an attached device. Getting the Android device test running from Travis isn't a blocker for release.

[dsvishchov]

1. Yes, you're right about android:assembleAndroidTest;
2. Already added Android-specific tasks;
3. Yes, you're right about connectedCheck, just confirming. As of now we have tests running on both locally connected device and Travis as well, there are couple of technical issues we're working on and then just need to make tests pass;

Once we have (I hope tomorrow) everything up and running properly and remaining thing will be to fix (or probably exclude some) tests on Android I'll issue a PR to review.

On a side note: we've also modified Travis script to workaround JDK7 issue in a right way without using "sudo" and switched to Travis sandbox environment with "trusty" dist instead of "precise", all tests passed properly on our Travis test account for both JDK7 and JDK8, however once pushed to existing PR one of test fails (investigating).

[dsvishchov]

Pushed current state to appropriate branch. Currently it runs JDK7 (one test keeps failing, the rest are passing), JDK8 (all tests passing) and Android (some of them passing, some not, working on making them run properly). Just FYI in case you want to check current state and how it works.

[dsvishchov]

Status update: made required changes to Android build, now tests run on the device without fails so far (takes quite long, we left them running on the device with 62 successfully passed). Will see how the final result in the morning and will provide an update.

[mattheworiordan]

Nice, thanks @dsvishchov

[paddybyers]

Currently it runs JDK7 (one test keeps failing, the rest are passing)

out of interest, which test was failing?

And which Android tests are taking a long time? I'd expect it to be slightly slower but not as much as it seems to be.

I will try to pull down what you've done and check it out on a device tomorrow.

[dsvishchov]

We discussed tests with @mattheworiordan and agreed to have a separate ticket for current and further discussions regarding tests running locally and on Travis. So I'll create it during the day today.

[dsvishchov]

Please check the latest update and detailed description of test issues in a separate ticket:
#159