Play App Signing is how every new app is published: you sign the bundle with the upload key, Google checks it, builds the split APKs and signs them with an app signing key that never leaves Google (the diagram in Play App Signing). For new apps Google now generates what its help pages call "quantum-ready, hybrid" keys, a classical RSA 4096-bit key plus a post-quantum ML-DSA-65 key, and a separate classical key for older Android versions. apksigner shows what BookNest's own release carries:
apksigner verify -v --print-certs app/build/outputs/apk/release/app-release.apk \
| grep -E "Verified|Signer #1 certificate (DN|SHA-256)"Verified using v1 scheme (JAR signing): false Verified using v2 scheme (APK Signature Scheme v2): true Verified using v3 scheme (APK Signature Scheme v3): false ... Signer #1 certificate DN: CN=BookNest Upload, O=Example Books, C=MY Signer #1 certificate SHA-256 digest: 4a8f456ef11287e2a1c017a5f3a5458c68cb098822a69795af47df903 da0563c
AGP signed with v2 alone: v1 (JAR signing) only matters below Android 7.0, and BookNest's minSdk is 26. Newer schemes add key rotation (v3, v3.1) and incremental installs (v4); Play picks the schemes for the APKs it signs, v3.2 for the hybrid keys (Play App Signing). That re-signing is the native-specific trap: everything that pins your app's certificate must list the app signing key's SHA-256 (in the Play Console 1 under Protected with Play, on the Play app signing page), not the upload key's 4a8f...563c. That means assetlinks.json for verified App Links (Deep Links) and passkeys (Credentials and Passkeys), OAuth client IDs for Sign in with Google, and API keys restricted to an Android app. While you test, list both digests: the upload key's for sideloaded builds, the app signing key's for everything Play delivers.