Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add release APK into github releases #290

Open
3 tasks done
kslcsdalsadg opened this issue Nov 29, 2023 · 13 comments
Open
3 tasks done

Add release APK into github releases #290

kslcsdalsadg opened this issue Nov 29, 2023 · 13 comments
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@kslcsdalsadg
Copy link

Describe a related problem (optional)

No response

Describe your suggested feature

Please, consider to add the release APK into releases

Describe alternatives you've considered for your suggested feature

No response

Other details

No response

Acknowledgements

  • I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
  • I have written a short but informative title.
  • I will fill out all of the requested information in this form.
@kslcsdalsadg kslcsdalsadg added the enhancement New feature or request label Nov 29, 2023
@TrianguloY
Copy link
Owner

There are two ways to do that (that I know):

  1. Automatically build them with Github actions. The issue is that, in order to sign the apks, I will need to upload the signing private key here on Github. They have secrets, I know, but I would prefer to keep the signing key private.
  2. Manually build the apks on my computer and upload them. Right now I build the app with Android Studio (as aab) and then upload it to Play Store. I have automated the second part with gradle-triplet, but the first part is still manual. Building the apks and then upload them to github can somehow be automated too, but is something I need to invest time to know how to do it.

And last: the main reason I haven't spent time on this is because F-droid already provides links to download them: https://f-droid.org/repo/com.trianguloy.urlchecker_28.apk
Maybe I can make a release with them...

@kslcsdalsadg
Copy link
Author

Thanks for the answer. I prefer to download from the Github if available due to I'm not much confident with Google but in fact I'm still less confident with F-Droid. There's no reason to it really, it's just my opinion.

@PabloOQ
Copy link
Collaborator

PabloOQ commented Dec 4, 2023

Is there any problem if the releases were signed as a different app/entity? After all you already made a workflow for alpha releases.

@kslcsdalsadg
Copy link
Author

If certificate used to sign the app changes is mandatory to uninstall previous installed app to install the new one

@TrianguloY
Copy link
Owner

If certificate used to sign the app changes is mandatory to uninstall previous installed app to install the new one

Exactly. Think of the certificate as the 'author' of the app (one that only those with the private kay can generate). You cannot have the same app by different authors.

Right now play store uses my own private key, while f-droid uses the f-droid private key (they have a way to use yours, but when I started either it was hard to configure or most probably I didn't had time to set it up). Using a third key for Github apks is even worse, I would like to avoid that.

Alpha releases are simply not signed (or, to be precise, they are signed with the public debug key).

@kslcsdalsadg
Copy link
Author

Why you simply upload here the PS version when upload to PS?

@TrianguloY
Copy link
Owner

Because play store doesn't use apks (they use aab, a different format).
That's option 2 from my original post.

Manually build the apks on my computer and upload them. Right now I build the app with Android Studio (as aab) and then upload it to Play Store. I have automated the second part with gradle-triplet, but the first part is still manual. Building the apks and then upload them to github can somehow be automated too, but is something I need to invest time to know how to do it.

@kslcsdalsadg
Copy link
Author

I'm still using APKs when upload anything to the Play Store. I'm old school ;)

@PabloOQ
Copy link
Collaborator

PabloOQ commented Dec 5, 2023

Using a third key for Github apks is even worse, I would like to avoid that.

That's what I meant, is that really a problem? That way you can keep your key in your PC and still offer a way to download the app from GitHub (which otherwise is not offered). After all, unless I'm missing something (that's probably it right? 😅) if someone chooses to download the app from here I'm guessing is to avoid F-Droid and Play store, so to keep the app updated they would want to download the update from here too.

Alpha releases are simply not signed (or, to be precise, they are signed with the public debug key).

Oh, that I didn't know!

@kslcsdalsadg
Copy link
Author

Yes, I like download from GitHub site to avoid to use GPlay or FDroid.
Thanks

@TrianguloY
Copy link
Owner

Using a third key for Github apks is even worse, I would like to avoid that.

That's what I meant, is that really a problem? That way you can keep your key in your PC and still offer a way to download the app from GitHub (which otherwise is not offered). After all, unless I'm missing something (that's probably it right? 😅) if someone chooses to download the app from here I'm guessing is to avoid F-Droid and Play store, so to keep the app updated they would want to download the update from here too.

Hmm, you are correct. In fact it's just another option for users to choose, it will be fully automatic too so it's perfect.
I'll still want to add a proper description to explain this though (that you cannot mix them).

This should be simple, I will try to set it up soon but you already saw that I'm quite absent currently :(
If someone wants to create a PR with the action template that would be wonderful!

@TrianguloY TrianguloY added the good first issue Good for newcomers label Mar 16, 2024
@Bakr-Ali
Copy link

Bakr-Ali commented Apr 14, 2024

I will need to upload the signing private key here on Github. They have secrets, I know, but I would prefer to keep the signing key private.

Do you mean anyone will have access to the signing key? Or that GitHub will know it which you don't want to? I assume its the second one because I have seen many repositories that let GitHub sign the apk with the private key without the key being public.

Using a third key for Github apks is even worse, I would like to avoid that.

That's what I meant, is that really a problem? That way you can keep your key in your PC and still offer a way to download the app from GitHub (which otherwise is not offered). After all, unless I'm missing something (that's probably it right? 😅) if someone chooses to download the app from here I'm guessing is to avoid F-Droid and Play store, so to keep the app updated they would want to download the update from here too.

Hmm, you are correct. In fact it's just another option for users to choose, it will be fully automatic too so it's perfect. I'll still want to add a proper description to explain this though (that you cannot mix them).

This should be simple, I will try to set it up soon but you already saw that I'm quite absent currently :( If someone wants to create a PR with the action template that would be wonderful!

If you don't trust GitHub then you shouldn't do this either, since it will essentially be compromising the users who use GitHub to update the app instead of the users who use Play Store.

Besides, not everyone uses GitHub exclusively for updates. For example, I use GitHub to get the apks initially (especially on a new device or after factory reset), but might sometimes use other methods for updating, like apkmirror or similar websites/apps that take the apks from Play Store. Using a third key will prevent such workflows.

@TrianguloY
Copy link
Owner

Do you mean anyone will have access to the signing key? Or that GitHub will know it which you don't want to? I assume its the second one because I have seen many repositories that let GitHub sign the apk with the private key without the key being public.

Yes, I can upload it as a secret and that way no one (not even me!) should be able to see it from github itself. However I still prefer to keep it on my computer only (well, and on google, they require it since a few years ago unfortunately).

If you don't trust GitHub then you shouldn't do this either, since it will essentially be compromising the users who use GitHub to update the app instead of the users who use Play Store.

That's why I didn't want to do it at first. However as it has been discussed that's a decision that the user should be able to do. Maybe I don't trust github enough, but if a user does, they should have the choice.

Besides, not everyone uses GitHub exclusively for updates. For example, I use GitHub to get the apks initially (especially on a new device or after factory reset), but might sometimes use other methods for updating, like apkmirror or similar websites/apps that take the apks from Play Store. Using a third key will prevent such workflows.

Yes, this is the downside of the approach. With the new backup/restore functionality it's less of a problem, but still as you said you are 'stuck' with the version you downloaded it from (which also happens with f-droid, unless I somehow discover how to do that 'validate' way of providing a signed apk that they use after validating that it's exactly the same as the code here).

I would like to automate it from my computer directly, so that I press a button and it is built, uploaded to play store and uploaded to github, everything without any extra effort. The play store part is more or less solved already (thanks to gradle triplet) and I would like to do the second part with the gh cli, but I still need to spend time to properly configure everything...and I don't know when I'll have the time for it.

Plus this should also allow it to be uploaded to other stores like Accrescent, if needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

4 participants