Release APKs and app store delivery

[Volker Krause]

On Wednesday, 28 April 2021 02:20:51 CEST Aleix Pol 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.

For the release builds signing is still missing, but that is just one small MR 
away I think: https://invent.kde.org/sysadmin/binary-factory-tooling/-/
merge_requests/173

> 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.

The existing generator already allows for manual overrides by preferring 
existing fastlane metadata in the source dir over generating it from 
appstream. That's e.g. how we get Itinerary's store header image in there, or 
KTrip's Android specific screenshots. Ultimately you can entirely replace that 
mechanism when needed, binary factory just wants fastlane metadata as part of 
the build results, how it gets there doesn't matter.

> In any case, big thumbs up, would be happy to help if there's anything
> I can help with.

You can indeed help :) Please go through the setup instructions for Google 
Play API access (https://docs.fastlane.tools/actions/supply/#setup) and send 
me the resulting key, so I can test the fastlane integration. My access rights 
aren't sufficient to do this myself.

Thank you,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-android/attachments/20210428/1acbc09a/attachment.sig>