To take advantage of some of the new nested virtualization capabilities
of some of the images in Travis, you must be using the newest LTS
release of Ubuntu, 18.04 Bionic Beaver.
However, the Travis image of Bionic does not include support for JDK 8,
which we need to utilize the Android SDK manager. To circumvent this
issue, we change from the "android" language type to "generic", and take
care of both the JDK and the Android SDK ourselves.
As such, this commit makes the following changes:
* Switch `dist` from `trusty` to `bionic`
* Switch `language` from `android` to `generic`
* Enable the use of `sudo`
* Install libpulse0 for emulator audio
* Set up KVM inside the allocated Travis image
* Use Gravis repository to download and install Java
* Version android-wait-for-emulator in our repo
* Download and install the Android SDK ourselves
* Switch to `emulator-headless` for the x86 emulators
Since we're free to switch Java versions as we please, we can finally
support JDK 11 by switching to it after starting our emulator.
This adds support in Travis to build API 24 with Oracle JDK 11. However,
at the current time, only Oracle JDK 8 is in active use on the project.
As such, we allow JDK 11 builds to fail without affecting the build
status for the project overall.
In Travis, "jobs" is an alias for "matrix". This is not very clear, and
is mentioned casually and off-handedly in their documentation. To help
clean up the config file, we also remove the old "matrix" block,
squishing it down into the "jobs" block.
The bump from 28.0.3 to 29.0.5 broke emulators on travis, but happily
just moving to the canary fixed the existing emulators and added the ability
to run x86_64 images unaccelerated, so we have modern APIs.
Still work to do (relaxing timings mostly) to get 28+Q working but it's possible.
Upstream issue + discussion here
ttps://travis-ci.community/t/android-emulators-not-starting-for-the-last-few-days-late-march-2019/2871/4
This appears to be a progressive disease related to code growth
or something, unsure. Bears examination later but in the meantime
CI should never flake
They are combining their Linux infrastructure to be all
VM-based and not container-based, which was what the sudo
directive did, modulo our "android" config which meant we
went to VMs all the time (confirmed with their support)
So this doesn't change our CI execution at all but does
conform with their current guidance
Travis is flaky at best on emulators, and adding UI tests with
all of their inherent timing issues to Travis would make it
unreliable. These @LargeTest ones work well locally though
- Upgrade JUnit3+AndroidTestCase to JUnit4 + Annotations
- Add ATSL (Android Test Support Library, new from google)
- Fix test permission errors w/@GrantPermissionRule from ATSL! API 24 works!
- https://developer.android.com/reference/android/support/test/rule/GrantPermissionRule
- Run tests with orchestrator to run connected tests; crash+state isolation
- Added a "RetryRule" to re-run a flaky test and used it on MediaImporter, works 2000 times and fails 1...
- fix api gradle deprecation, add warn comment in gradle wrapper
- buildtools 27.0.3 needs to be added w/license accepted
- install SDK API 16 to match emulator API 16, remove extra tools
- tools components entry twice per Travis docs
- only including build-tools 26.0.2 as it is default per my read
- only including one android API for the build
- removing non-existent extra-android-support
- changing from API-22 emulator to API-16 per performance documentation on web
- removing "no-skin" emulator argument as it is not supported
- upgrade to gradle 4.5.1 / gradle plugin 3.1.2
- alter gradle dependencies to modern fine-grained declarations
- move api build targetSdk to match main build targetSdk
We used to name the main branch "develop" and "master" contained the latest released source code. We no longer do this, and "master" contains the latest development source code
Material dialogs still requires 24.0.3, even in the latest version:
https://github.com/afollestad/material-dialogs/issues/1245
and in fact we can't use the latest version of material dialogs because it would increase the minimum SDK version
