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?
Just saw a new post by Daniel in the Starling forum:
“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
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
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
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
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
For the trollers
Date: Mon, May 20, 2019 at 4:20 PM
Subject: RE: Adobe 64-bit for Google
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.
just relax kiddos… here is my source: https://github.com/Gamua/Adobe-Runtime-Support/issues/29
so technically the source is user “@pis0” on the github of Gamua
that copy/pasted some text
- 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.>
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.
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.
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?
I having the same issue using this AIR 33 SDK. I´m using adobe Animate to generate the apps.
Could be many things
even if you compiled with the AIR 188.8.131.52 SDK
maybe you did not update your app XML?
<?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
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
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 ?
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
$ java -versionshould gives
java version "1.8.0_xyz"
- publish the APK without the
-arch armv8command-line option
(and note before the option was
-arch arm8so 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 armv8to produce an
- publish 1x APK with the
-arch armv7(or without this option) to produce an
- 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)
- publish 1x APK with the
- 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
you need to create a file
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