'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

Same project as here https://issuetracker.google.com/issues/256680246#comment6

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

Assigned to rp...@google.com.

Retraced stack

Caused by: com.android.tools.r8.CompilationFailedException: Compilation failed to complete
	at Version.fakeStackEntry(Version_8.0.13-dev.java:0)
	at com.android.tools.r8.utils.ExceptionUtils.failWithFakeEntry(ExceptionUtils.java:139)
	at com.android.tools.r8.utils.ExceptionUtils.failCompilation(ExceptionUtils.java:89)
	at com.android.tools.r8.utils.ExceptionUtils.withCompilationHandler(ExceptionUtils.java:83)
	at com.android.tools.r8.utils.ExceptionUtils.withD8CompilationHandler(ExceptionUtils.java:64)
	at com.android.tools.r8.D8.run(D8.java:122)
	at com.android.builder.dexing.D8DexArchiveMerger.mergeDexArchives(D8DexArchiveMerger.java:145)
	... 38 more
Caused by: com.android.tools.r8.errors.CompilationError: Dex file with version '37' cannot be used with min sdk level 'L'.
	at com.android.tools.r8.dex.ApplicationReader.throwIncompatibleDexVersionAndMinApi(ApplicationReader.java:264)
	at com.android.tools.r8.dex.ApplicationReader.validateOrComputeMinApiLevel(ApplicationReader.java:254)
	at com.android.tools.r8.dex.ApplicationReader$ClassReader.readDexSources(ApplicationReader.java:337)
	at com.android.tools.r8.dex.ApplicationReader$ClassReader.readSources(ApplicationReader.java:415)
	at com.android.tools.r8.dex.ApplicationReader.read(ApplicationReader.java:141)
	at com.android.tools.r8.dex.ApplicationReader.read(ApplicationReader.java:113)
	at com.android.tools.r8.dex.ApplicationReader.read(ApplicationReader.java:101)
	at com.android.tools.r8.D8.readApp(D8.java:177)
	at com.android.tools.r8.D8.run(D8.java:214)
	at com.android.tools.r8.D8.lambda$run$1(D8.java:125)
	at com.android.tools.r8.utils.ExceptionUtils.withCompilationHandler(ExceptionUtils.java:80)

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

Tried to run the reproduction with the code from https://issuetracker.google.com/issues/256680246#comment6. However that fails with:

* What went wrong:
Plugin [id: 'com.careem.publishing', version: '0.3.7', apply: false] was not found in any of the following sources:

Bingran, can you think of a situation where the global synthetics are compiled with a higher minSDK than the rest of the project? Dex file version 037 was introduced at minSDK 24 iirc.

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

Ah damnit. The artifact is also behind VPN. I will try to add a reproducer that doesn't depend on those artifacts or at least embeds them.

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

Updated repro project here https://issuetracker.google.com/issues/258237314#comment4, with internal dependencies bundled

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

I am able to reproduce the error by adding android.injected.build.api=24 to gradle.properties and run it from command line, which is same as running from IDE with a device of level 24. The root cause is the minSdkVersion used for merging global synthetics is not consistent with the version used when generating global synthetics in dexing. Fixed it with I79ac3ef95121378b3111bb01d0d45d92b101aee8

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

Can someone explain what exactly the global synthetics Gradle task generates and how to disable it using Kotlin script?

I found that every few builds the task suddenly becomes really slow (can take several minutes even for very small projects in those cases) and sometimes even makes the whole IDE unresponsive.

I didn't find an equivalent to android.enableGlobalSyntheticsGeneration in Kotlin script.

Unfortunately, there doesn't seem to be any documentation out there for the flag and/or the task. Or I'm just too dumb to properly Google it. 😅 For me, this thread is literally the only search hit.

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

There is no DSL for disable it and the gradle property android.enableGlobalSyntheticsGeneration will be gone soon. Basically we need to generate global synthetics for correctness of the build. If it makes the build slow, we would love to find out why. I guess it would be helpful if you could share a build scan so that we can have a better understanding of your build performance.

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