'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

Will be this fix also part of 4.2 please?

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

Assigned to rp...@google.com.

for the "out" bundle issue, this seems indeed an issue. for the second one reported adding "debugUpdateAPKArtifact" to the path, this WAI as there can more more than one transformer and we need to automatically separate them so they do not use the same output folder. for #3, I will look at it but it might be difficult to change it at this time.

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

I understand that if there is more transformer is necessary to make every folder different, but there is the main problem, that the final one (last transform) is inside of the intermediate folder. The last transformation should end in the standard location, right? Maybe also with the default name not?

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

Hello, this is a P1 S1 issue for a while now, and it's blocking us from upgrading to AGP 4.2 and further. What's the current status? And do you have plans to backport it to 4.2.x?

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

no we don't have a plan to backport this. why is this blocking you from upgrading ?

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

We sign apk's and bundles via internal service, and i don't know another way to interact with artifacts; Yesterday i ended up with some ugly workaround: https://github.com/avito-tech/avito-android/pull/1085/files#diff-b898cc20fedebe394439bb37ffb91d3366a1f9a6d359dbdebca79af8a079f911 I'd be glad if you'll point me out how can it be done better.

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

I commented on the merge request but to summarize :

you can set your signing tasks output folder to wherever you need to be :

artifacts.use(target.tasks.signedApkTaskProvider(this)).configure { signedDirProperty.set(File("/path/to/where/you/want/your/signed/files")) }

if you don't set it, then we will set a directory automatically.

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

Thanks, Jerome!

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

I checked that we do have correct behavior for FILE based artifacts like bundle :

> Task :app:debugUpdateArtifact
originalArtifact: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/intermediates/bundle/debug/signDebugBundle/app-debug.aab
updatedArtifact: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/bundle/debug/app-debug.aab

however, we still seem to not be consistent for the DIRECTORY based artifacts like APK:

> Task :app:debugUpdateAPKArtifact
Input folder: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/apk/debug
Output folder: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/intermediates/apk/debug
Input file: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/apk/debug/app-debug.apk

Alex, can you have a look ?

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

correction, I was not correct about FILE being correct.

Instead of :

updatedArtifact: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/bundle/debug/app-debug.aab

it should be

updatedArtifact: /usr/local/google/home/jedo/src/studio-main/out/apiTests/Kotlin/bugTest/app/build/outputs/app-debug.aab
``

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

Two requests are created as they are API changes b/241581686 (set artifact name for transformation) and b/241582907 (change string to OutputFile)

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

Fix will be available in Android Studio F/AGP 8.0 Canary 2 Release

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

I tried to use it and at first look, it looks like everything works as expected. Thanks!

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

The big issue is, that the current AGP 7.4.0 is broken. I tried to use this API and it is still broken in 7.4.0, it is probably really in AGP 8 :-(

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