Hello Rob,
All i can do is to appreciate the work you and your team is doing and also buying some yearly bundles from marketplace.
Please keep the great work going. I hope Corona will support 64 Bit and make a good comeback for its users.
I know this is hard time for all of us but we have to clear this or please try to take extension just like Unity did.
@sahil19.sindh, I don’t follow your message. If you used something like Google Translate, it didn’t come across too well. If you’re using English and slang, perhaps try to avoid the slang to keep the meaning of your post clear.
Rob
He is saying that he appreciates the hard work being put in by Corona’s staff towards meeting the 64-bit android requirement and that he tries to do his bit by subscribing to plugins and other paid corona services to show his support
He also acknowledges how this is a testing period for the corona team and developers alike and expresses optimism and faith in your ability to continue to deliver a fine product to your users
Didn’t see any slang to be fair
Quick update!
While the builds are not published, you can download:
http://developer.coronalabs.com/sites/default/files/corona/2019.3495/Corona-2019.3495.dmg
http://developer.coronalabs.com/sites/default/files/corona/2019.3495/Corona-2019.3495.msi
These builds have 64-bit Google turned on by default. Most everything should be working except for issues with LuaSec (needed for Web Sockets) and is tied to OpenSSL. The GameSparks plugin uses this as well as the Websockets plugin. We are working to fix it.
You should be able to publish with these builds assuming the plugin issues above are not needed. There may still be some third-party plugins that need updated.
Once we address the LuaSec issue, we are going to move on to Android API 28 support (also an August’ish deadline) and updating all the various google dependency plugins. They should “work”, but many are several versions behind and it will take time for us to update them all.
With this version, you get .aab (Android App Bundle) files created alongside your .apk files. .aab files will address the annoying “Your app isn’t optimized” warning that the Google Play developer console has been giving lately. To use .aab files, you must opt-in to Google’s new way of signing apps (.aab’s are unsigned). This may involve you having to update your android keystore files to a more modern format before uploading your keystore to Google where they will handle signing the apps. We’ve discouraged this in the past, but it’s required to use App Bundles, so it’s time to move forward. AAB files allow Google to produce smaller files to download for your users. A 16mb file produced more like an 8mb file for end users to download.
There is an AndroidResources folder along side the main.lua file. Inside that folder is a res folder and a bunch of Android mipmap-* folders. These folders contain the icons for Android apps going folder. Instead of Icon-xxxhdpi.png in main.lua, you move this folder to the mipmap-xxxdpi/ folder and rename it to ic_launcher.png. You will need to do this with all the the Icon-*dpi.png files…
This system also supports Adaptive Icons. If you do a File->New Project it will create a functioning AndroidResources tree that you can copy to your project and then update the appropriate files. We are working on updating the build guide to include information on this. These default icons are setup to have a transparent PNG information on foreground image and a solid color for the background image (look at the values.xml file). You can use an image as the background image, but that’s beyond what I want to go into in this post.
This should still be considered beta, but we’ve had really good testing and we know where specific problems lie. You should be able to start updating your apps as long as the listed issues are not a concern. And as always TEST TEST TEST before putting an app out for your users.
Rob
Oh, feel free to leave feedback here, or join the community Slack (https://coronalabs.com/slack) and after your invitation is sent and accepted join the #Android64 channel.
I’ve refrained from posting to this thread until now - quietly confident that 64bit support would land before the deadline.
This update sounds great. I totally realise this is all beta and until I get chance to test myself, I’ve no idea how stable it actually is, but 64bit + app bundles + adaptive icons all in one? Brilliant!
Thanks for the hard work, especially while facing a barrage of questions and complaints. I don’t even want to know what it’s been like in the Coronalab offices these last couple of months. I’ve worked through enough stressful deadlines and demanding clients in my time to appreciate this won’t have been a fun environment.
I’m sure some kind of an FAQ / upgrade guide is on the way, but is there anything we need to do to make our plugins compatible?
Wow, great news, thank you Corona team!
… now who wants to be first to test it in Prod 
Great job. I am very impressed
@Rob, for those of us who don’t use Native, is there a way to get a Daily Build Beta and build normally? If not, what’s the ETA?
If your plugins are using Java only, they shouldn’t need updated. For .so files, you need to include the arm64 architecture. But I would suggest you ask this question in the Slack channel where Engineering is hanging out for now.
@troylyndon, the links I provided include a fully functional simulator to build with. No need to use native. The builds are not showing up on the daily build page for now. You will need to use the links I provided above to directly download the builds. I think we want to knock out the OpenSSL/LuaSec bug before we have it show up in daily builds again.
What from my post above lead you to believe you needed native?
Rob
Does this affect the following functions / modules in any way?
network.getConnectionStatus
network.request
require(“socket”)
require("socket.url)
Our apps are using these to send and receive data or to test if there is an internet connection.
Thank you @Rob, that was really great to hear.
I have a qn which will surely help a lot of developers, Can we make builds with plugins say Admob, Splash control, Notifications.v2 and gpgs.v2?
This will not be a problem for now being. We understand it will take time to update everything but as these were not in the list so i was curious to know.
WebSockets are not the same as HTTP web requests or even straight up socket communications. All of the things you mentioned above should be working.
Rob
Hello Rob, I have installed the new release 2019.3495 that I have downloaded from the link you have indicated.
To compile in 64 bits you have to add something to the project configuration? or this version already compiles automatically in 64 bits?
That’s a question with two answers. You can build against those four plugins and your app will build and run as they do today. However, at least three of those plugins have currently reported issues against them. We have not addressed any current bugs/issues with those plugins. We have to finish this, then update to Android SDK 28 and turn our attention to the bugs.
Rob
64-bit should be on by default with this build. You can check by unzipping the .apk file (it’s just a .zip file with a different extension) and see both the arm7 and arm64 platforms inside… Another way you can check is it should also produce a .aab file in the same folder as the .apk.
Rob
Nice progress everyone!
I have successfully built with the new system - is there anything we can do to contribute to the test … or whatever?
@jaime9 you can test your apps and let us know if you see problems. It would be nice to get feed back, once posted to see if ANR/Crash rates go up or down or stay about the same.
@everyone, there was a small bug in yesterday’s daily build. Here are the links to the fixed version. Please download and use these instead:
http://developer.coronalabs.com/sites/default/files/corona/2019.3496/Corona-2019.3496.msi
http://developer.coronalabs.com/sites/default/files/corona/2019.3496/Corona-2019.3496.dmg
Rob