FS#63200 - [android-tools] switch to the proper official versioning scheme for adb and fastboot
Attached to Project:
Community Packages
Opened by Daniel Micay (thestinger) - Monday, 15 July 2019, 11:46 GMT
Last edited by Anatol Pomozov (anatolik) - Thursday, 18 July 2019, 23:50 GMT
Opened by Daniel Micay (thestinger) - Monday, 15 July 2019, 11:46 GMT
Last edited by Anatol Pomozov (anatolik) - Thursday, 18 July 2019, 23:50 GMT
|
Details
The package currently sets the version to the Android Open
Source Project tag where these are retrieved. This doesn't
match the official versioning scheme which is based on the
API level. This breaks version detection based on the
standard versioning scheme and makes it confusing to discuss
the version. Arch seems to have gotten this from Debian,
which also does this incorrectly.
For example, here's the current stable release: % adb version Android Debug Bridge version 1.0.41 Version 29.0.1-5644136 Installed as /home/strcat/sdk/platform-tools/adb % fastboot --version fastboot version 29.0.1-5644136 Installed as /home/strcat/sdk/platform-tools/fastboot Here's the actual version within the latest Android Pie stable tags: % adb version Android Debug Bridge version 1.0.40 Version 28.0.0 rc1-2019.07.14.18 Installed as /home/strcat/android/pie/out/host/linux-x86/bin/adb % fastboot --version fastboot version 28.0.0 rc1-2019.07.14.18 Installed as /home/strcat/android/pie/out/host/linux-x86/bin/fastboot The portion of the version that's set to 5644136 for the official releases and 2019.07.14.18 for my build in the AOSP source tree is the value of $BUILD_NUMBER, which doesn't really have a standard value. That's where you should put a custom version, i.e. "28.0.0 rc1-$CUSTOM". You can see the setup for this in system/core/platform_tools_tool_version.mk: platform_tools_version := $(shell sed \ 's/$${PLATFORM_SDK_VERSION}/0/ ; s/^Pkg.Revision=\(.*\)/\1/p ; d' \ development/sdk/plat_tools_source.prop_template \ ) tool_version := $(platform_tools_version)-$(BUILD_NUMBER_FROM_FILE) This is the content of development/sdk/plat_tools_source.prop_template in the tag that's being used: Pkg.UserSrc=false #Pkg.Revision=${PLATFORM_SDK_VERSION}.0.0 Pkg.Revision=28.0.0 rc1 Separately from this, it would be best to figure out where to get the Git revisions for the stable releases of the SDK and switch to the current releases of platform-tools, etc. instead of the older version currently being shipped. You can see that the current stable release as part of the SDK is based on a very recent master branch: https://android.googlesource.com/platform/development/+log/master/sdk/plat_tools_source.prop_template I don't know how to convert the 5644136 build number into the Git revisions for the actual release though. I'm looking into that. Using the older sources tied to stable releases of AOSP is are fine for working with that version of AOSP but not developer previews, etc. and it can be missing useful features. |
This task depends upon
Closed by Anatol Pomozov (anatolik)
Thursday, 18 July 2019, 23:50 GMT
Reason for closing: Fixed
Additional comments about closing: fixed in SVN revision 491955
Thursday, 18 July 2019, 23:50 GMT
Reason for closing: Fixed
Additional comments about closing: fixed in SVN revision 491955
What would be the best Arch's value for BUILD_NUMBER?
I've also confirmed that the platform-tools-29.0.1 tag is now available and working after I talked to https://twitter.com/jmgao so you can use that to build the most recent stable release of platform-tools (adb, fastboot, e2fsdroid, mke2fs). The other tools (avbtool, ext2simg) don't have canonical releases as far as I know but I think building from the platform-tools tag is a better choice than the stable Android release, because either way is essentially an arbitrary snapshot and platform-tools-29.0.1 is much newer. For example, avbtool from that tag has calculate_vbmeta_digest and calculate_kernel_cmdline. An example of a use case for calculate_vbmeta_digest is that people can compare it against the values reported by my Auditor / AttestationServer projects (https://attestation.app/about) via the hardware-based attestation so it would be nice to have that available via the official Arch repositories.