Appcenter: Option to sign and distribute debug builds to groups

[androideveloper]

When setting up branch configuration, I can't sign (and therefore distribute) debug build variants. It is a common practice to send debug builds for QA testing and this limitation is strange.

There a few alternatives:
-Create a separate build type (debug1) and it will work (but why the limitation exists on debug word?)
-Create a boilerplate post-build script that will distribute apks
-Create release variant and sign with debug key. Release build variant builds a little longer (proguard enabled) and that affects our workflow.

Why the limitation exists? Why can't we just use debug variant as others?

[nilofer]

Thanks for the issue @androideveloper. Taking a further look and I'll get back to you.

[matthiaswenz]

When running a debug build for Android Java/Kotlin apps the build tools automatically sign your application with a debug certificate. This is a self-signed certificate which hence should not be trusted outside the scope of your local debugging. Also, once the build is signed by the build tools, we can't re-sign it.

What is your need to distribute the debug build rather than a release build of your app?

The first alternative you mentioned is actually what we recommend: Create a dedicated build type for internal testing which uses a release certificate - this can then have build settings which might make triaging tester issues easier. In general though we recommend you distribute what's closest to your release build to your internal testing.

[androideveloper]

@ranterle Thanks for your reply. We have 3 build variants: debug, staging and release. For testing purposes, we distribute debug and staging builds via AppCenter (why distribute release builds? They are longer to build. Release apk-s are also dangerous on this step, they can be distributed on real users devices via email, etc. We use release build type only on pre-release and release steps). For staging builds (which is actually the same as debug, except that package id is suffixed with .staging) we don't have any issues using AppCenter.

"Also, once the build is signed by the build tools, we can't re-sign it." What regards to this, you can give us an option to sign apk using our gradle scripts (as in other cases, like staging).

[matthiaswenz]

When we built App Center Build for Android, there was no clear option on how to circumvent the Android tools perform the signing of the binary with a debug config.

Release apk-s are also dangerous on this step, they can be distributed on real users devices via email, etc.

I'm not entirely sure what this refers to - is your internal distribution process relying on the fact that people can't share the APKs with anyone else because they wouldn't work?
In our experience, internal release builds being as close as possible to our production builds has avoided many gnarly issues creeping up and the increase in build time was not significant. If you want to, you can also disable ProGuard/R8 i.e. in your staging config.

We will reconsider enabling the override switch for debug builds on Android Java/Kotlin - but in general the idea is that debug builds are not meant for installation on any non-debug devices, i.e. for distribution.

[f3mahmud]

Hello, I was wondering if this issue could be handled. We do have a team of testers and devs who at times use the debug builds for several purposes. Either ways we still download and re-upload the apk to distriibute to groups. We dont need it to be signed, but having the distriibution automated would be useful.

[hameno]

When we built App Center Build for Android, there was no clear option on how to circumvent the Android tools perform the signing of the binary with a debug config.

There has always been the possibility to configure the signing for debug builds. It's no different from release builds: You use signingConfigs, e.g.

debug {
   signingConfig signingConfigs.release
}

This is quite common, too. We use Hockey/AppCenter to distribute primarily test versions. They do not use the androiddebug keystore but a provided one.
Please remove this arbitrary restrction. Together with #32 this makes correctly building and distribution of Android apps almost impossible.

[matthiaswenz]

While this is fairly straightforward to configure, it is very unreliable to detect in analysis of the build configuration.
We decided at the time that since debug builds were discouraged from being distributed in the first place, there was a higher risk of confusing users by allowing to sign their debug build with a different config, then realizing things failed at a later step when we tried to sign it or they would distribute their builds and installation wouldn't work.
With the advent of React Native and people now also distributing debug variants of their app, we will look into reconsidering here, i.e. allow you to specify you manually took care of signing for your debug variant.
As a workaround: You can still create a separate build variant which is not named "debug" and incorporate the same configuration in there and App Center will let you sign and distribute it.

[yallam08]

It's also possible to manually distribute a debug build, so why the limitation on branch config?
It doesn't make sense .. if the case exists and many teams are using it and it works for them, why not allow it?

[akar33]

I agree with all the comments. We should have the flexibility on how to configure our builds. Microsoft cannot possibly know all the different matrices the devs are catering towards and to artificially restrict build configurations is bizarre, especially when a signed debug build _can_ be distributed when manually built.

[varuntribe]

When we built App Center Build for Android, there was no clear option on how to circumvent the Android tools perform the signing of the binary with a debug config.

Release apk-s are also dangerous on this step, they can be distributed on real users devices via email, etc.

I'm not entirely sure what this refers to - is your internal distribution process relying on the fact that people can't share the APKs with anyone else because they wouldn't work?
In our experience, internal release builds being as close as possible to our production builds has avoided many gnarly issues creeping up and the increase in build time was not significant. If you want to, you can also disable ProGuard/R8 i.e. in your staging config.

We will reconsider enabling the override switch for debug builds on Android Java/Kotlin - but in general the idea is that debug builds are not meant for installation on any non-debug devices, i.e. for distribution.

I think it should not be enforced by AppCenter that which build a client business should distribute. If you would like to enforce that, please also start blocking debug builds from getting uploaded from other CI/CD. It's a standard practice in the industry to test against staging or UAT env before creating final release builds. Reason being, we don't want everything to be deployed on prod before we can start testing it, hence different envs are required to achieve this abstractions and avoid buggy code from getting deployed to prod. We always build against staging env, test things throughly before we set them live in prod. This alone is the reason I would not be able to utilise AppCenter as our CI/CD, which is such a great platform, and will have to look for alternatives now.

[msftbot[bot]]

This issue has been automatically marked as stale because it has not had any activity for 60 days. It will be closed if no further activity occurs within 15 days of this comment.

[androideveloper]

New activity