Introduce the Android Alpha track 🎉

[nilsreichardt]

Description

This PR adds an Alpha track for Android, like we already have for web with https://alpha.web.sharezone.net. On every commit on the main, we build a new Android version. Because Firebase Distribution doesn't care about versioning, we don't need a complicated system for increasing the version number.

As release note we are using the last commit message.

Users can join the Alpha track via this link: https://appdistribution.firebase.dev/i/9c4942a1c01a5496. Just follow the introductions by Google. But I think we should also add our own docs later (How to join the alpha program, how to leave, etc.). Would be good to do #166 first.

We should first merge the following PR before merging this PR:

• Fix Android builds for CI machines & drop for support macOS video player #241

Closes #215

[github-actions]

Visit the preview URL for this PR (updated for commit 5244ffe):

https://sharezone-test--pr235-android-alpha-hhe8t4ln.web.app

_{(expires Wed, 25 May 2022 15:01:49 GMT)}

_{🔥 via Firebase Hosting GitHub Action 🌎}

[nilsreichardt]

@Jonas-Sander You can now review :)

[Jonas-Sander]

If it's not mentioned here than I wouldn't bother: https://docs.github.com/en/actions/security-guides/security-hardening-for-github-actions

But if you look here under "Register all secrets used within workflows" then we should maybe register these files as secrets?

Anyways if you leave this code then at least write via documentation that you're not fully sure yourself if that step is necessary. I personally don't think so.

[nilsreichardt]

For now, I just removed step. Just in case we should remove the files or mark them as secret, we need to do this in other workflows as well. Therefore, I would do this in a different PR.

[Jonas-Sander]

Hm, okay. Can you create an issue for marking them as secrets? (I'm currently on mobile) Just so that we don't forget:)

[nilsreichardt]

I opened #245 but I think the in the section "Register all secrets used within workflows" they are talking about something different. I understand that if we create a new secret within a workflow (like generating a JWT), you can mark this as secret so that this secret with not shown in the logs. But all the files that we created like sharzeone-prod-key.json, key.properties, etc. are just already registered secrets (just written in a file). So they should already be masked in the logs.

My concern was a different one. I was more thinking about that the company GitHub is compromised and someone got access to the GitHub Actions containers and is able to read all the files. Or we say that we don't trust GitHub that they really delete all files after finishing a workflow. I know that are rare cases but my idea was to just decrease the risk where we have the impact to do it (especially when it's so easy like here we just execute 3 commands).

[nilsreichardt]

I was more thinking about that the company GitHub is compromised and someone got access to the GitHub Actions containers and is able to read all the files. Or we say that we don't trust GitHub that they really delete all files after finishing a workflow. I know that are rare cases but my idea was to just decrease the risk where we have the impact to do it (especially when it's so easy like here we just execute 3 commands).

I thought a bit about that doesn't make sense (except you don't trust GitHub that they do not delete the VMs immediately)

[Jonas-Sander]

Please check again that nothing gets leaked in the logs and create the issue for marking the files as secrets (if the docs say it's necessary in our case).

Otherwise LGTM! 🎉