Release APKs and app store delivery

Ben Cooksley bcooksley at kde.org
Wed Apr 28 08:09:37 BST 2021


On Wed, Apr 28, 2021 at 12:21 PM Aleix Pol <aleixpol at kde.org> wrote:

> On Sat, Apr 24, 2021 at 10:17 AM Volker Krause <vkrause at kde.org> wrote:
> >
> > Hi,
> >
> > with the Craft-based Android release package builds hopefully being
> close to
> > working, here are some thoughts on the next steps of getting those
> packages
> > into the corresponding app stores/repositories, and a few points I would
> need
> > help with.
> >
> > (1) Signing
> > This should mostly be a copy/paste job from the existing setup for the
> nightly
> > builds.
> >
> > (2) F-Droid Release Repository
> > On the Jenkins side this should also be mostly a copy/paste job, the
> nightly
> > build script for this will only need minor adjustments to be less
> aggressive
> > for expiring old packages.
> >
> > We however would need to set up a new repository for release packages,
> next to
> > the one with the nightly builds. Ideally with a long-time stable URL so
> we can
> > maybe convince the F-Droid people to include that by default as an
> external
> > source (even if that means disabled by default as per their policy, still
> > better than not being available at all). That's probably something that
> would
> > need sysadmin help.
> >
> > (3) Google Play
> > I would like to evaluate using fastlane supply (
> https://docs.fastlane.tools/
> > actions/supply/) for automatically uploading metadata and APKs to Google
> Play.
> > That doesn't necessarily imply publishing APKs blindly, but being able to
> > automatically have APKs in the staging area as well as automatically
> syncing
> > translations for the app description seems very much worth it to me. And
> given
> > that fastlane actually defined the metadata format that F-Droid is using
> I
> > have high hopes that this integrates well with what we already have.
> >
> > However, fastlane seems to be mainly distributed via Ruby's package
> manager,
> > not via regular distro packages. Is that a blocker for installing this
> on the
> > signing machine?
> >
> > For testing, I'd also need an API access key for our Google Play
> account, as
> > described in the above link. I think that's something Aleix has to set
> up, I
> > don't have permissions for that.
> >
> > This then presumably also needs a small driver script like we have for
> F-Droid
> > to upload new packages and metadata after signing.
> >
> > Makes sense?
>
> The apks we generate now are already signed and can be just uploaded
> to F-Droid repos (our nightly repo being proof) and Google Play as is.
> So it's already done, unless you want to deviate from it in any way,
> but now it should work.
>

The difference here from my understanding is that what we build now are
nightlies, being built against the 'master' branch of a project.
Volker is targeting (from my understanding) builds from the actual stable
releases (git tags / tarballs).

This is something that Craft is very well optimised for.


> Regarding the usage of fastlane, we already support their format so
> yay. I don't know though how much we can extrapolate our generation
> through appstream. We might need ad-hoc solutions in some cases.
>
> In any case, big thumbs up, would be happy to help if there's anything
> I can help with.
>
> Cheers!
> Aleix
>

Thanks,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-android/attachments/20210428/ea4b0409/attachment.htm>


More information about the KDE-Android mailing list