Android Beta: 'Freeze' the Compatibilty Contract/Guidelines #2296

gildegoma opened this Issue May 12, 2014 · 10 comments


None yet

5 participants

Travis CI member

In order to avoid to break project builds when upgrading the Linux VM image, it is preferable to not pre-install build-tools-x.y.z components and thus force each project to explicitly declare the required version.

We also might have to revisit the list of pre-installed components, and maybe trim a bit...

Related stuff:

@gildegoma gildegoma referenced this issue in travis-ci/docs-travis-ci-com May 12, 2014

Update Android Beta documentation #63

@gildegoma gildegoma added a commit to travis-ci/travis-cookbooks that referenced this issue May 13, 2014
@gildegoma gildegoma Android SDK: Don't install build-tools components d66c997
@BanzaiMan BanzaiMan added the android label May 21, 2014
@gildegoma gildegoma added a commit to travis-ci/travis-cookbooks that referenced this issue Jun 27, 2014
@gildegoma gildegoma Android SDK: accept all the licenses by default 0413363
Travis CI member

For the records, the introduction of Android SDK 23 presents following compatibility issues:

Some components were removed/reorganized/renamed

Let's illustrate it with a concrete example:

Formerly the same sysimg-17 component could potentially install ARM, Intel or MIPS variants, depending on how many licenses were accepted. For that reason, we introduce the ability to accept a subset of the prompted licenses.

As of Android SDK 23, three independant components are now released instead of sysimg-17:

  • sys-img-armeabi-v7a-android-17 (current license: android-sdk-license-5be876d5)
  • sys-img-x86-android-17 (current license: intel-android-sysimage-license-9ae63a51)
  • sys-img-mips-android-17 (current license: mips-android-sysimage-license-65b5afcc)

The advantage of pre-installing the most popular system images, people don't have to explicitly specify moving targets like sysimg-17 or sys-img-armeabi-v7a-android-17 in their .travis.yml, which is good for backwards compatibility.

If we proceed this way, we'll only need to announce when we add or remove some pre-installed images after a build environment update.

On the other hand, it is good to keep in mind that these system images use lot of disk space:

# Currently pre-installed:
172M  system-images/android-15/default
203M  system-images/android-16/default
210M  system-images/android-17/default
226M  system-images/android-18/default
754M  system-images/android-19/default
# New:
754M  system-images/android-20/android-wear
1.1G  system-images/android-L/default

As long as the VM image size is not an issue, I would favor the pre-installation approach.

the license identifiers change overtime

In order to avoid breaking builds, should android-update-sdk helper script accept any license by default? (or at least android-.+ pattern?)

Pro Arguments:

  • Avoid problems like #2466 in the future
  • As illustrated in the previous point above, it seems that there is no longer the risk to install more components as wanted (e.g. MIPS or Intel system images). To be confirmed...
  • It would still be possible to specify a custom list of licenses to accept via .travis.yml to be sure to avoid some unwanted components.

These points will be addressed in travis-ci/travis-cookbooks#337. Your feedbacks are more than welcome! Please report any other trouble or wish you have so far with this beta.

/cc @joshk @andrewhr @rkistner @gabrielemariotti @vovkab @danielpassos @emmby @donv @leviwilson @austynmahoney @mendhak @ruleant @barbeau @xtreme-graham-holker @bingzer @pestrada

Travis CI member

In order to hide Google breaking changes to Travis projects, I previously said that

I would favor the pre-installation approach.

but after giving a bit more thinking on the disadvantages of both approach, I changed my mind and think that having pre-installed components is more a source of confusion and is only useful to reduce download efforts. My feeling is that most projects might sooner or later introduce some components to their .travis.yml to test against latest revisions (as the Travis VM image will frequently get outdated). I doubt that after a VM upgrade, these customizations will be reverted.

So, please guys raise your hand if you don't like the idea to not preinstall any components. See also travis-ci/travis-cookbooks#337 (comment) and #2470.

Travis CI member

Can someone tell me which component is very stable ? For instance, when was android-19 (Android SDK Platform 4.4.2 Revision 3) updated for the last time ?

(Platform 4.4.2 Revision 3 is not listed in


Raises hand. The preinstall of components is what gives the biggest speedup of the test runs, is it not? We gained about 10 minutes on each test run when the Android support was added. We would really hate to loose that. ...or am I misunderstanding here?

Travis CI member

@donv thanks for responding back :) I expected you would worry about these famous 10 minutes! I hope we get more feedbacks, after you fired. Thanks again!

We are indeed searching an "optimal" tradeoff between aspects like

  • "stability" (avoid broken builds due to external changes from Google or Travis)
  • "accuracy" (build against latest revisions)
  • "speed" (avoid frustrating download time for each build).

The central problem is that android update sdk always reinstall the components, even if the component is already up to date. If android update sdk could be improved to only upgrade outdated components, pre-installing would be without any doubt the best approach. Note that I haven't taken time to search for an existing feature request about that (help appreciated).

Being currently not able to ship an updated VM at the ideal pace (see #2470 (comment)), I feel that a majority of projects will tend to specify all their component dependencies in .travis.yml to be certain to run against updated versions. Having to maintain a list of pre-installed components is an additional effort for the Travis team, which is worth only if it is used. Hence this debate... before we finish the beta phase.

Note that beside saving build time, the Travis Android builder aims at simplifying the build configuration (.travis.yml goodies). It also saves from the initial boilerplate setup (install SDK tools, configure environment variables, etc.). We also plan to integrate, so that corresponding Maven artifacts are automatically installed in the local Maven repository when SDK components are installed. There is also questions to address around emulator (management, performance, etc).

So don't get me wrong, I am looking for the "best possible", but keeping in the balance:

  • backwards compatibility concerns
  • simple and intuitive configuration (no guide needed)
  • build performance

@donv The upcoming VM image will still contain the same set of sdk components. it could be really nice to use your project(s) to run both styles in parallel, and benchmark the build time saved when relying on preinstalled components. What do you think?


Hi @gildegoma !

A million thanks for the efforts in making Android development with travis-ci better! ❤️

Adding maintenance efforts to your process is costly and should be minimised, I agree.

For Ruboto core testing and testing of Ruboto projects, the current efforts are very useful, and Ruboto tooling itself compensates for the mentioned deficiencies by updating or installing missing components.

A base installation of components updated 2-4 times a year would still make a huge positive impact. Projects using cutting edge versions of components can install these themselves using the provided tooling.

Being able to update Android SDK components and detect an up-to-date/not-up-to-date installation is part of the Ruboto tooling and a must-have for serious development of Android apps. We will improve our tooling, and we would love for our improvements to flow into the travis-ci Android support to help other non-Ruboto projects as well.

Filing issues upstream to make android update sdk do nothing when components are up to date should be done. It will solve the cause of the problem, right? I found these in the Android tracker:

Add your "stars" to make them higher priority.

Using the Ruboto project build to benchmark builds would be great! Please let me know how I can help. I have on my plan to add a "Reference Ruboto app" to travis-ci, but I cannot promise when that will happen.


I agree with most of what @donv is saying, and would like to add the following:

You (the Travis team) should be able to freely add and remove components in your images, without it significantly affecting builds. This main reason for pre-installing them should just be to speed up build times, and should not affect compatibility. Then you can freely change the components to adjust the trade-off between VM size and build time, without breaking builds.

This means that projects should either list all components that they use, or use their tool of choice to handle the installation of components for them. I can imagine that eventually every project will use some tool to manage the SDK, similar to Bundler for Ruby. Until these tools become common it is still useful to be able to specify the components in the travis.yml file.

The main difficulty here is that it will increase the build time if all listed components are installed, regardless of whether or not they were pre-installed. The simplest workaround I can think of is to "blacklist" the pre-installed components from the build-time installation script.

It feels like a big part of Travis' support for Android belong in either the official Android SDK, or some third-party tool. Unfortunately those issues in the Android SDK (like @donv mentioned) aren't receiving much attention, so until the issues are fixed / implemented we'll need it in Travis.


We really need a solution to keep SDK items pre-installed. The work to add new items to the Travis image should not be hard if we add the right tools. I would be okay pulling my own stuff for the week or so it might take the Travis team to update their image.

I also agree with @rkistner. The work with keeping the SDK and the platform images updates should be in a different tool. I will try and contact a couple of the guys on the Android Tools Team to see if we can get their input/help on this issue.

Travis CI member

We've updated the Android build environment yesterday, and I believe this issue is fixed. If you see a problem, please open a new issue. Thank you.

@BanzaiMan BanzaiMan closed this Jul 31, 2014
@gildegoma gildegoma added a commit to gildegoma/rxjava-android-example that referenced this issue Aug 2, 2014
@gildegoma gildegoma Integrate with updated Travis CI build environment
- Use android-wait-for-emulator script shipped in Travis VM image
- Require build-tools-19.0.3 component, which is no longer preinstalled
- Specify all the required SDK components even if they are present on
  the Travis VM image. See travis-ci/travis-ci#2296
- Tweak a bit .travis.yml organization
@gildegoma gildegoma added a commit to travis-ci/docs-travis-ci-com that referenced this issue Aug 2, 2014
@gildegoma gildegoma Android: recommend to specify all dependencies
This practice ensure stable build environment even if some preinstalled
components are removed from the Travis VM. Unfortunately, it will also
increase the total build time (until we find a solution to this

See discussion in travis-ci/travis-ci#2296 for full details about the
advantages and drawbacks to rely on the pre-installed components.
Travis CI member

@donv @rkistner @austynmahoney Thanks a lot for your feedbacks. I agree with what have been said above.

@BanzaiMan I agree to close this issue, as we reached to define the way we should deal with addition/removal of SDK components in the future:

Travis team should be able to freely add and remove components in VM image

Travis documentation will thus recommend to specify all SDK dependencies to ensure stable build environment. See travis-ci/docs-travis-ci-com@98b9c05 and travis-ci/docs-travis-ci-com#91.

Being warned about possible broken builds, it will still be possible to build faster by relying on preinstalled components

implement a solution that avoid to uselessly re-install components that are up to date

By fixing this problem, it will be possible to have a stable and fast environment for everyone. Any one interested to pair with me on this?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment