[Android-tools-devel] arm64 & armhf builds?

[Neil Williams]

On Fri, 25 Mar 2016 20:23:57 +0800
殷啟聰 <seamlikok at gmail.com> wrote:

> adb and fastboot are part of the Android SDK which are only officially
> supported on x86 platforms. Strictly speaking, Google only supports
> its i386 version, because the official SDK are mostly 32-bit
> softwares. Although the Android OS runs on x86, ARM and MIPS, the SDK
> does not.

"does not" or "is not supported on" ?

It's not the full SDK that is relevant necessarily. For automated
testing of AOSP development, adb and fastboot binaries are the
principle requirement.

> We don't want to maintain too many ports of them, there's too much
> work. More importantly, even if we can successfully build them on
> other platforms, we can't assure that they will work on other
> platforms.

There are established automated systems which could test exactly this
requirement. Users of such systems have expressed interest in doing
precisely this kind of testing, particularly for and on ARM
architectures. Once more suitable arm64 hardware is available (soon),
LAVA expects to be able to provide such testing but the lack of such
testing currently is not an excuse to remove the architecture just at
the point where this support could be offered.

> For example, we used to let android-libunwind build on
> other platforms but it FTBFS on MIPS. Another example, 64-bit dexdump
> won't work and we can only use its 32-bit version.

The use case for testing adb and fastboot does not have to include
dexdump. Equally, having a validation framework can assist in debugging
*why* dexdump does not work and *fixing* that bug and other bugs related
to architecture-specific flaws in the code.

> You can surely use adb and fastboot on a x86 computer to debug ARM
> phones, and I think most people do this?

This is not about debugging a single phone. This is about automated
testing of dozens of phones and other devices across a range of
infrastructure to do automated testing of AOSP builds to support kernel
development and mainline testing.

LAVA (lava-dispatcher specifically) uses adb and fastboot to deploy and
test on multiple devices. As an ARM test facility, there is a strong
interest in testing using ARM infrastructure wherever possible - that
way we can test the mobile device and the enterprise server at the same
time. If there are tests that can or need to be run to validate adb and
fastboot themselves, those can be run on the server hardware but still
within the same CI framework.

lava.debian.net is the Debian LAVA instance but this is in early stages
of device integration. validation.linaro.org is the established
instance and runs large numbers of AOSP tests on a wide range of ARM
devices.

So ports of adb and fastboot could be tested and validated on ARM
platforms, that is why ARM builds should not be dropped.

The previous builds of adb and fastboot were not tested within Debian
but using this as an excuse to remove them when an established test
system is gaining support to provide that testing does not make sense.
There is an expectation from users that LAVA will be able to use arm64
servers to run tests inside LAVA as part of a CI framework for arm64
kernel support. Hardware to do this is pending but to complete this
service, LAVA needs ARM builds of adb and fastboot. Equally, LAVA can
be used to provide the very testing that has been missing in the past.

If there are no other reasons for shortening the architecture list, at
least arm64 should be recovered. However, with devices like the
cubietruck already running lava-dispatcher services, there is no
particular reason to drop armhf either. Building those packages is not
a problem, the buildd framework is more than capable of that task.

Please retain arm64 and armhf architectures.
 
> 2016-03-25 4:58 GMT+08:00 Neil Williams <codehelp at debian.org>:
> > What is the reason for the removal of the ARM builds of adb and
> > fastboot? It seems odd to not support debug tools for ARM devices
> > from ARM devices.
> >
> > i386 is still supported, so it doesn't seem to be a 32bit issue -
> > even if it was, there should be no particular reason to drop arm64.
> >
> > Is there an upstream link or reference for why 6.0.1 cannot support
> > non-x86 architectures?
> >
> > --
> >
> >
> > Neil Williams
> > =============
> > http://www.linux.codehelp.co.uk/
> >
> >


-- 


Neil Williams
=============
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/android-tools-devel/attachments/20160326/8e8b5929/attachment.sig>