'debug' build type has default signing key, others do not [111118208]

Fixed

Bug

Status Update

No update yet.

Description

cc...@google.com

created issue #1

Jul 3, 2018 05:33PM

Having an unsigned, non-debuggable build is very useful for profiling, but when I try and run the release variant of a small test APK, I get the following error in the event log:

10:19 AM Error running 'app': The apk for your currently selected variant (app-profile.apk) is not signed. Please specify a signing configuration for this variant (profile).

This doesn't make sense to me, since I've in the past been able to run non-debuggable apps without signing, so I try and create a 'profile' variant which copies all the default settings from 'debug', but just sets debuggable -> false. Same error.

For some reason, I can edit the 'debug' build type to run debuggable, but not any other build type.

Build: 3.2 Beta 2, AI-181.5281.24.32.4860949, 201806252233, AI-181.5281.24.32.4860949, JRE 1.8.0_152-release-1136-b04x64 JetBrains s.r.o, OS Linux(amd64) v4.9.0-6-amd64 unknown, screens 2560x1600, 1920x1200Android Gradle Plugin: 3.3.0-alpha01Gradle: 4.8NDK: from local.properties: 15.0.4075724; latest from SDK: 15.0.4075724; LLDB: pinned revision 3.1 not found; latest from SDK: (package not found); CMake: from local.properties: (not specified); latest from SDK: /usr/local/google/sdk/cmake/3.6.3155560/bin/cmake -version/usr/local/google/sdk/cmake/3.6.3155560/bin/cmake: error while loading shared libraries: libssl.so.1.0.0: cannot open shared object file: No such file or directory; from PATH: (not found); IMPORTANT: Please read

https://developer.android.com/studio/report-bugs.html carefully and supply all required information.

Comments

cc...@google.com <cc...@google.com> #2Oct 1, 2018 07:43PM

Tried to repro in 3.3 Canary 12, not able to edit build variants, getting a different error that blocks me trying to repro -

1) Right click app in the project window
2) select module settings
3) select build variants
4) create a 'custom' build variant with Debuggable disabled.

Expected:
That variant to show up in 'Build Variants' window

Observed
Build Variants is empty, if I go into the build variant options again, both my custom build variant and 'debug' are deleted. I tried to recreate 'debug', but it's still broken - the build variant window still says 'nothing to show', and my project fails to gradle sync.

le...@google.com <le...@google.com> #3Oct 1, 2018 09:25PM

Assigned to rp...@google.com.

Renaud, would this be in your team?

uc...@google.com <uc...@google.com> Mar 13, 2020 09:03PM

Reassigned to an...@google.com.

es...@google.com <es...@google.com> #4Apr 27, 2020 10:32PM

Chris is this bug still applicable? We cannot run unsigned apks. Or do you mean you want debuggable=off with debug signature in them?

cc...@google.com <cc...@google.com> #5Apr 28, 2020 02:52PM

Esteban - yes. For some context, this bug was originally filed about some Studio UI that ~sort of~ let you edit signing configs, but I haven't been able to find any more. This should probably be moved to a better category.

The root point still stands though when configuring through gradle files - the error message from #1 is difficult to act on:

10:19 AM Error running 'app': The apk for your currently selected variant (app-profile.apk) is not signed. Please specify a signing configuration for this variant (profile).

This raises the question - why is signing required only for non-debug variants?

The answer is (I assume) that debug builds are signed with a special key since they're never deployed to play store. However, not every non-debug build variant is either. release (or custom build variants) are useful for many things before deploying to play:

- profiling
- testing minification / R8
- benchmarking

There are a few options that could improve things for these use cases (so folks don't go and add fake/temporary signing keys, since the error message implies they have to).

1) make signingConfigs.debug more discoverable

I'd like to see some official docs on how to use it, e.g. here:

https://developer.android.com/studio/build/build-variants#signing

Could also add a link to these docs any time we give the "this is unsigned" error. That would help significantly.

2) make signingConfigs.debug the default for library test APKs

Library test APKs (androidTest in a library module) follow the same signing constraints as regular apps - they must be signed to run in release mode. These test APKs are self-instrumenting tests - they shouldn't be uploaded to the store, so they're likely to never need to be 'correctly' signed.

3) make signingConfigs.debug the default for all APKs

This is more extreme, but worth discussing. Play store already blocks you from uploading debug signed APKs - would it be acceptable to just debug-sign everything by default so that apps don't have to worry about this until upload?

es...@google.com <es...@google.com> #6Apr 28, 2020 06:40PM

Thanks, yeah much of that makes sense to me. I'm moving this to the AGP team, to decide how the app is build and what signatures are required on release.

cc...@google.com <cc...@google.com> #7Apr 28, 2020 06:58PM

Retitled, since the original title was about behavior in the Studio UI for buildtype configuration. Not an issue when configuring through build.gradle

je...@google.com <je...@google.com> May 4, 2020 04:21PM

Reassigned to cm...@google.com.

cm...@google.com <cm...@google.com> #8May 7, 2020 12:20PM

2 seems uncontroversial to me, so we should at least do that.

cm...@google.com <cm...@google.com> May 7, 2020 03:40PM

Accepted by cm...@google.com.

cm...@google.com <cm...@google.com> #9May 12, 2020 11:51AM

2 is done in https://android.googlesource.com/platform/tools/base/+/04a5f9c9abb6c681c79a6d31e940a9b0ae852be4 which will be in a future 4.1 release.

je...@gmail.com <je...@gmail.com> #10Aug 24, 2021 07:22AM

I think this is related:

https://issuetracker.google.com/issues/197430188

cc...@google.com <cc...@google.com> #11Nov 8, 2021 10:27PM

Default signing key for release builds came up in a conversation with +Jedo and +Xav today, in the context of encouraging people to profile performance accurate (release) builds. There was concern that pushing people to release builds would mean they couldn't run the unsignable builds by default.

While the fix for 2 above was great for library builds, using the debug key universally would simplify what needs to be done for profiling release builds.

cc...@google.com <cc...@google.com> Nov 17, 2021 09:01PM

Assigned to je...@google.com.

lu...@google.com <lu...@google.com> #12Jan 10, 2022 01:19PM

From AGP 7.3-alpha01, debug signing will be automatically applied to build types with debuggable or profileable enabled, if there are no other signing configs defined for the build type.

yi...@google.com <yi...@google.com> #13Feb 15, 2022 01:06AM

Hi Luke, how about when profilingMode is set (i.e. when launched from profilers)? Can debug signing also be automatically applied in that case?

lu...@google.com <lu...@google.com> #14Feb 16, 2022 10:14AM

Yes, the new behavior means when profileable/debuggable is enabled, the default debug signing config will be used if no other signing config is specified (see VariantDslInfoImpl:845).

yi...@google.com <yi...@google.com> #15Feb 16, 2022 08:29PM

It works fine when I use the new profileable DSL but not when I launch the new profiler toolbar (which sets the profilingMode flag under the hood).
The run config shows an IDE error and wouldn't let me proceed. See attached screenshot.
It might have something to do with when the flag is set (com.android.tools.idea.run.MakeBeforeRunTaskProvider), maybe there's some timing issue between signing and its check?

Wed Feb 16 2022 12:20:59 GMT-0800 (Pacific Standard Time).png

56 KB

View

Download

cm...@google.com <cm...@google.com> #16Feb 17, 2022 11:24AM

Reassigned to yi...@google.com.

This only takes effect when the flag is injected - the model Studio sees will still see that variant as unsigned.

I'd suggest the logic in Studio that blocks the run configuration in Studio from running needs to be updated so when the profileable flag will be injected it assumes that the build system will sign and doesn't warn or block deployment (for AGP versions that support it, of course)

cm...@google.com <cm...@google.com> #17Feb 17, 2022 11:24AM

Yi - are you the right person to own that part?

yi...@google.com <yi...@google.com> #18Mar 21, 2022 06:55PM

Per Diego, "my understanding is that we probably need to pass the ProfilerState.PROFILING_MODE to the ApkProvider so it can make the decision on whether it needs to be signed or not."

Message last modified on Mar 21, 2022 06:55PM

di...@google.com <di...@google.com> #19Mar 23, 2022 02:15PM

Marked as fixed.

This was fixed by http://ag/17044839 and should be available in Dolphin Canary 7 already.

yi...@google.com <yi...@google.com> #20Mar 23, 2022 06:16PM

Status: Assigned (reopened)

Thanks for the update. I just tried Dolphin Canary 7 (as well as studio-main dev build): when I tried to run the release variant, I got this error:

03/23 11:13:22: Launching 'app' on Google Pixel 4.
Installation did not succeed.
The application could not be installed: INSTALL_PARSE_FAILED_NO_CERTIFICATES

List of apks:
[0] '/Users/yiyiyang/AndroidStudioProjects/ProfilerTester/app/build/intermediates/apk/release/app-release-unsigned.apk'
APK signature verification failed.
Retry
Failed to launch an application on all devices

di...@google.com <di...@google.com> #21Mar 23, 2022 06:20PM

What's the version of AGP? My understanding is that the flag will only work after a certain version?

yi...@google.com <yi...@google.com> #22Mar 23, 2022 06:52PM

7.3.0-alpha07, which supports profileable.
I just realized I set the profiling mode to debuggable. So I tried profileable, which seemed to work. Looking at ag/17044839, I believe the condition should be profilingMode != NONE as either PROFILEABLE or DEBUGGABLE is considered profileable.

so...@google.com <so...@google.com> #23Mar 24, 2022 12:45PM

Please do not use !=. if both modes are profileable add a method to the
enum class so that it can look like profileMode.isProfileable

On Wed, 23 Mar 2022 at 18:52, yiyiyang <buganizer-system+yiyiyang@google.com>
wrote:

- Show quoted text -

yi...@google.com <yi...@google.com> Apr 1, 2022 06:55PM