[Android-tools-devel] Building Jack/Jill and other Android build tools from source

Tue Dec 27 13:16:09 UTC 2016

Hans-Christoph Steiner writes:

> Wolfgang Wiedmeyer:
>> 
>> Hans-Christoph Steiner writes:
>> 
>>> Wolfgang Wiedmeyer:
>>>> Sorry for my late reply!
>>>>
>>>> Hans-Christoph Steiner writes:
>>>>
>>>>> We're interested in packaging as much of the Android tools as possible,
>>>>> we'd also be interested in the manifest-merger.  We have manifest-merger
>>>>> built as a JAR in the android-platform-tools-base package, but we
>>>>> haven't really exposed it.  You can see it listed here:
>>>>>
>>>>> https://packages.debian.org/stretch/all/android-platform-tools-base/filelist
>>>>
>>>> Awesome! Are there any plans to do a backport to Jessie?
>>>>
>>>>> If you are interested in basing your ROM builds on Debian, then we can
>>>>> shift priorities some to work on fixing issues related to ROM builds.
>>>>> We're currently focused on getting app building working with the Debian
>>>>> packages.
>>>>
>>>> I'm very interested in that and I already try to use everything that is
>>>> available in Jessie. It would be great to have all host tools either
>>>> build from source as part of Replicant or getting them from Jessie. I'm
>>>> already pretty close to that. In fact, I'm only aware of the
>>>> manifest-merger and some binaries from the NDK repo that run on the
>>>> build host and are not yet from Jessie or build from source. This is for
>>>> building a ROM image, to build the SDK a lot more is needed. I'm
>>>> focusing on the host tools for now to make the build itself more
>>>> trustworthy, but the goal is to get rid of all the prebuilts.
>>>>
>>>> Replicant needs to be buildable on a GNU FSDG-compliant
>>>> distribution. While I think it's fine that my focus is currently on
>>>> Debian, it should be possible to build it on a FSDG-compliant distro
>>>> like Trisquel in the future. A dependence on the backports repo could
>>>> make this more difficult, but I don't see an other option at the moment.
>>>>
>>>> Thanks,
>>>> Wolfgang
>>>
>>> We're still focused on getting everything working in testing.  Backport
>>> to jessie is feasible, but its a chunk of work.  How essential is it for
>>> you?  It would make the workflow a lot easier if you work on stretch,
>>> since we can then make updates and fixes in one place.
>> 
>> Stretch is not really an option right now. I'm already mirroring all the
>> repos from CyanogenMod to have everything in a "freezed" state. A
>> running target like Stretch would result in a lot of additional work to
>> keep up with the changes. Google seems to target an older Ubuntu LTS
>> release for building their native toolchain (compilers etc.). Debian
>> Stable is a much better fit for that. I already tried to help someone to
>> get everything build on Stretch until this person gave up. There were
>> quite some new build errors.
>> 
>> Maybe this is something where I could get involved? I backport a few
>> things for personal use: https://packages.fossencdi.org/
>> I could do some quick and dirty backports of needed packages and see how it works
>> out. Then, with your help and Debian Mentors, I could try to get them in
>> the official backports repos.
>
> Yeah, that would certainly help.  The painful part is the staged
> uploads, meaning that you first have to upload a partial version of
> android-platform-build and android-platform-system-core, then upload
> other things that depend on those, then upload the full versions.
> That's because of circular dependencies between the git repos/source
> packages.
>
> https://wiki.debian.org/AndroidTools#Updating_the_source_packages
>
> I propose a much easier way to use the android-tools packages from
> stretch: add testing as a package source, but pin it at very low
> priority so you have to manually install packages from that repo.   This
> is the same setup as jessie-backports.  Then you can start working with
> the stretch versions of the packages while on jessie.  I think the 7.0
> SDK packages will be easier to backport since there is only one circular
> dep: android-platform-system-core.  We're aiming to have those included
> in stretch's final release.
>
> Also, FYI, stretch will freeze in November, so it will be soon not
> changing very much.

I recently managed to fix all the build errors with Debian Stretch and
I'll use Stretch from now on to build Replicant 6.0.
The manifest-merger is already in use:
https://code.fossencdi.org/replicant_build.git/commit/?h=replicant-6.0&id=35c9421f7a5b4a3a67b0a7b76e68bf83b4bef546
https://code.fossencdi.org/replicant_build.git/commit/?h=replicant-6.0&id=6662a629cef6f9bcf7edf0885080e3857b8b49b5

Best regards,
Wolfgang

>
>>> We already have the bulk of the SDK tools packaged.  Its really just the
>>> odd things like renderscript that are not.  As for building the NDK from
>>> source, that's a whole other question.  It would probably be pretty easy
>>> to package ndk-build since its just a collection of Make scripts.  But
>>> actually building the compilers would be a large project.
>> 
>> Building the compilers works fine, but some binaries like a minimal
>> Android libc is needed. I also have to check what else is needed for
>> building a ROM, but it doesn't seem to be much.
>> 
>> Wolfgang
>
> Ok, at least its easy to build.  There are still a lot of issues related
> to the packaging and integrating with the compilers already in Debian.
>
> .hc

-- 
Website: https://fossencdi.org
OpenPGP: 0F30 D1A0 2F73 F70A 6FEE  048E 5816 A24C 1075 7FC4
Key download: https://wiedmeyer.de/keys/ww.asc
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 818 bytes
Desc: not available
URL: <http://lists.alioth.debian.org/pipermail/android-tools-devel/attachments/20161227/4fd1cd67/attachment.sig>