Add Gradle-based integration project for Android & setup new CI pipeline for the project

[mannodermaus]

Add a new test-android-gradle project to the repository and weave in the existing cache2k-testsuite for execution on Android devices and emulators. Replace the existing CI pipeline with a new connection to CircleCI. Note that I did not remove the existing .travis.yml here, however we may want to consider doing that to complete the transition to Circle.

An exemplary execution of the new CI pipeline can be found on my fork. I'm open to further clarifications regarding when these steps should be executed - at the moment, they run on any commit and PR.

This process was performed in several steps:

• 50ac6e7
  • For cache2k-testsuite, revert the deactivation of JAR output from its parent module (test-parent)
  • The JAR is needed so that Android can consume its tests
• a5b483b
  • Add a Gradle project with a basic Android library configuration (AGP 7.0, Gradle 7.3)
  • Configure androidTest dependencies to consume JUnit 4 and 5 in tandem (courtesy of android-junit5)
  • Add a symbolic instrumentation test to the project's androidTest source set. This is required in order for the Android test instrumentation to start its work; otherwise it would not even detect cache2k's tests in the transitive JAR
  • Add custom build logic to integrate this Gradle project with the Maven build process of cache2k-testsuite and its transitive dependencies
• 482eec6
  • Revamp the CircleCI config file to include a parallel build of the Android project next to the existing Maven job
  • Android tests are exercised on API 26 (Android 8.0) and 30 (Android 11)
  • Add auto-generated Gradle wrapper files to the Android project so that the CI script can invoke it correctly
• 529acfc
  • Add another status badge to README.md

Resolves #143.

[cruftex]

Wow! Cool stuff! But do you want to ruin my Sunday with an early Christmas present?!
I will try hard not to look into it before Monday ;)

[cruftex]

@mannodermaus thanks again for the great work!

Thoughts:

The test results in CircleCI are only containing the method name. Is it possible to have at least the class name as well?

I suggest we make a sequence (via requires): maven, API 26, API 30. It does not make sense to run the Android test, if the normal tests fail already. The additional delay is okay.

Is it possible to have a separate badge for the Android test? Or even one for API 26 and another for API 30?

[mannodermaus]

The test results in CircleCI are only containing the method name. Is it possible to have at least the class name as well?

Unfortunately, the test insights dashboard on Circle doesn't seem to care about the inclusion of class names in the XML report delivered to it. As it seems to be a beta feature, here's to hoping that they'll improve their integration with JUnit test reports eventually.

I suggest we make a sequence (via requires): maven, API 26, API 30. It does not make sense to run the Android test, if the normal tests fail already. The additional delay is okay.

a51c943 updates it accordingly. Another run on my fork confirms the sequential execution.

Is it possible to have a separate badge for the Android test? Or even one for API 26 and another for API 30?

Unfortunately, no. Circle badges operate on branches, so while it would be possible to have a badge dedicated to a specific branch, it's not possible to have it for individual steps of a workflow. That being said, I update to the shield-style design in a83b98e to make the Circle badge fit in with the others on the README: