Harman AIR SDK 33 Beta, x64-apk


#1

So Harman released their first version of the AIR SDK.

Did anyone successfully create a x64-apk with the included adt?


#2

Link ?..


#3

ForeverMacro Links are sent in the emails to everyone, who subscribed

aidemR didn’t have time to check, first have to prepare my game build for the contest submission (deadline is 30th June)


#4

Yes. I am using the latest version (33.0.0.175) and using both the command line and now the latest IntelliJ.


#5

hi, could you please tell me where to subscribe?


#6

Email
adobe.support@harman.com


#7

thanks for the reply. did send an email, but never received any reply


#8

Can you give us an example of the command line?

Do youe have the Early Access Program of IntelliJ or the latest update?

Because i installed the last update and the option is not included.


#9

Furthermore, the new version (33.0.0.175) does not include Flex components, even if the name refers to it.
When i integrate the new SDK in IntelliJ, then appears a warning that my app could not be a Flex/AIR because of the missing components.
When i want to package via command line, i get the same error.

Am i right or do i miss something here?


#10

maybe you should provide informations about your environment
and the command-line you are using


#11

“/Users/user/Library/Application Support/JetBrains/Toolbox/apps/IDEA-U/ch-0/191.7479.19/IntelliJ IDEA 2019.1 EAP.app/Contents/jdk/Contents/Home/jre/bin/java” -Dapplication.home=/Users/user/SDKs/AIRSDK_33 -Dfile.encoding=UTF-8 -Djava.awt.headless=true -Duser.language=en -Duser.region=en -Xmx512m -jar /Users/user/SDKs/AIRSDK_33/lib/adt.jar -package -target apk-captive-runtime -arch armv8 -storetype PKCS12 -keystore /Users/user/flash/64_ANES/tuaruaWin.p12 -storepass XXXXXXX /Users/user/flash/Google-Maps-ANE/example/bin-release/device/mobile_Android_Device.apk /Users/user/flash/Google-Maps-ANE/example/bin-release/device/GoogleMapsANESample-app.xml

Yes I have access to the EAP. It shows up in the JetBrains Toolbox

I don’t use Flex so can’t help you there.


#12

I am using IntelliJ IDEA Ultimate (2019.1.3).

This version isn’t yet compatible with the new AIR/Flex SDK. Hopefully they release the new version in July, as they announced.

I used the commandline which IntelliJ generates and made small changes.
Even tried to create the command line manually but resulted in the same error.

I will now try it with the new updated SDK and give you information if it was successful or not.


#13

I successfully created a x64-apk but couldn’t run it on a x64-device.

Furthermore i am not sure how you can support both, x32- and x64- in one apk.
Otherwise you have to make two sepereated packages.


#14

:thinking: Reading the rules of Google/PlayStore, I was also in doubt about this: Are we ever going to have to send two APKs? …one 32bit and another 64? …or one made in 64bit automatically also works for 32bit?


#15

at the compiler level you always compile to one CPU architecture

but then in your app file layout you can have one or more architecture

.
|_ lib
     |_ armeabi-v7a     <-- ARM 32-bit
     |_ arm64-v8a       <-- ARM 64-bit
     |_ x86             <-- Intel 32-bit
     |_ x86_64          <-- Intel 64-bit

see : Android - Support 64-bit architectures

now to distribute it as an APK, there is different way of doing

  1. you can distribute multiple APK
    see Android - Multiple APK support

By publishing your application with multiple APKs, you can:

  • Support different OpenGL texture compression formats with each APK.
  • Support different screen sizes and densities with each APK.
  • Support different device feature sets with each APK.
  • Support different platform versions with each APK.
  • Support different CPU architectures with each APK (such as for ARM or x86, when your app uses the Android NDK).
  • Optimize for entry-level devices such as those running Android (Go edition).

and

How multiple APKs work

The concept for using multiple APKs on Google Play is that you have just one entry in Google Play for your application, but different devices might download a different APK. This means that:

  • You maintain only one set of product details (app description, icons, screenshots, etc.). This also means you cannot charge a different price for different APKs.
  • All users see only one version of your application on Google Play, so they are not confused by different versions you may have published that are “for tablets” or “for phones.”
  • All user reviews are applied to the same application listing, even though users on different devices may have different APKs.
  • If you publish different APKs for different versions of Android (for different API levels), then when a user’s device receives a system update that qualifies them for a different APK you’ve published, Google Play updates the user’s application to the APK designed for the higher version of Android. Any system data associated with the application is retained (the same as with normal application updates when using a single APK).

and then read carefully Rules for multiple APKs


  1. merge different architectures into 1 APK

an APK is just a zip container, you can generate 2 APKs, one with ARM 32-bit, another one with ARM 64-bit, and then merge the different files into one APK

I would not give too much details into that but let’s just say it is “advanced”, more prone to errors etc.

  1. produce an Android App Bundle instead of an APK

see Android App Bundle

not sure if this is compatible with the way AIR produce APK, and never tried that way