Titanium JIRA Archive
Appcelerator Community (AC)

[AC-6357] Error: This release is not compliant with the Google Play 64-bit requirement

GitHub Issuen/a
TypeBug
Priorityn/a
StatusClosed
ResolutionInvalid
Resolution Date2019-10-03T16:36:53.000+0000
Affected Version/sAppcelerator Studio 4.5.0
Fix Version/sn/a
ComponentsTitanium SDK & CLI
Labels64bit, android, playstore
ReporterThomas Neerup
AssigneeShak Hossain
Created2019-09-05T08:21:32.000+0000
Updated2019-12-12T15:29:48.000+0000

Description

Not able to upload Titanium App to Google play any more... I'm using sdk 8.1.1.. First i thought it was my modules that was the problem, but efter removing all modules, I stille get the following error when I upload to Google Play, see atached file. I know google upped the requirements last month. Can anyone verify that Appcelerator can upload apps to Google play? Any advice to what I might do wrong? I tried opening the APK in Googles APK Analyzer and verified that it contained lib/arm64-v8a folder with all *.so files /Thanks

Attachments

FileDateSize
image002.png2019-09-05T08:18:04.000+000061346
PastedGraphic-1.png2019-09-06T06:19:28.000+000073430

Comments

  1. Joshua Quick 2019-09-05

    It sounds like "x86" .so libraries are being bundled into your app. By default, Titanium "production" built apps only include the "armeabi-v7a" and "arm64-v8a" architectures only, which are 32-bit and 64-bit respectively. Titanium "production" builds do not include "x86" by default... unless you've modified your "tiapp.xml" to include it. Check your "tiapp.xml" file. Do you have the following <abi/> element defined? If so, the "x86" part is the cause of the issue. My recommendation is to completely *+remove+* the <abi/> element from your "tiapp.xml" and let Titanium do the default handling mentioned above. 
       <?xml version="1.0" encoding="UTF-8"?>
   <ti:app xmlns:ti="http://ti.appcelerator.org">
   	<android xmlns:android="http://schemas.android.com/apk/res/android">
   		<abi>armeabi-v7a,arm64-v8a,x86</abi>
   	</android>
   </ti:app>
  2. Thomas Neerup 2019-09-05

    Hi Joshua My APK does not include the x86 Library and my tiapp.xml does not include the Tag Is there anything Else I can check? /Chers
  3. Joshua Quick 2019-09-05

    When you unzip your APK file, check that you have the folders within it: ./lib/arm64-v8a ./lib/armeabi-v7a If you have any other folders under "lib" such as "x86", then that's the cause of the problem. Note that you can easily unzip your APK file by changing its extension to .zip and then double clicking it. An APK is really just a zip file.
  4. Thomas Neerup 2019-09-05

    My lib folder looks exactly like that, no other subfolders.
  5. Joshua Quick 2019-09-05

    And do both folders contain the same files?
  6. Thomas Neerup 2019-09-06

    Yes both contains the same files... I attached an image from Android APK Analyser !PastedGraphic-1.png|thumbnail! Is there any other information I can provide?
  7. Thomas Neerup 2019-09-13

    I'm getting a little desperate here... Can anyone verify that Appcelerator Studio can upload apps to Google play after Google upped their requirements in August?
  8. John Staunton 2019-09-18

    Yes, I've managed to upload an app since the requirements change. Dropped the abi tag and it worked. Unfortunately, I have one user who uses an x86 machine and the app crashes on launch for him if I don't specify the abi. So now I've to build a separate non-Play store version for him every time I update...
  9. Joshua Quick 2019-09-18

    Sorry about the late response. We built an APK with Titanium 8.2.0 and uploaded to Google Play in the past week to re-test it (in case anything has changed on Google's end). It uploaded fine. There was no error. And I know this is working for other Titanium app devs too (the whole community would be in an uproar if there were any 64-bit problems). So, I'm not sure why you're having this problem and no one else is. Your unzipped APK "looks" fine. Would you mind sharing your "tiapp.xml" file?
  10. Thomas Neerup 2019-09-18

    This is how my tiapp.xml looked like before I removed all modules. I can't upload with or without mu modules.. Hope this helps. If more info is required ... just let me know... http://ti.appcelerator.org"> dk.eg.mobile.crosspad Egcrosspad 1.8.06 EG A/S http://www.eg.dk undefined 2019 by EG A/S appicon.png false true false 20190904-0900 true dp inhousebuild 20190904-0900 UISupportedInterfaceOrientations~iphone UIInterfaceOrientationPortrait UISupportedInterfaceOrientations~ipad UIInterfaceOrientationLandscapeLeft UIInterfaceOrientationLandscapeRight UISupportedExternalAccessoryProtocols com.datecs.linea.pro.msr com.datecs.linea.pro.bar UIRequiresPersistentWiFi UIPrerenderedIcon UIStatusBarHidden UIStatusBarStyle UIStatusBarStyleDefault UIBackgroundModes remote-notification fetch external-accessory NSFaceIDUsageDescription To provide smooth login experience NSLocationAlwaysUsageDescription To provide you with services based on your location NSLocationWhenInUseUsageDescription To provide you with services based on your location NSContactsUsageDescription To use details about your contact where it is relevant NSCameraUsageDescription To provide you with the ability to take photos and camera based barcode scanning NSCalendarsUsageDescription To provide you with services based on your calendar NSPhotoLibraryUsageDescription To use your photos where it is relevant NSMicrophoneUsageDescription To provide you with the ability to make soundrecordings and voice control NSAppleMusicUsageDescription To break the silence CFBundleURLTypes CFBundleURLName dk.eg.mobile.crosspad CFBundleURLSchemes egcrosspad http://schemas.android.com/apk/res/android"> ti.cloud ti.map ti.map ti.touchid ti.cloudpush ti.cloudpush ti.touchid com.mirasense.scanditsdk com.mirasense.scanditsdk dk.eg.crosspad.linea.scanner ti.paint ti.paint ti.imagefactory ti.imagefactory com.omorandi bencoding.android.tools ti.draggable true true true 8.1.1.GA ti.alloy https://secure-identity.cloud.appcelerator.com https://api.cloud.appcelerator.com https://secure-identity.cloud.appcelerator.com https://api.cloud.appcelerator.com
  11. John V Pataki 2019-10-02

    I'm curious if there was any new findings for this issue. This issue has stopped our update of an existing app as well that has always been built to include both 64bit (arm64-v8a) and 32bit (armeabi-v7a) libraries since long ago when that was originally introduced as a requirement in Titanium. From initial researching online, something changed in late August in terms of Google Play's review process and now this error message is shown where it wasn't before. We've tried upgrading Ti SDK to 8.2.0.GA and bumping minimum Android version to API 28 and still get the error message. Inspecting the APK for 64bit libraries using this method https://developer.android.com/distribute/best-practices/develop/64-bit#apk-analyzer does show a copy of each library the app uses in each of the two folders arm64-v8a and armeabi-v7a. Is there a way to force Titanium to ONLY build with 64bit libraries and not include any 32bit at all (mainly to test a theory that it is the 32bit libraries that are causing this error)? The text of the error message in Google Play is {noformat} Error This release is not compliant with the Google Play 64-bit requirement The following APKs or App Bundles are available to 64-bit devices, but they only have 32-bit native code: 11. Include 64-bit and 32-bit native code in your app. Use the Android App Bundle publishing format to automatically ensure that each device architecture receives only the native code it needs. This avoids increasing the overall size of your app. Learn More {noformat}
  12. John V Pataki 2019-10-02

    Ah ha - I think I just figured it out. I noticed the difference between the error message I posted in my comment above and the error message from the original poster and it was the number at the end of the this line: {noformat} The following APKs or App Bundles are available to 64-bit devices, but they only have 32-bit native code: 11. {noformat} That number I just figured out is referring to an old version of an APK (before we switched to 64bit) that was "retained" for the app even though it wasn't the main APK ... and Google Play's review process was throwing the error for that APK version only. I had no idea that was even a version code number from their clumsily worded error message until I noticed that the original poster's message had a different number. I had thought it was an error code number actually to be used in referencing the error. So, I returned to the app release configuration and "deactivated" that particular APK (version code 11 in this case) for the app and re-ran the "Review" process and now that error message is gone! I hope this helps someone else.
  13. Joshua Quick 2019-10-03

    Oh interesting... So, just to be clear, Google Play was complaining about a previously uploaded APK? The APK you are currently uploading is passing fine, right?
  14. John V Pataki 2019-10-03

    Yes - sort of, not just that it was previously "uploaded", but specifically "retained". Google Play has this ability to "retain" older APK files for an app, I guess so that devices that can't use the newer one still have something to download that is compatible. This section on the app release setup {noformat} Android App Bundles and APKs to retain These app bundles and APKs from your previous release will continue to be served in the Google Play Store. {noformat} But something apparently changed with Google's 32bit acceptance, per their timeline referred to on this page https://android-developers.googleblog.com/2019/01/get-your-apps-ready-for-64-bit.html so even an older APK "retained" for older use purpose, must now also be 64bit. So once I "disabled" the previously "retained" APK and there was only the most recent APK, the error went away.
  15. Joshua Quick 2019-10-03

    Got it. Thanks for the info. I'm glad it's resolved.
  16. John V Pataki 2019-10-03

    [~jquick] To be clear, I am not the original author of the issue, so might want to confirm if my resolution solves it for [~thomas.neerup@eg.dk] as well.
  17. Thomas Neerup 2019-10-03

    This is Greatest news. Problem Solvej. Thank you...
  18. Carlos Henrique Zinato 2019-12-12

    I had the same today and @John V Pataki solution was exactly what I needed. I had this app on stores for 5 years and a very old APK with the error message, in my case, number 4. Thanks for figuring it out and I hope that other people with the same problem see this message =)

JSON Source