Accept all licenses about android-sdk-installer

[sebv]

This is another way to achieve what you want without resorting this kind of hack:

1/ You get the id of the package you want to install:
android list sdk -a | grep 'ARM EABI v7a System Image, Android API 18, revision 2' | cut -d '-' -f1 | tr -d " "

2/ Then use add it to the package in the android-sdk-installer script or install it with
android update sdk --no-ui -a --filter <ID>

[austynmahoney]

The current sample Travis-CI Configuration tries to ask the user to accept the license for the new Android Wear SDK.

Do you accept the license 'android-wear-sdk-license-4a8b8ed9' [y/n]: 
Unknown response ''.
Max number of retries exceeded. Rejecting 'android-wear-sdk-license-4a8b8ed9'
Package Android Wear ARM EABI v7a System Image, Android API 19, revision 1 not installed due to rejected license 'android-wear-sdk-license-4a8b8ed9'.

FIlter

export COMPONENTS=build-tools-18.1.0,android-17,sysimg-17,extra-android-support,extra-google-google_play_services,extra-google-gcm,build-tools-18.1.0,extra-google-m2repository,extra-android-m2repository

The problem is sysimg-19 now includes the Android Wear SDK, and that license is not accepted with the current code.

[rkistner]

Licenses can now be accepted by passing the licenses in the --accept option. Each license has to be explicitly specified. See https://github.com/embarkmobile/android-sdk-installer/tree/version-2#accepting-licenses for details.

Note that you have to change scripts to use the version-2 branch instead of version-1, since this now requires the expect package to be installed.

[gildegoma]

Hey guys!

FYI: I also introduced similar license strategies in android-sdk chef cookbook v0.1.0 (see gildegoma/chef-android-sdk@cdcad47). This cookbook will be used to build the upcoming Android VM on Travis CI (and it's not an April Fool!).
Note that I faced some strange installation issue with --filter component1,component2,... syntax and (temporarily) work around it with a loop over each item to be installed. Maybe I missed something, as it looks that you have no issues on your ends.

In the next days, I also plan to work on finishing .travis.yml built-in goodies that might allow to trigger extra android update sdk commands. The idea is also here to deal with licenses the easiest way for the end-user. I think that a possible approach could be to integrate/adapt embarkmobile/android-sdk-installer (a version of such helper script could be pre-installed on the Travis VM or auto-downloaded, etc.). That would also prepare the ground for next improvements like Emulator startup, etc.

If you have time and interest to help me to finalize this thing in the best possible way, just know that your advised comments/contributions are always welcome :)

[rkistner]

@gildegoma What specifically was the issue you had with that?

At the moment this repo is just designed to do the initial install, which will be rendered semi-obsolete when your Android VM work lands on Travis (on Travis at least). It would be nice to have some scripts to handle the updating properly as well, but that's a whole new problem unfortunately.

I really wish this kind of functionality would just be included in the core Android SDK, so that we don't have to rely on workarounds such as this.

The work you've done so far for Android support on Travis look good - let me know if there's anything specific you need help with.

Btw I adapted that expect script of yours to accept the licenses here - hope you don't mind :)

[gildegoma]

Btw I adapted that expect script of yours to accept the licenses here - hope you don't mind :)

Surely not!!! These are desired "side-effects" of a great community :)

It would be nice to have some scripts to handle the updating properly as well, but that's a whole new problem unfortunately

I think we can re-use some/lots from android-sdk-installer. The idea would be to coordinate it well to maintain the quality on the long run... This additional dev-toolkit (updater, emulator manager, ...) could also be part of android-sdk cookbook features.

I really wish this kind of functionality would just be included in the core Android SDK, so that we don't have to rely on workarounds such as this.

Is there already an open feature request (on which we could vote) ?

What specifically was the issue you had with that?

With Android SDK 22.6.2, running android update sdk ... --filter platform-tools,build-tools-19.0.3,android-19,sysimg-19,android-18,sysimg-18,... leads to following setup (platforms are OK, but most system-images are missing):

 55M build-tools/
146M platforms/android-10 
82M platforms/android-15 
87M platforms/android-16 
89M platforms/android-17 
99M platforms/android-18
114M platforms/android-19
754M system-images/android-19/default/armeabi-v7a
 13M extras/android/m2repository
 12M extras/android/support
 36M extras/google/google_play_services
9.1M extras/google/m2repository
----
1.7G in total

While running the loop workaround (accepting the intel/x86 license in this example):

android update sdk ... --filter platform-tools
android update sdk ... --filter build-tools-19.0.3
...
android update sdk ... --filter extra-android-m2repository

installs all components as expected:

 55M  build-tools/
146M  platforms/android-10
 82M  platforms/android-15
 87M  platforms/android-16
 89M  platforms/android-17
 99M  platforms/android-18
114M  platforms/android-19
172M  system-images/android-15/default/armeabi-v7a
222M  system-images/android-15/default/x86
203M  system-images/android-16/default/armeabi-v7a
262M  system-images/android-16/default/x86
210M  system-images/android-17/default/armeabi-v7a
281M  system-images/android-17/default/x86
226M  system-images/android-18/default/armeabi-v7a
306M  system-images/android-18/default/x86
754M  system-images/android-19/default/armeabi-v7a
756M  system-images/android-19/default/x86
 13M  extras/android/m2repository
 12M  extras/android/support
 36M  extras/google/google_play_services
9.1M  extras/google/m2repository
----
4.2G  in total

I haven't tested yet with android-sdk-installer (please, let me know if you do this check)

[gildegoma]

At the moment this repo is just designed to do the initial install, which will be rendered semi-obsolete when your Android VM work lands on Travis (on Travis at least).

android-sdk-installer will still be necessary for Travis builds on the Mac OS X platform, as the Android worker will be Linux-based (to begin).

[gVien]

I know this is closed but I have a question related to the way Android is installed. As @gildegoma mentioned that updating the SDK with android update sdk ... would install the packages inside either build-tools, platforms, extras, samples, and system-images directories inside $ANDROID_HOME, but does it update any other configuration files inside the tools directory or other directories?

I'm automating the installation of Android SDK with Puppet but plan to package all the platforms/android-XX directories after updating the SDK into RPM format and then combine them with other Android packages (extras, system-images, etc) during the installation. However, I wasn't sure if doing this would break anything, considering I'm not so sure if updating the SDK would update any configuration files inside $ANDROID_HOME.

 55M  build-tools/
146M  platforms/android-10
 82M  platforms/android-15
...
210M  system-images/android-17/default/armeabi-v7a
281M  system-images/android-17/default/x86
...
 13M  extras/android/m2repository
 12M  extras/android/support
...
----
4.2G  in total