The 64-bit requirement on play store

Voted and commented !

We just received letter from Google saying that all our games will be unupdateable by August 1, 2019. This is getting really urgent now.

Did you also received this letters?

Edit:
Just saw a new post by Daniel in the Starling forum:
https://forum.starling-framework.org/d/21231-let-adobe-know-we-need-android-64bit/50

“I’ve sent another query to Adobe on this topic, as well, and I was told there’d be official (good!) news on this topic in just a couple of days, probably next week. I know, we’ve heard such messages already in the past, but it sounded very sure and sincere. So, please hang in there a little longer!”

So, there is hope :slight_smile:

well…

I replied that in February, and since then I only saw people losing their shit and spreading FUD

personally I’m not worried one bit

I really don’t see where is the problem here?

at worst, you’re not sure of the stability of your game and so you should push updates before that date

at best, you’ll get at the very least an AIR BETA to update the games to 64-bit by that time

stop reading the bullshit and conspiracy theory on adobe forums

I tried to reasonably talk to those guys, lol huge waste of time

now as soon as I see “Leo Kanel”, “ASWC”, “OMA2k” and the like
sorry but I flip the bozo bit, I don’t have time to waste on mental patient

so for the record, because my answer got “rejected by moderator”

when you see such message

Leo Kanel May 5, 2019 1:43 PM (in response to zwetan kjukov)

Well you know, on the opposite of what you do, I actually help devs both here and in the starling forum. Also contribute with as3 libs abd stack overflow. Also, once again on the exact opposite of you, I do have successfull apps for android and ios. I was forced to leave the tech as a professional.

Concerning your ignorant comments about not knowing the sdk, the issue is on the damn sharedprefs of air sdk. If i can fix it that easily without access to documentation and dev docs, the damn adobe team should have done it long before.

You always trying to defend them is not just pathetic but also reminds me of devs who once did an app with that sdk asdk and defend it like religion. Ignorant, low skilled, never progressing code monkeys.

Now either contribute something meaningful or leave.

when it come to “measuring dicks” contest , personal attacks and threats… well…

btw the message that got rejected is this one

zwetan kjukov May 6, 2019 12:28 AM (in response to Leo Kanel)


Now either contribute something meaningful or leave.

leaving? nah …

let me see… humm what do I see?

I see a Co-Organiser of a Google Developers Community Group from Athens
that come to an Adobe group telling us how AIR missed a release (according to him) and that’s a big red flag
how Adobe is stupidly handling the issue, how from now on the company he is working for will only use Flutter (google tech) and how AIR is only good for legacy apps …

so I’m curious now
during those google dev meetup do you guys discuss how to troll forum?
how does it work exactly?

have a great day :slight_smile:

I guess the moderator saw that as doxxing … anyway

those people do have an hidden agenda and I can guarantee you this is not for the good of AIR

that’s the more vicious kind of trolling, they make you think that they are on your side and then they blow up things from the inside

only one rule: do not feed the trolls, just ignore them

2 Likes

For the trollers :slight_smile:

“From: Adobe
Date: Mon, May 20, 2019 at 4:20 PM
Subject: RE: Adobe 64-bit for Google
Hi,
We’re aware of the 64-bit requirement and hope to have news for the community later this week or by mid next week at the latest.
Thanks,
Chris”

just relax kiddos… here is my source: https://github.com/Gamua/Adobe-Runtime-Support/issues/29

1 Like

so technically the source is user “@pis0” on the github of Gamua
that copy/pasted some text

2 Likes
  • Extensions: Google Play will continue to accept 32-bit only updates to existing games that use the following SDKs:
    • Corona Labs SDK - until August 2020
    • Adobe Air software and the AIR SDK - until August 2020
    • Unity 5.6.7 or older - until August 2021

Starting August 1, 2021:

  • Google Play will stop serving apps without 64-bit versions on 64-bit capable devices, meaning they will no longer be available in the Play Store on those devices.
  • This will include games built with Unity 5.6.x or older.>

:smiling_face_with_three_hearts: For everything to get better now, Harman could make AIR 33 totally free for everyone, until everyone migrates, and start enforcing their pricing policy, only from AIR 34.

1 Like

Extensions: Google Play will continue to accept 32-bit only updates to existing games

One word that is a bit worrying here is “games”. I’m about to release a non-game app using AIR. Hopefully, it will still qualify for the extension, and the choice of words here was a generalization / oversight.

Your new app will still disqualify for the extension as it is only applied to existing 32-bit apps on GP.

the addition of Adobe AIR in the list of exempted frameworks is one thing
but it is more due to Google wanting game developer to keep publishing games and updates
than anything else

to me it is not connected to the licensing of AIR 33

it would send the wrong message imho

Harman already modified their licensing based on the many feedbacks,
that said, they have always been clear about them taking over AIR SDK to make it a for profit project
which is good

they do have a free tier, with splash screen, which is free.

1 Like

How can I do now to make a new app with 64-bit Android?

HARMAN just sent AIR33 ready for use. Google Play accepts the apks created with it well.

where is it? any links?

see Latest Update for AIR 33 SDK

I having the same issue using this AIR 33 SDK. I´m using adobe Animate to generate the apps.

(upload://rY4HFlm8qxm2n2kjZoE2uSKnyLd.png) error2error

Could be many things

even if you compiled with the AIR 33.0.1.220 SDK
maybe you did not update your app XML?

eg.

<?xml version="1.0" encoding="utf-8" ?>
<application xmlns="http://ns.adobe.com/air/application/33.0">

try to follow Look for native libraries using APK Analyzer to see what is inside your APK

for 64-bit you want to look for arm64-v8a

1 Like

Thank you zwetan, I will try.

Just was about to ask about this. I’m using Flash Develop. I selected AIR 33 SDK in the Project Properties. Also in SetupSDK.bat I have set FLEX_SDK=D:\Tools\Air\33

When I have <application xmlns="http://ns.adobe.com/air/application/32.0"> in application.xml the game compiles well, runs well, and then I’m able to package it to both armv7 and armv8 using AIR33, and Google Play accepts these submissions.

But if I change it to <application xmlns="http://ns.adobe.com/air/application/33.0"> and compile the game, I have the black screen with text:

Starting AIR Debug Launcher with screen size '576x768:576x768'

(hint: edit 'Run.bat' to test on device or change screen size)

invalid application descriptor: Unknown namespace: http://ns.adobe.com/air/application/33.0
Press any key to continue . . .

However, the swf game compiles successfully with a log

Running process: D:\Tools\FlashDevelop\Tools\fdbuild\fdbuild.exe "D:\Dropbox (Personal)\_Gamedev\30_Spinner\Spinner-x64\Spinner-Android-x64.as3proj" -ipc e61c3ade-97bf-427c-b5c3-d03aa6fce05d -version "33.0.0" -compiler "D:\Tools\Air\33" -notrace -library "D:\Tools\FlashDevelop\Library"
Building Spinner-Android-x64
mxmlc-cli -load-config="D:\Tools\Air\33/frameworks/airmobile-config.xml" -load-config+=obj\Spinner-Android-x64Config.xml +configname=airmobile -swf-version=35  -define+=CONFIG::isWebVersion,false -define+=CONFIG::isMobileVersion,true -define+=CONFIG::isPCVersion,false  -define+=CONFIG::hasChat,false -define+=CONFIG::hasPicShare,false -define+=CONFIG::isUsingExternalFBANE,false -o obj\Spinner-Android-x64637013390469499179
Running java as: java
Loading configuration: D:\Tools\Air\33\frameworks\airmobile-config.xml
Loading configuration: D:\Dropbox (Personal)\_Gamedev\30_Spinner\Spinner-x64\obj\Spinner-Android-x64Config.xml
2130693 bytes written to D:\Dropbox (Personal)\_Gamedev\30_Spinner\Spinner-x64\obj\Spinner-Android-x64637013390469499179 in 9.273 seconds
Build succeeded
Done(0)

So, should I rather keep <application xmlns="http://ns.adobe.com/air/application/32.0"> or use <application xmlns="http://ns.adobe.com/air/application/33.0"> for Google Play publishing?

you use Flash Develop to run the compilation
same as using IntelliJ, Animate CC, etc. all of those are wrapper
for the real compiler tools, so maybe the limitation come from them

so I would say to be 100% sure, only use the command-line tools from the AIR SDK
(MXMLC, ADL and ADT)

again I would advise to learn the command-line and learn to do an automated build

think of it like that, at one moment you may want to compile 2 APK
one for ARM 32-bit and another for ARM 64-bit, or merge them into only one APK, etc.

it is much much easier and faster to do such things from the command-line

FD is very close to the pure command line, and all the .bat commands are transparent. So I’m just wondering - should I set application xmlns to http://ns.adobe.com/air/application/33.0 ?

technically yes
after I did not personally tested with AIR 33 SDK so maybe harman missed/forgot something?

but for years it always been like that

  • new AIR SDK
  • if you need the new features then you have to update the app xml with the new SDK version

now with the AIR 33 SDK, I saw different types of things that can cause errors/problems

  • Not having Java 8, / using an older Java version like Java 7
    AIR 33 is built against Java 8 so check if you have this minimum version installed
    eg. $ java -version should gives java version "1.8.0_xyz"
  • publish the APK without the -arch armv8 command-line option
    (and note before the option was -arch arm8 so check if you do use “armv8”)
    without that option this will produce an ARM 32-bit binary
  • only publish 1x APK when you want to support both 32-bit and 64-bit
    in order to support both you need
    • publish 1x APK with the -arch armv8 to produce an arm64-v8a binary
    • publish 1x APK with the -arch armv7 (or without this option) to produce an armeabi-v7a binary
    • be sure to follow Android directives when you publish multiple SDK for the same app
      see Multiple APK support (read it well the multiple version parts can be quite confusing)
  • publishing the APK with the wrong minimum/target SDK version
    see Meet Google Play’s target API level requirement
    eg. Back button key down event targetsdk v28
    you would want something like <uses-sdk android:minSdkVersion="19" android:targetSdkVersion="28" />
  • publishing the APK without updating the ANE to 64-bit
    • it seems that Milkman did not update their old ANE
    • and Distriq did update their ANE to 64-bit
    • if you build your own ANE you then need to recompile them too

and for Animate CC in particular check
How to publish apk with ARMv8 Adobe Animate CC 2017?

eg. in the same folder as adt.jar
you need to create a file adt.cfg
and edit the content

DefaultArch=armv8
OverrideArch=armv8
DebugOut=false

this seems to be a global option (not per project)
so check if you need to close/restart Animate CC after making the edit
etc.