[Feature] Build and publish Android Debug apk from GitHub Actions

[francisduvivier]

Hi, just first want to say thanks a lot for this project, it really helps me for getting into hobby robotics, AI, 3D printing, electronics and Arduino.
I was looking at the build pipelines for Android and I see that currently, the android app is not being built(since android/gradlew is executed from the root of the repo, which has no gradle project) or uploaded.

I've worked with Bitbucket pipelines and I would love to contribute and get some experience with GitHub's build pipelines, so I would like to improve this in 2 PR's:

1. Add a build step to build the app module, I'm thinking of using https://github.com/marketplace/actions/android-build for that, but I still have to experiment with that a little. With this, we can already ensure that on every PR, the app build is still working.

2. Upload the debug apk to the build artifacts. I was thinking to follow this guide for that, but here also I still have to experiment a little first. With this, people could download this apk to their device so that they would not necessarily need to install android studio. They would still have to change settings on their phone to allow the installation though so this PR should also include some documentation with a (or link to) explanation about installing a debug apk on your android phone.

A nice third step would be to instead upload a signed apk, but this requires to store the signing keys somewhere safe, so I won't be able to set that up as an external contributor.
And from there, you could also include an automatic deployment to the F-Droid repo or google play store. But also, since it requires signing keys and authorization, it's out of scope for an external contributor I would think.

Let me know if you guys think the above 2 PR's would be useful. The downside will be that the build will take a lot longer, I think it can certainly add multiple minutes to the build.

[thias15]

Hi @francisduvivier.

This is great!

(1) I never actually checked the workflow, just assumed it worked. So this would be a great contribution! Ideally, it would only run when files in the android folder are changed and not for any push to the repo.

(2) This is also a good idea. I'm actually just about the tag the first release, now that the project seems to be semi-stable and some people were able to go through the complete process. Just to make sure. Would this only run when a new release is tagged? There should not be a new release for every push to the repo. So I guess ideally, people can download the apk from the build artifacts for every push and if a release is tagged the corresponding apk is added. Not sure if this is possible.

(3) I also agree on this and we are working on it. However, it requires some internal approvals to host the app in the Playstore.

Anyways, open to discussions. You obviously have much more experience than me with this.

[francisduvivier]

(1) Good point regarding changed files, we can arrange that with https://docs.github.com/en/free-pro-team@latest/actions/reference/workflow-syntax-for-github-actions#onpushpull_requestpaths,

(2) Yes I should actually split this in 2 parts as well since there is a difference between GitHub release assets and GitHub Action build artifacts. And so actually I would say that we use the build artifacts every time the apk is built, since the time-cost of uploading is very small compared to the build and it is IMO useful if you on every PR with changed android files can easily download the apk and quickly check the functionality when you want to. Also people who need access to a quick fix which is not released yet but is already on master could use this, or if you want people to check that a PR fixes their android issue for them.
Then as a 2.2 step, we can upload the same artifacts as a release asset in case of a tagged release, but it's a different trigger, different destination and a different Github Action, so it's quite a separate thing.

(3) Indeed, I am certainly not expecting this to be done anytime soon and I think the above stuff can stand fine on its own, it was just my Idea of where this could eventually go. Having a signing key would certainly already be a good step, so that you can upload the release version to the release assets and so that it is not signed with the google debug key. But yeah, you need to make sure that this key can only be used when authorized by owners, I don't know if there is a way to automate that in a public Github project.

[thias15]

This issue is completed with #68, #73 and #74.