Auth: add package override support to getTokenWithAccount (#3278)

[vijay12481248-lab]

Mirrors the override logic from AccountAuthenticator.getAuthToken into AuthManagerServiceImpl.getTokenWithAccount so that apps calling this path directly (e.g. patched YouTube flavors) also benefit from package overrides, fixing UNREGISTERED_ON_API_CONSOLE errors.

[matteozanettii]

Hi @vijay12481248-lab , few observations regarding the implementation:

1. Certificate Selection: The logic uses certs.get(0), assuming the first certificate is the target. Have you considered edge cases with APK Signature Scheme v3 where key rotation might introduce multiple certificates?
2. SHA-1 Usage: I noticed SHA-1 is used for authManager.setPackageSignature. While I assume this is a legacy requirement for the Auth servers, can you confirm if this is strictly necessary instead of moving to SHA-256?
3. Magic Strings: There are several hardcoded strings like "NeedPermission", "1", and specifically "delegatee_user_id". Extracting these into constants would prevent future typos and improve overall maintainability.
4. Broad Exception Catch: The catch (Exception e) block when setting the override signature is quite broad. It might be safer to catch specific exceptions like NoSuchAlgorithmException to prevent swallowing unrelated errors.

[vijay12481248-lab]

Hi @vijay12481248-lab , few observations regarding the implementation:

1. Certificate Selection: The logic uses certs.get(0), assuming the first certificate is the target. Have you considered edge cases with APK Signature Scheme v3 where key rotation might introduce multiple certificates?
2. SHA-1 Usage: I noticed SHA-1 is used for authManager.setPackageSignature. While I assume this is a legacy requirement for the Auth servers, can you confirm if this is strictly necessary instead of moving to SHA-256?
3. Magic Strings: There are several hardcoded strings like "NeedPermission", "1", and specifically "delegatee_user_id". Extracting these into constants would prevent future typos and improve overall maintainability.
4. Broad Exception Catch: The catch (Exception e) block when setting the override signature is quite broad. It might be safer to catch specific exceptions like NoSuchAlgorithmException to prevent swallowing unrelated errors.

[vijay12481248-lab]

Thanks for the review!

1. Certificate Selection (certs.get(0) & v3 key rotation)
certs.get(0) is intentional — it returns the original/leaf cert, which is what was recorded when the override permission was granted (stored as a SHA-256 digest in account userData). Using a newer rotated cert would break existing grants. This mirrors the same logic in AccountAuthenticator.getAuthToken for consistency.

2. SHA-1 in setPackageSignature
Yes, SHA-1 is required here — it's a legacy format expected by Google's Auth servers for package identity lookup, not used for any internal security decision. The authorization gate above it already uses SHA-256. Switching to SHA-256 for setPackageSignature would likely cause server-side auth failures since we don't control that API contract.

[matteozanettii]

Suggested change

	authManager.setPackageSignature(PackageManagerUtilsKt.toHexString(PackageManagerUtilsKt.digest(overrideCert, "SHA-1"), ""));
	authManager.setPackageSignature(PackageManagerUtilsKt.toHexString(PackageManagerUtilsKt.digest(overrideCert, "SHA-1"), ""));
	if (!effectivePackageName.equals(packageName)) {
	// SHA-1 is used here intentionally: Google's Auth servers require the package
	// signature in SHA-1 hex form for legacy compatibility. This is not used for
	// security decisions — the authorization check above uses SHA-256.
	byte[] overrideCertificateBytes = extras.getByteArray(AccountAuthenticator.KEY_OVERRIDE_CERTIFICATE);
	CertData overrideCert;
	if (overrideCertificateBytes != null) {
	overrideCert = new CertData(overrideCertificateBytes);
	} else {
	// See comment above about certs.get(0) and APK Signature Scheme v3
	List<CertData> certs = PackageManagerUtilsKt.getCertificates(context.getPackageManager(), packageName);
	overrideCert = certs.isEmpty() ? null : certs.get(0);
	}
	if (overrideCert != null) {
	authManager.setPackageSignature(PackageManagerUtilsKt.toHexString(PackageManagerUtilsKt.digest(overrideCert, "SHA-1"), ""));
	}
	}

[matteozanettii]

from copilot: Copilot said: I'll help you find a solution for
I'll help you find a solution for this failing job. Let me start by retrieving the job logs.Now let me examine the failing file:## Solution

The build is failing due to a Java compilation error in AuthManagerServiceImpl.java at line 221. The issue is an unreachable exception handler: the code catches NoSuchAlgorithmException, but the only method that could throw it (PackageManagerUtilsKt.digest()) is never actually called in the try block when an override certificate is not present.

Root Cause
Looking at lines 208-223, the try-catch block attempts to handle NoSuchAlgorithmException, but the exception can only be thrown by PackageManagerUtilsKt.digest() at line 219. However, line 219 is only executed if overrideCert != null (line 218). If overrideCert is null, the try block completes without any code that throws NoSuchAlgorithmException, making the catch clause unreachable.

Fix
Remove the try-catch block since the exception handling is not needed. The code is already defensive by checking if overrideCert != null before calling the digest method: