airsdk
Since November, AAB capacity has decreased and is abnormal.
Discussed in https://github.com/airsdk/Adobe-Runtime-Support/discussions/2952
Originally posted by SEMOKISOFT December 3, 2023
Hello, I love Harman and Samsung very much. Thank you very much for allowing me to create apps through AS3.
One problem occurred. I am creating an AAB file through Animate and publishing the game on the Play Store.
There has been no problem at all so far, but there is a problem starting from the November version. For example, if I make my game in AAB in the September or October version before November, it originally came out to about 150 megabytes. However, if I make AAB in the version after November, it comes out to 120 megabytes. At first, I thought it was good because the capacity was reduced, but the problem is that it doesn't go up normally on the Play Console, and even if it goes up, it doesn't run when I test it in an internal test.
If you use the October or September version again, AAB will be created with 150 MB, and it will load and run well.
I've done various tests, and if you make it as an APK instead of AAB with the November version, the size comes out to 150 MB and the test play works well. Only when you make it as an AAB file does the size get drastically reduced to about 120 MB and it doesn't seem to work properly.
Therefore, we are unable to use the latest SDK and are only updating in September and October.
There is no major problem right now, but in the long run, I think I will need to use the latest SDK. Is there anyone like me?
This is a very serious problem for me. I really need help.
Same problem, when publishing using SDK 50.2.4.2. in conjunction with Animate The apk is fine (the updated adt.jar supplied for download, fixed issue around CERTIFICATE etc. ) but the aab file sent to the store is reduced in size and the app fails on opening. So reverted to earlier SDK (50.2.2.6) for now - have not tried with any of the SDKs, between these two.
Would like to say how much I appreciate the enormous work you are doing to keep this route for app production alive. Big thank you!
Extract the AAB using WinRAR for example, created by older and newer SDK, checks if files are missing. see here too.
Files missing from aab produced by 50.2.4.2 compared to the working aab from 50.2.2.6 are: In base folder the files native.pb and resources.pb are are both absent.
Yes a couple of District ANE.s
On 4 Jan 2024, at 17:39, pol2095 @.***> wrote:
are-you using ANE ?
— Reply to this email directly, view it on GitHub https://github.com/airsdk/Adobe-Runtime-Support/issues/2992#issuecomment-1877506798, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABNGIUMMSIRTYIZCLUHBSUTYM3SL5AVCNFSM6AAAAABBNGN5USVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNZXGUYDMNZZHA. You are receiving this because you authored the thread.
Try creating a simple project, and check if resources.pb is present in the aab file.
OK - made very simple project - no ANE's. Examined aab there is no native.pb when pub;oshed with 50.2.4.2 but there is when published with 50.2.2.6 resources.pb is presnt on both cases, as is assets.pb Hope this helps?
Same simple project compiled to aab with SDK 50..2.3.4 also produces native.pb, and resources.pb, - all the same collection of files as SDK 50.2.2.6. Only SDK 50.2.4.2 does not produce native.pb
Android SDK Build-Tools version ?
in the app descriptor, you didn't add <BuildLegacyAPK>true</BuildLegacyAPK> ?
Android SDK Build-Tools version APi Level 33 installed, as shown in Android Studio Tools>Android>SDK - SDK Platforms
Have never included <BuildLegacyAPK>true</BuildLegacyAPK> in app descriptor.
Is this only when packaging with Animate? I mentioned in the original thread it might be worth a try to package from the command line (with adt -package) with AIR 50.2.4.2, using the swf generated from Animate, and see if you get all .pb files that way. I'm not having the same problems with 50.2.4.2, though I'm on Windows and using the command line for packaging, so I'm wondering if it's a macOS issue, or maybe an issue with Animate (especially if you're on the latest Animate version)?
trying adt :
1- create a directory "testAir" on the Desktop
2- extract the swf in the *.aab/base/assets/ creating in the simple project, in "testAir" directory, name it "main.swf"
3- create a file "application.xml"
<?xml version="1.0" encoding="UTF-8"?>
<application xmlns="http://ns.adobe.com/air/application/50.2">
<id>com.Test</id>
<versionNumber>0.0.1</versionNumber>
<filename>Test</filename>
<name>Test</name>
<initialWindow>
<content>main.swf</content>
</initialWindow>
</application>
4- right-click on "testAir" directory > "New Terminal at Folder"
5- <AIR_SDK>/bin/adt -certificate -validityPeriod 25 -cn SelfSigned 2048-RSA certif.pfx yourPassword
6- <AIR_SDK>/bin/adt -package -target aab -storepass yourPassword -storetype pkcs12 -keystore certif.pfx Test.aab application.xml main.swf
check if "resources.pb" is present in "Test.aab"
Carried out the above steps and yes resources.pb, native.pb and assests.pb are all present in the unzipped aab file.
So we have a Mac issue when using SDK 50.2.4.2
adt work correctly, it's strange, I think Animate use adt like the command line. try to change the certificate in Animate in the simple project by the self signed that you have generated and try again. Share the "application.xml" generated by Animate.
Did that and assets.pb, resources.pb produced but no native.pb
In terms of Animate version, its 20.0.3
The problem is mentionned in the log
-target apk-captive-runtime -arch armv8 ...
Overriding request for apk-captive-runtime, instead generating Android App Bundle
Ignoring architecture request for AAB target
you have an aab in the output folder or an apk ?
where is the "adt.log" file located ?
apk in output folder, which I have then always modified the extension to .aab as per instructions.
The adt.log folder is created in the home directory. Attached is the adt.log for a build with 50.2.3.4 This contains a number of additional steps (e.g. "Version in APK = 50.2.3.4, version of ADT = 50.2.3.4" which are absent from the adt.log for a 50.2.4.2 build.
the log isn't exactly the same
Ok, try in "testAir" :
<AIR_SDK>/bin/adt -package -target apk-captive-runtime -arch armv8 -storepass yourPassword -storetype pkcs12 -keystore certif.pfx Test.apk application.xml main.swf
rename "Test.apk" to "Test.abb" and check if "resources.pb" is present
I can reproduce it without Animate.
It's the parameter CreateAndroidAppBundle=true (uncommented) in <AIR_SDK>/lib/adt.cfg that causes the bug on AIR SDK 50.2.4.2 using adt -package -target apk-captive-runtime -arch armv8
adt -package -target aab works correctly but it's impossible to use it in Adobe Animate.
Now we need a Harman help to fix this bug.
Many thanks for your help
Sent from my iPhone
On 5 Jan 2024, at 13:01, pol2095 @.***> wrote:
I can reproduce it without Animate It's the parameter CreateAndroidAppBundle=true in <AIR_SDK>/lib/adt.cfg that causes the bug on AIR SDK 50.2.4.2 using adt -package -target apk-captive-runtime -arch armv8 adt -package -target aab work correctly but it's impossible to use in Adobe Animate now you need a Harman help.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you authored the thread.
Just coming back from a New Year break, sorry.... @pol2095 thanks for the support, you went through the same steps I would have done! I think it's most likely a problem caused by a combination of factors hitting a scenario that we may not have spotted (particularly if using Animate..)
So with Animate, if you're trying to create an AAB file, then you'd need to have the extra setting in the configuration file, CreateAndroidAppBundle=true and we can see from the log file that this is working..
Then the difference that you've spotted in the log is where we don't have:
Version in APK = 50.2.3.4, version of ADT = 50.2.3.4
which is where we're looking at the Runtime.apk files for each platform, and checking that they match the runtime classes that are contained within ADT (since this is the JNI interface and it needs to correspond...)
Which implies, we're not picking up the native libraries from Runtime.apk, which would mean that the bundle is smaller and doesn't work...!
We will need to check what's going on here, but it should be a set-up we can reproduce and debug fairly swiftly.
thanks
@MikeSB this appears to be linked to some similar issues we've had when trying to adjust the build settings using overrides, and trying to ensure we get sensible default values etc.. but the use of 'CreateAndroidAppBundle' appears to then miss out on the default settings that should happen when we normally build an app bundle.
So we can fix that in the next release, but the workaround for the short term is to add the below to your app descriptor file (or merge into an existing 'android' section):
<android>
<buildArchitectures>x86,x64,armv7,armv8</buildArchitectures>
</android>
Or you can just choose armv7,armv8 which covers a lot of devices .. or even just the x64,armv8 which probably covers the majority of more modern devices..
thanks
Thanks
Sent from my iPhone
On 8 Jan 2024, at 23:41, Andrew Frost @.***> wrote:
@MikeSB this appears to be linked to some similar issues we've had when trying to adjust the build settings using overrides, and trying to ensure we get sensible default values etc.. but the use of 'CreateAndroidAppBundle' appears to then miss out on the default settings that should happen when we normally build an app bundle.
So we can fix that in the next release, but the workaround for the short term is to add the below to your app descriptor file (or merge into an existing 'android' section):
Or you can just choose armv7,armv8 which covers a lot of devices .. or even just the x64,armv8 which probably covers the majority of more modern devices.. x86,x64,armv7,armv8 thanks
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you were mentioned.