[Android-tools-devel] Android Gradle Plugin

[Hans-Christoph Steiner]

Yet another painful part of packaging the Android SDK is all the version
craziness.  For something like the gradle plugin itself, it uses the
studio-1.5 tags, but I think some of the related components will use the
SDK 24.5.0.  For things that have a visible public version, we should
use that version.  Somethings do not, like adb and fastboot, we just
used the source tag version.

.hc

殷啟聰:
> Hi Markus and Hans,
> 
> Although I hope that all AOSP packages should follow the same versioning scheme
> since they have different versions everywhere and they do not version so many
> components, turns out that platform/tools/buildSrc doesn't have tags like
> "android-6.0.0_r26", which makes things tricky.
> 
> So I propose that all AOSP packages in platform/tools/* follow the versioning
> scheme of "studio-1.5" or "gradle-1.3.1", as they exist in all platform/tools/*
> repositories. But should we follow "studio-*" or "gradle-*"?
> 
> AFAIK, "studio-1.5" means Android Studios 1.5, while "gradle-1.3.1" means Gradle
> Plugin 1.3.1. But as I have observed, "project.ext.buildVersion" in
> "base/version.gradle", which is used as the version of both projects, is exactly
> the version number. So I guess the Gradle Plugin and Android Studios share the
> same version. Markus, have you got any confirmation on this?
> 
> If they really share the same version, we can simply checkout the latest tags
> like "{gradle,studio}-*" when getting a new upstream release.
> 
> Cheers,
> Kai-Chung Yan
> 
> 2016-02-09 4:43 GMT+08:00 Hans-Christoph Steiner <hans at at.or.at>:
>>
>>
>> Markus Koschany:
>>> Hi,
>>>
>>> I'm subscribed to android-tools-devel.
>>>
>>> Am 08.02.2016 um 14:22 schrieb 殷啟聰:
>>>> Hi Markus,
>>>>
>>>> Thank you for the effort on the Java part of Android SDK!
>>>>
>>>> I would insist that the package should follow the naming and
>>>> versioning conventions of the existing AOSP packages by Android-Tools
>>>> team. For this source package, the name should be
>>>> "android-platform-tools-base" and the version should be something like
>>>> "6.0.0+r26-1".
>>>
>>> Ok, I will rename the source package to android-platform-tools-base. I'm
>>> not so sure with the versioning. I have checked out the studio-1.5 tag.
>>> The build system uses
>>>
>>> rootProject.ext.buildVersion = 1.5.0 (Android Studio version)
>>> rootProject.ext.baseVersion = 24.5.0 (=> API)
>>>
>>> The 6.0.0+r26-1 numbers seems to be more like an internal versioning
>>> scheme. In my opinion we should either use the Android Studio release
>>> numbers or the API version which would be in line with the official
>>> releases from:
>>>
>>> https://developer.android.com/sdk/index.html#Other
>>>
>>> or the developers guide from
>>>
>>> https://sites.google.com/a/android.com/tools/build
>>>
>>> I would go with 1.5.0 in this case.
>>
>> The versions/tags in the Android sources are painful.  There are many
>> different ones, and its not clearly documented.  I think you are correct
>> that the studio-1.5 tag is the one used for the core gradle plugin
>> stuff.  The open question is whether that studio-1.5 tag is available in
>> all of the git repos related to these packages.  That's why we ended up
>> going with the Android OS version tag (e.g. 6.0.0_r26): because it is in
>> all of the git repos, and it lines up to the various releases.
>>
>> In case you haven't seen it, this is worth a quick read, or please add
>> anything you think should be there:
>> https://wiki.debian.org/AndroidTools#Android.27s_upstream_version_names
>>
>>
>>>> We have a simple and unified way to fetch the upstream tarball. Please
>>>> check out one of our packages, e.g. src:android-platform-libcore [1].
>>>
>>> Thanks.
>>>
>>>>
>>>> AFAIK this repository needs a buildSrc from [2] to build. Did you also
>>>> include this part into the upstream tarball? For now we have been
>>>> making one package for exactly one repository instead of merging
>>>> multiple repositories. Hence if I were you I would make another source
>>>> package called "android-platfrom-tools-buildsrc" which produces
>>>> "android-platform-tools-buildsrc-source" containing the Java codes or
>>>> "libandroid-tools-buildsrc-java" containing the "buildSrc.jar".
>>>
>>> I didn't need to package this repository but thanks for pointing it out
>>> to me. In fact I only need build.gradle and settings.gradle from this
>>> repo. I could create src:android-platform-tools-buildsrc and install the
>>> gradle build files for instance into
>>> /usr/share/android/android-platform-tools-buildsrc. I would still need
>>> to copy these files into the build tree because they need some patches.
>>>
>>>>
>>>> And I am also wondering where are you going to maintain this package?
>>>> pkg-java or Android-Tools team?
>>>
>>> I think it makes sense to maintain all android-* packages as part of the
>>> android-tools team and all generic packages like intellij-annotations,
>>> that are useful across different packaging teams, in pkg-java.
>>
>> Sounds good to me.
>>
>> .hc
>>
>> _______________________________________________
>> Android-tools-devel mailing list
>> Android-tools-devel at lists.alioth.debian.org
>> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel
> 
> 
>