[Android-tools-devel] what needs doing for stretch?

Chirayu Desai chirayudesai1 at gmail.com
Wed Feb 8 16:05:34 UTC 2017


Re: building support library

I saw https://plus.google.com/+IanLake/posts/Z4nusZ7sjRW yesterday, seems
that might make it easier to do it, haven't looked at the actual thing yet
though (travelling)

On Wed, Feb 8, 2017, 13:24 Hans-Christoph Steiner <hans at at.or.at> wrote:

>
> F-Droid's buildserver can use packages from backports already.
>
> As for the Support Library, I'm thinking now that Debian is not really
> the place for those libraries.  They are Java libraries that will only
> ever be used on Android.  They do need to be present on the Debian
> system to build apps.  I do think it is important to have free software
> builds of the Android Support Libraries, that should happen as part of
> F-Droid or perhaps even its own project that generates its own maven
> repo.  "android-platform-23" is required for things like apktool to run
> on Debian, so that makes sense to include.
>
> We could do that on gitlab.com, for example, with gitlab-ci running the
> build and publishing to a maven repo that works on gitlab pages.
>
> Any ideas how hard it would be to build the support libraries?
> Hopefully they are straightforward, they are after all just plain Java.
>
> .hc
>
> 殷啟聰:
> > Seems that a newer API platform isn't going into Stretch, now that it
> > entered full freeze. But we can still backport it to Stretch as well
> > as other future packages. Does F-Droid's official build server uses
> > backport?
> >
> > In order to build apps we still need to package the Support Library.
> > And I remember that in order to use the latest Support Library, the
> > app must be compiled against the latest API platform, which means we
> > still need to package the latest API platform. I don't feel like
> > maintaining multiple versions of the Support Library. In that case,
> > does that mean we eventually only need to maintain the latest API
> > platform? Since the older platforms are not used in the compilation.
> >
> > 2016-12-21 2:34 GMT+08:00 Chirayu Desai <chirayudesai1 at gmail.com>:
> >> Hi,
> >>
> >>
> >> On 12/20/2016 01:08 AM, Hans-Christoph Steiner wrote:
> >>> So we're looking good for getting 7.0.0 into stretch!  The
> >>> build/platform tools are pretty complete, and the LAVA group (Neil
> >>> Williams, etc) are already using our adb/fastboot instead of the old
> >>> android-tools package.  In January, we can deal with removing
> >>> src:android-tools and migrating users from android-tools-* to our
> >>> packages by filing RC bugs.  This will only be changing the packaging,
> >>> so I think its appropriate to do after the freeze, given limited time
> >>> before the freeze.
> >>>
> >>> I would really love to see android-platform-tools-base v2.2.x and
> >>> android-framework-24 in stretch.  I should be able to find some time to
> >>> help, but I've never worked on those packages.  Any tips?  Will they be
> >>> a lot of work?
> >> I can't comment on android-platform-tools-base.
> >> However, for android-framework-24, the current android-framework-23
> >> should make it easy in theory, and one should be able to keep the
> >> makefiles from that and add / remove files which were added / removed in
> >> API 24.
> >>
> >> d/build.gradle has some whitelisted/blacklisted files which would need
> >> to be updated
> >> d/aidl.mk contains the list of aidl files actually included in the
> >> android system build, and not all aidl files under frameworks/base. List
> >> can be copied from frameworks/base/Android.mk
> >>
> >> Now I haven't really looked at the framework part of the Android 24
> >> source code in detail to know if they moved things around repos, or how
> >> would the switch to openjdk (mainly in libcore) would affect us.
> >>
> >>
> >> And one more thing, having API 24 should make creating a API 25 package
> >> easier as well, as there aren't as many changes from 24->25, compared to
> >> 23->24 (or any other major Android version).
> >>>
> >>> With that in place, I can build the first official app release using
> >>> only Debian packages: the F-Droid Privileged Extension. Its a perfect
> >>> example for building our Debian packages since it is a very
> >>> security-sensitive app:
> >>> https://gitlab.com/fdroid/privileged-extension/
> >>>
> >>> .hc
> >>>
> >>> _______________________________________________
> >>> Android-tools-devel mailing list
> >>> Android-tools-devel at lists.alioth.debian.org
> >>>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel
> >>
> >>
> >> _______________________________________________
> >> Android-tools-devel mailing list
> >> Android-tools-devel at lists.alioth.debian.org
> >>
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel
> >
> > _______________________________________________
> > Android-tools-devel mailing list
> > Android-tools-devel at lists.alioth.debian.org
> >
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel
> >
>
> _______________________________________________
> Android-tools-devel mailing list
> Android-tools-devel at lists.alioth.debian.org
> http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/android-tools-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.alioth.debian.org/pipermail/android-tools-devel/attachments/20170208/7235b443/attachment-0001.html>


More information about the Android-tools-devel mailing list