> it took them almost a year to add support for 64 bit in APK
While the author's confusion is understandable, because most of the people posting in the linked Github issue have the same confusion, it's always been possible to build a 64-bit APK (and a 32-bit APK). The linked issue is actually about building a single "fat" APK with both 32-bit and 64-bit native libraries in it, which Google Play Store then repackages to have just the needed library for the device it's being downloaded to.
Shipping two separate APKs has always been possible and gives the same end result for just a little more build process work, which is (/should be) automated anyway.
I've been shipping an app like this for some time now, and it's really not a hardship in any way, certainly not one that justifies the amount of hand-wringing in that Github issue.
What was the holdup, though? This should have been almost a trivial feature to implement (just make an APK with multiple .so files in separate directories).
It must have been either low priority (except the Play Store has been strongly encouraging fat binaries for some time now) or there were additional complications (which makes me more suspicious about the stability of the framework).
Maybe low priority / insufficient resources, or the issue didn't get triaged and brought to the attention of the right person to fix it quickly enough. The fix wasn't complicated at all once it was eventually in, so I don't think it was any deep issue with the framework.
While the author's confusion is understandable, because most of the people posting in the linked Github issue have the same confusion, it's always been possible to build a 64-bit APK (and a 32-bit APK). The linked issue is actually about building a single "fat" APK with both 32-bit and 64-bit native libraries in it, which Google Play Store then repackages to have just the needed library for the device it's being downloaded to.
Shipping two separate APKs has always been possible and gives the same end result for just a little more build process work, which is (/should be) automated anyway.
I've been shipping an app like this for some time now, and it's really not a hardship in any way, certainly not one that justifies the amount of hand-wringing in that Github issue.