Android emulators are broken on trusty env update because avdmanager is not on PATH

[ZacSweers]

Started happening recently and noticed it on a couple of different android repos

uber/AutoDispose#71
JakeWharton/RxBinding#404

Error is basically Error: Target id is not valid. Use 'android list targets' to get the target ids.

[isnifer]

Confirm tipsi/tipsi-stripe
All builds from the 1st of September are broken. I don't change any config.

[BanzaiMan]

What target ids are problematic?

[iriberri]

Hi @hzsweers and @isnifer, thanks for reporting this issue and sorry for the troubles.

First of all, and while we help you sort out this issue or any other related to the migration to the Android image in Trusty, you can specify dist: precise to keep your builds running in the Precise image in which they were working before.

Now, let's get to some details on the new Android image (see #5370), which was released recently.

In this update, the android tool has been deprecated in favor of sdkmanager and avdmanager.

Getting back to the specific error you're seeing, the old Android image in Precise came with the following targets preinstalled:

id: 1 or "android-10"
id: 2 or "android-15"
id: 3 or "android-16"
id: 4 or "android-17"
id: 5 or "android-18"
id: 6 or "android-19"
id: 7 or "android-20"
id: 8 or "android-21"

however, the Trusty image comes only with android-25, and other targets (such as android-21 or android-18) need to be explicitly requested in the android.components section, as well as the specific ABIs needed.

For example, I made some tests on a fork of the tipsi/tipsi-stripe repository, and the build seems to be going through this step after adding the following components:

- android-21
- sys-img-armeabi-v7a-android-21

Could you please give this a try and let us know how it goes?

Thank you!

[ZacSweers]

Mind taking a look at uber/AutoDispose#79 and letting me know if you spot anything obviously wrong? I've been trying to get this working but without avail (see the recent commits on the PR for various attempts)

[ZacSweers]

So it seems the crux of the issue is that the avdmanager binary is not getting installed, and subsequently any UI tests requiring an emulator won't work

[ZacSweers]

I've renamed this to be more accurate. Hope travis-ci can look into it soon as it seems to block any project using emulators :/

[isnifer]

@iriberri my problem is solved, thank you)

[BanzaiMan]

@hzsweers How about you? Is @iriberri's suggestions helpful for you?

[ZacSweers]

Unfortunately not, if you look at my linked PR you'll see that was one of the things I tried in my iterations

[BanzaiMan]

It is not hard to get avdmanager on $PATH using the tools at your disposal; specifically, by using sdkmanager.

As I mentioned in #8155 (comment), we should eventually move to sdkmanager to manage installed components. I have a primitive working example, but it is not anywhere close to production use. I'll have to work on this a little bit before presenting as a possible replacement going forward.

So, what does that leave you now?

If you need avdmanager NOW and @iriberri's suggestion does not work, you can try the following:

env:
  global:
    - ANDROID_SDK_ROOT=/opt/android  # any place `travis` can write to should work
before_install:
  - mkdir -p $ANDROID_SDK_ROOT
  # tailor the following list to your needs; `yes` below means accepting licenses.
  - yes | sdkmanager --sdk_root=$ANDROID_SDK_ROOT "tools" "build-tools;26.0.1" "extras;android;m2repository"
  - export PATH=${ANDROID_SDK_ROOT}/tools/bin:$PATH

avdmanager would be in ${ANDROID_SDK_ROOT}/tools/bin.

[isnifer]

@hzsweers hey, also you can create new installation config based on our tipsi-stripe config. Look into .travis folder and .travis.yml of course

[ZacSweers]

That didn't work for me either. What did work for me was to actually install the tools manually, as in JakeWharton/butterknife#1055

Does travis maintain updated example projects and docs when updating images?

[stale]

Thanks for contributing to this issue. As it has been 90 days since the last activity, we are automatically closing the issue. This is often because the request was already solved in some way and it just wasn't updated or it's no longer applicable. If that's not the case, please do feel free to either reopen this issue or open a new one. We'll gladly take a look again! You can read more here: https://blog.travis-ci.com/2018-03-09-closing-old-issues