Contents
This page is a gathering place for information about the android-tools packaging team, which is focused on packaging the Android development tools for Debian. There are also some packages which help run Debian in a chroot on Android. The goal of this team is to get as much of the Android SDK and development tools into Debian as possible. There are many advantages to having the SDK and tools in Debian, rather than relying only on the Google distributions:
- easy install and update channel that all Debian users already know
- automatic trustworthy downloads, no need to verify hash sums
- eliminate need for insecure wrapper scripts, like ./gradlew
trivial install for specific tools, like adb, fastboot, etc.
To read more about the rationale behind this work, see this blog post: https://guardianproject.info/2015/04/30/getting-android-tools-into-debian/
To communicate with this team, join our low traffic mailing list, android-tools-devel@lists.alioth.debian.org and on the IRC channel #debian-mobile (webchat).
Package naming scheme
The naming scheme for android-tools packages is as follows:
source package names are named after the git repository, prefixed by android- (e.g. android-platform-system-core, android-platform-system-extras, android-platform-build, android-platform-frameworks-base, etc.)
binary packages of utilities that run on Debian directly are named after the utility itself (e.g. zipalign, aapt, etc.)
shared libraries that are only used by android-tools packages are named after the library, without a ABI version number in the package name, and prefixed by android-. (e.g. android-libhost, android-libcutils-dev, etc. In the Google builds, these are built as static libraries, and linked statically into each binary. In the Debian builds, they are built as shared libraries and installed into /usr/lib/android.
Source package structure
The structure of each source package is documented in the README.source of each source package for this team:
http://anonscm.debian.org/cgit/android-tools/android-permissions.git/tree/debian/README.source
http://anonscm.debian.org/cgit/android-tools/android-platform-build.git/tree/debian/README.source
http://anonscm.debian.org/cgit/android-tools/androidsdk-tool.git/tree/debian/README.source
http://anonscm.debian.org/cgit/android-tools/android-tools.git/tree/debian/README.source
Upstream repository of tools in Android SDK
Tools in Android SDK come from various repositories. Here is a list of tools consisting the entire Android SDK, with each tool followed with the corresponding upstream repository name.
SDK Tools
- Android Device Monitor
ddms: platform/tools/swt
hierarchyviewer: platform/tools/swt
- monitor (Depends on hprof-conv, systrace.py, logcat)
traceview: platform/tools/swt
- android (Including SDK Mannager, AVD Manager)
draw9patch: platform/tools/base
emulator: platform/sdk
jobb: platform/tools/base
lint: platform/tools/base
mksdcard: platform/sdk
monkeyrunner: platform/tools/swt
proguard: http://proguard.sourceforge.net/ (Already in Debian)
screenshot2: platform/tools/base
uiautomatorviewer: platform/tools/swt
SDK Platform-tools
adb: platform/system/core
dmtracedump: platform/dalvik
etc1tool: platform/development
fastboot: platform/system/core
hprof-conv: platform/dalvik
systrace.py external/chromium-trace
SDK Build-tools
aapt: platform/frameworks/base
aidl: platform/frameworks/base
bcc_compat: platform/frameworks/compile/libbcc
dexdump: platform/dalvik
dx: platform/dalvik
jack: toolchain/jack
jill: toolchain/jill
llvm-rs-cc: frameworks/compile/slang
mainDexClasses: platform/dalvik
split-select: platform/frameworks/base
zipalign: platform/build
Other Tools
- Android Plugin for Gradle: Not sure
repo: tools/repo
Android's upstream version names
There are many naming schemes for versions in Android, and none are used everywhere. For the Android OS itself, there are three schemes: version names, like Gingerbread or Kitkat; version numbers, like 2.3.7 or 4.4.2; and, "API level" numbers, like android-10 or android-19. None of these line up with each other. For example, the Jelly Bean name spans 4.1 through 4.3.1 and android-16 through android-18. The version numbers and API level also do not line up, with android-14 covering 4.0.1 - 4.0.2, android-15 covering 4.0.3 - 4.0.4, but android-16 covers all of 4.1.x.
The madness doesn't end there. Next up we have SDK version numbers, which are like 20, or 23.0.2. Part of the SDK includes the build-tools package, which has its own version numbers, which are like 18.1.1 and 20.0.0, but these do not line up with the SDK version numbers. The platform-tools seems to have its own versioning scheme also, but it is not really exposed. Then there are the NDK release numbers, which are like r8b or r10, and they also do not line up with anything else.
In the git repo, there are a mishmash of tags and branches that do not represent all of these various versions. There does seem to be consistent tagging of the OS releases, you can see those listed under Source Code Tags and Builds. There are a few branches that seem to line up to the SDK version numbers, like tools_r21 and tools_r22.2, but there is not a complete set of those branches.
example versions
Android SDK Tools seems to have it's own versioning scheme, since the major version is ahead of the SDK major version:
- v24.2.0
- v24.1.0
- v23.0.0
Android SDK Build-tools seems to follow the SDK major version, but have its own minor and micro versions:
- v22.0.1
- v21.1.2
- v21.0.0
Android SDK Platform-tools seems to follow the SDK major version only.
- v22
- v21
- v20
You can find the official Google package names and versions in the index XML files that the android tool downloads when doing updates:
https://dl.google.com/android/repository/sys-img/android/sys-img.xml
https://dl.google.com/android/repository/sys-img/x86/addon-x86.xml
Android SDK version declarations
However, the exact version number of Android SDK toolsets can be found in a source.properties under each directories. Here are the source locations of each version declaration:
SDK Tools: https://android.googlesource.com/platform/sdk/+/master/files/tools_source.properties
SDK Platform-tools: https://android.googlesource.com/platform/development/+/master/sdk/plat_tools_source.prop_template
SDK Build-tools: https://android.googlesource.com/platform/development/+/master/sdk/build_tools_source.prop_template
Which matches the official release notes.
Note that according to the source code the major version number of Platform-tools and Build-tools is simply the API Level, which is defined here. But for SDK Tools it follows its own version pattern and does not relate to the API Level.
Some tools tracks their own version and do not follow the SDK version:
- adb
- dx
Why is this so complicated?
Packaging all of these Android SDK Tools is so complicated because the source code is organized into semi-arbitrary "projects" that are split up between many different git repos. Those git repos are then all checked out at the same time using Google's crazy repo tool. Then the entire Android OS and SDK are built using a single, unified build system that requires something like 8 gigs of source code be downloaded.
Needs doing
There is lots left to do before someone can do Android development using only official Debian packages. The best way to get started is to join the email list and ask there. We're also in IRC at #debian-mobile. Here are some general topics that need work:
figure out packaging scheme for various android "platforms", i.e. /opt/android-sdk/platforms/android-* and /opt/android-ndk/platforms/android-*
figure out how to represent Android NDK gcc and clang "toolchains" in Debian, i.e. /opt/android-sdk/toolchains
- build "android support" jars
- help Google integrate Android's QEMU into upstream (since Google has started to do this, I think this is the best approach to getting the Android emulator into Debian)
fdroidserver
fdroidserver is the tool suite for managing FDroid app repos and making release builds. It uses the Android SDK and NDK to make the builds and work with APKs. There are three notable milestones for fdroidserver packaging needs:
- everything to create and manage app repos
- everything to make pure Java builds
- everything to make native builds
The first milestone will be done once the aapt package is accepted into Debian. It is part of the android-platform-frameworks-base package that is waiting in the NEW queue.
low-hanging fruit
Here are a couple of easy tasks to do that will further this effort along:
get answer from Google on how the SDK versions are marked in the source git repos (i.e. what tag/branch is SDK v23.0.2? And what tag/branch is build-tools v20.0.0?)
Is https://source.android.com/source/code-lines.html#terms-and-caveats any helpful? Among other things, it says:
A release corresponds to a formal version of the Android platform, such as 1.5, 2.1, and so on. Generally speaking, a release of the platform corresponds to the version in the SdkVersion field of AndroidManifest.xml files and defined within frameworks/base/api in the source tree.
seems to vaguely contribute to understanding, but no concrete answers for which commit ID to build for SDK release v23.0.2. -- HansChristophSteiner 2014-10-07 19:51:57
android-platform-system-extras package, replacing android-tools-fsutils package.
build adb as part of android-platform-system-core package, replacing the android-tools-adb package.
build fastboot as part of android-platform-system-core package, replacing the android-tools-fastboot package.
- update all source packages to the latest SDK release (v23.0.2, provided you can find the right tag or branch)
See Also
Arch Linux packages up the Google binary packages https://wiki.archlinux.org/index.php/Android