[Android-tools-devel] Fwd: google-android-platform-* packages WAS: android-platform-libcore/6.0.1+r16-1

Tue Jul 19 22:04:45 UTC 2016

Here is a start for the package android-google-platform-installers[1] which
generate installers for platform 24, 23 and 22 (I think it's easy to add
older platforms). I will try to improve this even more following the
suggestions and discussions we had.

[1]: https://github.com/Aallam/debian_google-android-platform-installers

*Mouaad Aallam*

On Tue, Jul 19, 2016 at 9:59 PM, Hans-Christoph Steiner <hans at at.or.at>
wrote:

>
> I think making the source package use a python or perl script to parse
> the Google repo XML makes sense.  Then we can just build the source
> package, and it would generate all of the latest binary packages needed.
>
> I'll let Mouadd take the lead on this one since he's been doing the work
> on it so far.
>
> .hc
>
> Chirayu Desai:
> > On Mon, Jul 18, 2016 at 8:40 PM, Hans-Christoph Steiner <hans at at.or.at>
> wrote:
> >>
> >> I thought about enabling `android update sdk` in the Debian package's
> >> version of `android`, but now I'm thinking that it would be better to do
> >> it all with Debian packages.  I think a primary use case of the Debian
> >> packages will be to set up a system to build Android apps in an
> >> automated way (e.g. via Chef, Puppet, Ansible, CI script, etc).  It'll
> >> be a lot easier to do that if all of the components of the SDK can be
> >> directly `apt-get install`ed.  `android update sdk` is a really crappy
> >> package manager, and I've spent quite a bit of time fighting with it
> >> when automating things like CI builds.
> > I would agree here. It shouldn't take long for us to add the newer
> > versions to the contrib packages (for future releases)
> >>
> >> I think it could make a lot of sense to have a single
> >> google-android-platform-installer source package that then makes
> >> multiple google-android-platform-*-installer binary pacakges for each
> >> platform number.  It might even make sense to have a single source
> >> package for all of these installer binary packages.  The source package
> >> would just contain basically a template, then the build process would
> >> generate lots of binary packages based on replacing things in the
> >> template using a list of values for all of the Google binary packages
> >> that we want to support, e.g.
> >>
> >> * docs
> >> * platform-*
> >> * sys_img-*
> >> * build-tools-*
> >
> > I'm working on creating the google-android-platform-installer package
> right now.
> > Experimenting reading up a bit on how to best use templates, and
> > things like deb-substvars.
> > A single source package for all the google binary packages could work
> > too. Maybe we could even have something which parses the repository
> > xml, and creates packages for things we want. Not sure if we want to
> > do XML parsing though. If we do though, I have some past experience
> > with python which could be helpful.
> >
> > I can continue with the platform-installer package, or get started
> > with a generic google binary downloader, whatever suits us the best.
> >
> >>
> >> .hc
> >>
> >> Chirayu Desai:
> >>> Hi,
> >>>
> >>> This idea sounds good, and should make us able to have an android app
> >>> building shortly.
> >>> The "proper" SDK could come later, lots of work to do there still.
> >>>
> >>> There's one thing which has discussed at DebConf (informal
> >>> conversation at some random place) - what we could do is use the
> >>> components we have building and working currently right now, and then
> >>> grab the rest from google / use contrib packages. However, it might be
> >>> tricky to combine files from multiple packages, I hadn't really
> >>> thought about that before. Still putting this thought here, if it
> >>> turns out to be helpful.
> >>>
> >>> One more thing, do we want to have some sort of integration with the
> >>> SDK Manager ('android' command) and debian packages? I.e., user can
> >>> pick SDK platform 23 and get the platform package Mouaad created
> >>> installed. If he picks emulator, he can get the emulator images
> >>> downloaded directly from Google if they're not in a debian package. It
> >>> would involve some code changes though, but I'm not sure exactly how
> >>> much work would that be, and if it would be worth it to do that right
> >>> now for the installer packages.
> >>> It could still be useful later though, when we have platform packages
> >>> built from source.
> >>> And either way, part of this was discussed earlier as well, where the
> >>> user should still be able to install his own packages / add custom
> >>> stuff / install the missing packages from Google easily in a way that
> >>> works with the existing debian packages.
> >>>
> >>> I'm just getting back to work after the DebConf trip, lots of catching
> >>> up to do - I did read all of the e-mails when there, just didn't get a
> >>> chance to send a proper reply until today.
> >>>
> >>> Regards,
> >>> Chirayu Desai
> >>>
> >>> On Tue, Jul 12, 2016 at 11:15 PM, Mouaad Aallam <mouaad at aallam.com>
> wrote:
> >>>> A start package for Google Android SDK Platform 24[1]
> >>>>
> >>>> [1]:
> https://github.com/Aallam/debian_google-android-platform-24-installer
> >>>>
> >>>> Mouaad Aallam
> >>>>
> >>>> On Mon, Jul 11, 2016 at 4:29 PM, Mouaad Aallam <mouaad at aallam.com>
> wrote:
> >>>>>>
> >>>>>> This approach would make the packaging simpler, but I think we would
> >>>>>> provide a much better experience to users who are installing the
> >>>>>> platforms if there was one Debian package per platform package.
> That's
> >>>>>> how the platforms are represented using the `android list sdk`
> command
> >>>>>> line tool, and the `android` GUI package installer.  That's what
> Android
> >>>>>> devs are used to.
> >>>>>>
> >>>>>> I think it also provides a more Debian-ish experience, I need X so
> I do
> >>>>>> `apt-get install X`.
> >>>>>
> >>>>>
> >>>>> Alright then, that was just an idea I had :D, let's do it the way
> you just
> >>>>> discribed then.
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> 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
> >
>
> _______________________________________________
> 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/20160719/06d18abb/attachment-0001.html>