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

Question

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.

Answer 1

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... :/

Answer 2

Believe it or not, after a long divide and conquer exercise comparing the ongoing version to a former 64 bit compliant one, this is what I've found out:

NOTE: Code has been simplified at max

App Bundle A - Google Play 64 bit compliant

    // Invoked from MainApplication
    val deviceInfo = AndroidUtils.addDeviceInformationHeader()
    println(deviceInfo)
}

object AndroidUtils {
    @JvmStatic
    fun addDeviceInformationHeader(): String {
        return StringBuilder().toString()
    }
}

App Bundle B - NON Google Play 64 bit compliant

    // Invoked from MainApplication
    // val deviceInfo = AndroidUtils.addDeviceInformationHeader()
    // println(deviceInfo)
}

object AndroidUtils {
    @JvmStatic
    fun addDeviceInformationHeader(): String {
        return StringBuilder().toString()
    }
}

Nothing else changes in the project from App Bundle A to B. Nothing at all. Both App Bundle A and B were generated from the exact same Docker-based environment. Each build starts from a blank checkout with only the code difference you see in A and B. The build itself executes the bundleRelease Gradle task.

While the cause remains unclear, I'm happy to share more information with Google in case they help improve the clarity or accuracy of their 64-bit compliance checks.