search

bitrise-steplib / steps-deploy-to-bitrise-io

Deploy build artifacts to bitrise.io
MIT License
23 stars 40 forks source link

No way to opt out of universal APK generation #93

Closed DSteve595 closed 3 years ago

DSteve595 commented 5 years ago

When deploying a bundle, the step automatically builds a universal APK out of it. However, it's not signed with the same key, so it's not useful to us. We're manually calling assembleRelease in addition to bundleRelease so that we get an AAB and a universal APK, both signed. It would be good to have an option to prevent the step from generating its own universal APK.

bitce commented 5 years ago

Hey @DSteve595,

Thanks for reporting, could you please include a build URL of this happening here?

DSteve595 commented 5 years ago

@bitce Can I send it privately?

bitce commented 5 years ago

Sure thing, just hit us up on our on-site chat 🙂

linean commented 5 years ago

We have the same issue as @DSteve595 . In my opinion generating universal APK should be treated as a separate step.

Diego-Franco commented 5 years ago

Any update on this one? I have the same issue

radko93 commented 5 years ago

The same issue, I can't upload my bundle right now as this step fails, I don't care about the universal APK.

ghost commented 5 years ago

Hi everyone! 👋 Basically we included the universal APK creation in our Deploy to Bitrise.io step for troubleshooting purposes. The step should in no way be changing the actual exported bundle or excluding it from deployment to Bitrise. If for whatever reason, the step is interfering with that functionality, please send us a build URL and we will look into it 😄

RustamG commented 5 years ago

Hi everyone! 👋 Basically we included the universal APK creation in our Deploy to Bitrise.io step for troubleshooting purposes. The step should in no way be changing the actual exported bundle or excluding it from deployment to Bitrise. If for whatever reason, the step is interfering with that functionality, please send us a build URL and we will look into it 😄

@ahvth-bitrise, The thing is that Install page will contain universal APK instead of AAB that I specified in Deploy directory or file path

bitce commented 5 years ago

Hi @RustamG!

That's correct. We do have an ongoing issue, but that's that the Deploy step will print this out otherwise (says that an install page is available for the .aab while it's only so for the universal .apk)

This is intended because .aabs are zips and you couldn't directly install them on your device (not due to it being a folder but due it being a distribution method essentially) - that said you can manually allow them on the Apps and Artifacts folder.

arthursady commented 5 years ago

@bitce Is there a way to send the email with the .aab public install page automatically?

I don't want the email to install the apk in a device. I want to be able to download the file without necessarily having access to the bitrise credentials from my account. That would make my flow much easier if I can send the link to the .aab instead of the link to the .aab.universal.apk

Roland-Bak commented 5 years ago

Hi there @arthursady!

There is a way that you can manually enable sending a public install page: image

If you have Slack, you can update it to send a message with all public install pages.

How to use it:

!/usr/bin/env** bash

installPageURLs="${BITRISE_PUBLIC_INSTALL_PAGE_URL_MAP//|/ }" installPageURLs="${installPageURLs//=>/|}" slackMessage="View App|${BITRISE_APP_URL} View Build|${BITRISE_BUILD_URL} ${installPageURLs}"

envman add --key SLACK_MESSAGE_WITH_URLS --value "$slackMessage"

arthursady commented 5 years ago

Thx, that also solves my problem. I will give it a try.

WarrenFaith commented 5 years ago

@ahvth-bitrise personally I am fine with the generated universal apk as our QA can easily test it this way. The only issue is: the apk is not signed correctly. It is signed with an Android Debug key, so we are unable to upload the apk into the store nor can we install it over previously generated and released apks because of mismatch of the certificate. The aab has the right certificate...

Certificate of the AAB

martin:~/Desktop$ keytool -list -printcert -jarfile release.aab Signer #1:

Signature:

Owner: CN=Name, OU=Company, O=Company, L=Berlin, ST=Berlin, C=BE Issuer: CN=Name, OU=Company, O=Company, L=Berlin, ST=Berlin, C=BE Serial number: 51752f00 Valid from: Mon Apr 22 14:37:20 CEST 2013 until: Wed Feb 28 13:37:20 CET 2046 Certificate fingerprints: MD5: 9A....60 SHA1: 7D....3B SHA256: 6C...E7 Signature algorithm name: SHA1withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3

Certificate of the APK

martin:~/Desktop$ keytool -list -printcert -jarfile universal-release.apk Signer #1:

Signature:

Owner: C=US, O=Android, CN=Android Debug Issuer: C=US, O=Android, CN=Android Debug Serial number: 3cf2d829 Valid from: Tue Oct 01 13:17:17 CEST 2019 until: Sat Feb 16 12:17:17 CET 2047 Certificate fingerprints: MD5: FA...53 SHA1: 16...35 SHA256: B0...DF Signature algorithm name: SHA256withRSA Subject Public Key Algorithm: 2048-bit RSA key Version: 3

Extensions:

1: ObjectId: 2.5.29.14 Criticality=false

SubjectKeyIdentifier [ KeyIdentifier [ 0000: DB 74 BB 3F C0 33 DA 56 64 E2 C0 91 4B 38 9B 06 .t.?.3.Vd...K8.. 0010: A1 69 16 22 .i." ] ]

maxlapides commented 5 years ago

I agree with @WarrenFaith. The root of the issue is the incorrect signing of the universal APK.

vpontis commented 5 years ago

Yep, also having problems with the APK since it is signed with the incorrect key.

It looks like it should be pretty easy to fix. We just need a way of putting in the path to the keystore via env vars here: https://github.com/bitrise-steplib/steps-deploy-to-bitrise-io/blob/f21a87fa42176f4bf03bf4744300400e86994dcf/aabutil.go#L56

tir38 commented 4 years ago

Just to create a paper trail: https://discuss.bitrise.io/t/android-stop-deploy-to-bitrise-io-step-generating-deploying-universal-apk-file-from-aab-file/10861/2

squeeish commented 4 years ago

Thanks for this. Yes, the universal APK is being signed wrongly.

danielhalim92 commented 4 years ago

Created the feature request here: https://discuss.bitrise.io/t/sign-auto-generated-apk-by-deploy-to-bitrise-step-using-the-same-keystore-to-sign-aab/11581

paramaggarwal commented 4 years ago

Problem

The APK is signed using a temporary debug key - this causes problems like the one mentioned in https://github.com/bitrise-steplib/steps-deploy-to-bitrise-io/issues/119. Such a broad assumption should not be made.

Fix

It should pick up the credentials from the code signing variables that configured already in the workflow as standard. Please use these when available, otherwise fall back to what is mentioned above:

Reference

https://github.com/bitrise-steplib/steps-deploy-to-bitrise-io/blob/b74fb07f34f8a76469896e2116b1f8932826a254/aabutil.go#L38-L51

G00fY2 commented 4 years ago

Any news on this?

We run assemble and bundle task and use the "Android Sign" step afterwards. This results to the following files:

app-production-store-release20200430145733.aab
app-production-store-release20200430145733-bitrise-signed.aab
app-production-store-release.aab
app-production-store-universal-release20200430145733.apk
app-production-store-universal-release20200430145733-bitrise-signed.apk
app-production-store-universal-release.apk
appname-app-productionStoreRelease.apk
appname-app-productionStoreRelease-bitrise-signed.apk

I would expect:

app-production-store-release.aab
app-production-store-release-bitrise-signed.aab
appname-app-productionStoreRelease.apk
appname-app-productionStoreRelease-bitrise-signed.apk

Pretty confusing artifact output. Would be great if we could disable the "universal apk" generation. And I guess there is a bug with the createDeployPth which results in the files with the timestamps.

paramaggarwal commented 4 years ago

I have suggested an approach to fix this here: https://github.com/bitrise-steplib/steps-deploy-to-bitrise-io/issues/121

This can be an easy task for someone with Go-lang experience

pigeon-archive commented 4 years ago

This feature has been added to our internal productboard. We will notify you all here once the implementation has been finished.

G00fY2 commented 4 years ago

@paramaggarwal your PR doesn't really relate to the root topic of this issue. I am also looking for a simple flag to skip the ensureAABsHasUniversalAPKPair function in the deploy step. ;)

paramaggarwal commented 4 years ago

Ah yes, the request in this particular discussion is to bypass it rather than customise it. 👍

androideveloper commented 4 years ago

Any updates on this?

Now that we have an official universal apk build step it has collisions with this one https://github.com/bitrise-steplib/bitrise-step-export-universal-apk/issues/8

royerdavid commented 4 years ago

As there is a new "export universal apk step", there should be an option in the "deploy to Bitrise" step to not generate the universal APKs.

G00fY2 commented 3 years ago

This is really frustrating. This issue is still not solved, any news?

pigeon-archive commented 3 years ago

There is unfortunately no updates yet. I'm very sorry for the frustration. I've bumped this internally.

androideveloper commented 3 years ago

This is very frustrating for us too, as we get 2 apks at the end of the build

kdani41 commented 3 years ago

Any updates on this? I see an open PR #126. Does that resolve the issue?

bitce commented 3 years ago

Hey everyone! We are looking into accepting #126 for a quick fix and researching & discussing the long term solution with you guys. Thanks for all the patience so far!

EyMaddis commented 3 years ago

Sidenote: I also find it annoying that the build is signed with "android debug". I made a step that deletes all apk/aab that are not signed how they are supposed to but thanks to this issue this slips throught. Now we deployed a debug signed apk to Amazon. Luckily that store does not care about signing...

royerdavid commented 3 years ago

@EyMaddis You're lucky. We've deployed it in a Store in China and it took us weeks to be able to get them to let us upload a build with the proper release signature after that.

G00fY2 commented 3 years ago

It took 17 month to provided "quick fix" by merging a community pr. I don't want to be disrespectful but this is bad customer support.

lchrislee commented 3 years ago

I think the blame goes both ways. It took 17 months for someone in the community to care enough and contribute to an open source step 🤷

If there's issues with the community fix, let's work together to find and resolve it in less than 17 months.

mateherber commented 3 years ago

Hi @G00fY2,

Thank you for your feedback! We are aware that the wait on this (and several others) issue had been long without much communication from our side, I'd like to apologize for that.

We are working hard to support the vast amount of our steps utilizing our resources the most impactful way. As this issue was not critical in a sense that while the generated *.apk is not signed properly - we never intended for it to be used for any other than testing purposes, it never got high enough on our priority list.

Where we failed is the upfront communication so we decided to improve on that on an organization level. We have a team dedicated for step development and maintenance and that team's priority this year will be improving the priorization and communication on our issues / PRs, also welcoming and supporting our community to actively participate in discussing, fixing and improving our step library.

Regarding this issue I think we can all agree that the accepted PR is not a solution rather a "quick-fix" (the reason why we never implemented and hesitated merging the PR for this long), so we decided to handle it in a proper way. We're going to deprecate the *.apk generation from this step and will introduce a flag on the build and sign steps to be able to have properly built and signed *.apk next to the *.aab for testing purposes. Should any question / concern / feedback arise regarding this approach, please discuss it on the follow-up issue here.

G00fY2 commented 3 years ago

Hi @mateherber, thanks for your detailed answer! Short comment to finish my thoughts (probably off-topic): My intention was not to use this issue for "ranting" about your support. I really like bitrise.io and we (the company I work for) are very happy using your product in our day-to-day work.

We used a lot of other CI/CD platforms in the past and one issue I often see is that many steps/tasks do too much "magic". So when you have a Gradle task to generate an ABB file, and simply want to deploy it, the CI shouldn't decide to generate an additional APK or at least let me opt-out. Thats what bothers me. So for me this is more an issue about the "mentality" of how steps are intended (and ofc documented). Sure, I could fork the step and adjust everything for my personal needs (thanks again to @lchrislee). But we choose bitrise.io to minimize the work for CI/CD processes.

androideveloper commented 3 years ago

Hi @mateherber

First of all thanks for giving at least quick-fix for this issue. One question though. You mentioned that you're going to deprecate the .apk generation in this step and introduce a flag on the build and sign steps to generate them. But we already have a step that generates universal apk, isn't it enough for testing purposes? https://github.com/bitrise-steplib/bitrise-step-export-universal-apk

I also created an issue there that relates to this one https://github.com/bitrise-steplib/bitrise-step-export-universal-apk/issues/8.

mateherber commented 3 years ago

Hi @androideveloper,

That is actually an excellent idea. It has the drawback of forcing the user to set-up the keystore inputs again for this step but we're going to run tests with the step and if it can cover all the use-cases we're trying to solve with the *.apk we will close the issue above and advocate using the export-universal-apk step instead. Please stay tuned for the updates.

androideveloper commented 3 years ago

Hi @mateherber

Thanks! I wouldn't say it's a drawback as you have control over the keystore you use. And also it's very easy to setup, so would be nice to go in that direction.

istvankovacs-bitrise commented 3 years ago

Please see this thread for the resolution.