Unable to publish an App Bundle because of the Google Play 64-bit requirement

I'm encountering a persistent 64-bit error when trying to publish an update for my Android application's App Bundle on Google Play.

Technical Setup:

• Project Type: Standard Kotlin project for Android
• Android build tools version: 34.0.0
• minSdkVersion: 24
• compileSdkVersion: 34
• targetSdkVersion: 33
• Android Gradle Plugin version: 8.4.1
• Android Gradle Wrapper version: gradle-8.6-bin.zip

Context:

• I've meticulously followed Google's official documentation for App Bundle publishing, specifically regarding 64-bit library requirements.
• I create the App Bundle with the following Gradle task bundleRelease.
• My project successfully runs within a 64-bit simulator inside my IDE.
• I've verified that the three native libraries within the App Bundle's "lib" folder have indeed their 64-bit (arm64-v8a and x86_64 architectures) version using the file command.
• I confirm I do not utilize Unity or any Native Development Kit (NDK).
• There is no RenderScript usage.
• I have tried without success ndk.abiFilters 'armeabi-v7a','arm64-v8a','x86','x86_64'.
• I have read other SO posts like this without any success.

I've interacted with Google Play support, but they were unable to resolve the issue and closed the ticket, stating they couldn't provide a more specific answer. Any insights or suggestions to resolve this issue would be greatly appreciated.

Android automatically considers any APK as only working in a 32-bit environment if it contains a file with the extension ".bc" (RenderScript) -- This is documented here: https://developer.android.com/games/optimize/64-bit#renderscript-and-64-bit

You seem to be using an obfuscator which changes the name of some files. One of the files under directory META-INF/ does not have an extension but the name of the file was renamed to com.package.name.Bc <-- Android (and thus Play) thought this was a RenderScript file because of the seemingly extension ".bc" and thus flagged the AAB as being 32-bit regardless of the native libraries available.

A re-run of the obfuscator after having commented one line of code led to a different random file name com.package.name.Cc and that's why the other AAB worked.

Granted, it would help debugging if the error message included the reason why it's not 64-bit compliant... :/