App is not signed with v1 scheme when using minSDK 24, even when enabled explicitly [134858541]

Assigned

Bug

Reviewed (L1)

Status Update

No update yet.

Description

ni...@ansman.se

created issue #1

Jun 10, 2019 02:34PM

Gradle version: 5.4.1
Android Plugin Version: 3.5.0-beta01 - 3.5.0-beta04
Module Compile Sdk Version: 28
Module Build Tools Version: 29.0.0
Android SDK Tools version: 26.1.1
Min SDK version: 24

Regardless of if I enable v1 signing explicitly (enabling it in the signing config) or if I build a signed APK via Android Studio (ticking the v1 scheme box) the output APK is not signed using the v1 scheme, only the v2 scheme.

I filed this issue previously (

https://issuetracker.google.com/issues/133325048) with less specifics, opening a new one with more specific info

I now believe this is because AGP detects that I'm using 24 as the min SDK and rather than set the default value of v1 signing to false it simply disables that feature entirely.

See the related issue for a sample project.

Comments

da...@google.com <da...@google.com> Jun 10, 2019 02:35PM

Assigned to bi...@google.com.

ni...@ansman.se <ni...@ansman.se> #2Jun 10, 2019 02:52PM

This is pretty bad for us as it prevents us from uploading builds to Fabric Beta (they require v1 signing)

bi...@google.com <bi...@google.com> #3Jun 13, 2019 10:42AM

Reassigned to ku...@google.com.

The ability of enabling v1 signing through signing config is disabled when SDK version is 24+. I think we should provide users an option to enable v1 signing regardless of SDK version, right?

ku...@google.com <ku...@google.com> #4Jun 17, 2019 08:20AM

Reassigned to bi...@google.com.

I believe the initial assumption was that v1 signature never needed if minSDK (and therefore the target device) is 24+. Since people have problems with this we'd better revert that/rework the solution.

bi...@google.com <bi...@google.com> Jun 17, 2019 09:03AM

Accepted by bi...@google.com.

ni...@ansman.se <ni...@ansman.se> #5Jun 17, 2019 01:02PM

I would happily have it disabled as default but that it can be enabled

je...@google.com <je...@google.com> #6Jun 17, 2019 04:04PM

right, we should provide a setting to forcefully re-enable it.

bi...@google.com <bi...@google.com> #7Oct 14, 2019 04:43PM

Hi Nicklas, it is unfortunate this bug prevents you uploading builds to Fabric Beta as they require v1 signing. I wonder if the following signing mechanism(for minSDKVersion 24 and above) can unblock you.

1. For release, we sign with v1 and v2 by default unless users explicitly disable them through DSL
2. For debug, we only sign with v2 by default unless users explicitly disable it through DSL. If v2 is disabled, we sign with v1 only. The reason why we don't want to sign with v1 is to improve build performance and it is not necessary in most cases.

ni...@ansman.se <ni...@ansman.se> #8Oct 14, 2019 09:16PM

To be honest I don't really think this is particularly important any longer. We have since switched to use Firebase App Distribution which does not have the requirement to sign with v1. But what you wrote does make sense. I'm even fine with disabling v1 signing by default when using minSDK>=24 as long as it respects when you explicitly enable it through the DSL.

bi...@google.com <bi...@google.com> #9Dec 9, 2019 03:04PM

Marked as fixed.

The fix will be included in 4.0 canary 6. I also filed

b/145907649

to update docs.

The implementation basically has the same idea as

comment #5

. V1 signing can be definitely enabled through DSL and it might be disabled by default based on min sdk and target sdk.

li...@gmail.com <li...@gmail.com> #10Nov 2, 2022 05:57AM

I am using AGP 7.1.3, and after I enable V1 signing:

v1SigningEnabled true
v2SigningEnabled true

And the final apk is signed with V2 and V3 signature.

Verified using v1 scheme (JAR signing): false
Verified using v2 scheme (APK Signature Scheme v2): true
Verified using v3 scheme (APK Signature Scheme v3): true
Verified using v4 scheme (APK Signature Scheme v4): false

bi...@google.com <bi...@google.com> Nov 2, 2022 03:45PM

Status: Assigned (reopened)

bi...@google.com <bi...@google.com> #11Dec 22, 2022 02:34AM

Reassigned to sp...@google.com.

Those old dsl has been deprecated and has no effect IIUC. Can you try enableV1Signing and enableV2Signing? Assign to Scott as he has more context.

sp...@google.com <sp...@google.com> #12Dec 27, 2022 03:58AM

Marked as fixed.

That's right. Closing this bug, but reply on this thread if that doesn't fix your issue.

nd...@newrelic.com <nd...@newrelic.com> #13Jan 23, 2024 05:22PM

it is still happening with AGP version 8.0.2 and Gradle version 8.0.

sp...@google.com <sp...@google.com> #14Jan 23, 2024 06:33PM

Re: #13, are you using enableV1Signing and/or enableV2Signing? If not, can you try with those instead of the deprecated v1SigningEnabled and/or v2SigningEnabled?

el...@gmail.com <el...@gmail.com> #15Jul 11, 2024 12:52PM

I'm using both enableV1Signing/enableV2Signing and v1SigningEnabled/v2SigningEnabled, and I'm still having the same issue where the APK is only signed with V2 and not with V1. I tried this on AGP 8.1.1 and 8.5. Min sdk version is 28.

This is blocking distributing our app through a platform that only accepts V1 signed APKs.

je...@google.com <je...@google.com> Jul 11, 2024 01:42PM

Status: Assigned (reopened)

sp...@google.com <sp...@google.com> #16Jul 11, 2024 07:05PM

Re: #15, I'm not able to reproduce the issue. Can you please give more information so I can reproduce it?

ch...@gmail.com <ch...@gmail.com> #17Jul 11, 2024 07:35PM

Comment has been deleted.

Message last modified on Jul 11, 2024 07:35PM

el...@gmail.com <el...@gmail.com> #18Jul 11, 2024 07:35PM

How are you verifying the signing on the apk? When I use apksigner with the configuration I mentioned, it says that V1 signing is not verified and only V2 is. I followed the recommendation of a StackOverflow thread where it mentions that apksigner is giving the wrong output, and that jarsigner can verify that the apk is indeed signed with V1. I tried with jarsigner and it confirmed that.

I'm not completely sure what to trust, but maybe that's a clue to the problem.

I'm not sure what other information could be useful. My target and compile sdk is 34.

sp...@google.com <sp...@google.com> #19Jul 12, 2024 03:03AM

Can you try running with the --min-sdk-version=23 flag? Something like this:

apksigner verify --verbose --min-sdk-version=23 /path/to/apk

el...@gmail.com <el...@gmail.com> #20Jul 12, 2024 08:15AM

Nice, now it does return true for V1 signing.

I understand the usage of this flag for signing the APK, but for verifying it seems strange to use it, doesn't it? I'd expect apksigner to be able to recognize all the signing versions applied to the APK without providing it with this flag, especially that my minimum version is not 23.

sp...@google.com <sp...@google.com> #21Jul 12, 2024 05:09PM

Reassigned to ma...@google.com.

I understand the usage of this flag for signing the APK, but for verifying it seems strange to use it, doesn't it? I'd expect apksigner to be able to recognize all the signing versions applied to the APK without providing it with this flag, especially that my minimum version is not 23.

I agree it's undesirable that it prints Verified using v1 scheme (JAR signing): false without the --min-sdk-version=23 flag in this case. Seems like it should either say that it didn't attempt to verify it or should just try to verify it without that flag.

Matt - do you know if this behavior is intentional (or do you know the right person to ask?)

ma...@google.com <ma...@google.com> #22Jul 12, 2024 05:21PM

Reassigned to mp...@google.com.

Over to Mike, as he is much more familiar with the individual schemes than yours truly.

mp...@google.com <mp...@google.com> #23Jul 12, 2024 08:12PM

apksigner verify is intended to perform APK signature verification similar to how it would be verified by all Android platform releases. Since APK signature scheme V2 support was added in SDK version 24, when an APK has minSdkVersion 24, the platform would not verify the V1 signature since the V2 signature would be sufficient for the install, so the output reports that a V1 signature was not verified. Explicitly setting a minSdkVersion for the verification is the intended workaround for this behavior since this will show how the APK would be verified if it could be installed on platform releases earlier than its declared minSdkVersion. While not as common, similar behavior can also be seen when an APK has a declared maxSdkVersion (or one is specified with the --max-sdk-version parameter; specifying a value < 28 will cause the verification to skip V3+ signature verification.

While this behavior is working as intended, the output can still be confusing, even if it does reflect how verification would be performed on all platform versions. I'll evaluate if changing this behavior to verify and display all contained signature schemes (even those that may not be verified due to the min / max SDK version declared in the APK) may have an effect on tests and other clients.

el...@gmail.com <el...@gmail.com> #24Jul 12, 2024 09:18PM

Thanks a lot everyone for your prompt responses! I'm glad we figured this out.

My last two cents: I feel like the usage of the --min-sdk-version=23 for verifying is still not intuitive for the purpose of checking all applied signing versions of an APK. I think tweaking the output is a good idea. And also maybe it would make sense to add another explicit flag for checking all signing versions and abstract the sdk version conditions.