We are only talking about official packages. I think some of the
confusion stems from there being an "android-tools" team which manages
many packages and an "android-tools" source package, which is the old
deprecated approach for building adb, fastboot, and fsutils.
I didn't realize that the andr
On Mon, 28 Mar 2016 10:19:45 +0200
Hans-Christoph Steiner wrote:
> Hey Neil,
>
> Sounds like you are in the perfect position to do this porting and
> maintenance since you are working with lots of ARM hardware, and want
> to use the Android SDK on ARM as part of your regular work.
No, not the p
Hey Neil,
Sounds like you are in the perfect position to do this porting and
maintenance since you are working with lots of ARM hardware, and want to
use the Android SDK on ARM as part of your regular work. So I think the
best workflow here is if you start building the android-tools packages
on A
On Sun, 27 Mar 2016 00:36:37 +0800
殷啟聰 wrote:
> So, looks like the LAVA team does need adb & fastboot on all ARM
> platforms, right? :)
It would be useful and IMHO that is sufficient reason to keep arm64 and
probably armhf in the architecture list of the source package. The need
isn't immediate
So, looks like the LAVA team does need adb & fastboot on all ARM
platforms, right? :)
I was wrong about android-libunwind. Actually I remember it was
android-libbacktrace, which is needed by adb, who FTBFS in the other
platforms. What if android-libbacktrace still FTBFS on ARM? In that
case, adb w
X-Debbugs-CC: android-tools-de...@lists.alioth.debian.org
X-Debbugs-CC: codeh...@debian.org
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
softwa
6 matches
Mail list logo
