Edit:
As Per @marbarfa 's answer, this seems related to 3rd party libraries. Read his answer and comment for full explanation.
Thanks marbarfa !
Using the new Google Play Developer console, I am facing a strange situation: I recently switched to Facefbook's fresco image loading library and this could maybe explained my problem.
(possibly similar problem reported here: Google play, publishing app update, issue with 'Native platforms' )
In the frame of promoting a beta build to production, I encountered this:
On the new Google Play console, under Release Management / App release, when in "New release to production (Promoting from beta 2.2.0)" I see this that
"Native platforms" value changed from arm64-v8a, armeabi, armeabi-v7a, x86, x86_64 to none!
Google Play Console page code excerpt for "previous APK":
Differentiating APK details
Native platforms
arm64-v8a, armeabi, armeabi-v7a, x86, x86_64
Google Play Console page code excerpt for "new APK" (the Beta one with Facebook's Fresco):
Differentiating APK details
Native platforms
none
I updated all my (10!) apps and it seems to be OK (number of supported devices is the same, i.e., 11434), but still, I am not really comfortable with not understanding what exactly happened.
Can someone explain please?
Thanks!
I'll try to explain the problem as simple as possible:
The problem seems to happen when you are splitting for some architectures (e.g.: arm64-v8a, armeabi, armeabi-v7a, x86, x86_64) but you don't have any native implementation on those architectures.
For example, in my case was mips and mips64.
The play store seems to recognize the architecture supported by an apk based on the lib/$arch folder. So, if the apk lacks this folder, the playstore shows "none" as "native platform" (you can check this by unzipping the apk).
The problem is that "none" is interpreted as "all architectures are supported" and then the apk will be downloaded based on the versionCode.
If you have an apk with "native platform" as "none" with higher versionCode than another that do has a native implementation, the user will end up downloading the apk with higher versionCode. Depending on the app or configuration, this will just work fine, or not.
The problem is generated on how gradle splits the apks and you have to be careful on how you define the versionCode for your splits.