12/8/2023 0 Comments Adobe air sdk harmanI do not think this is a big problem to "solve" right now. The issue of paying licenses for an OS as something "negative". We have had interactive multimedia working in windows / AIR, 24h a day without problems. It does not matter if you compile "also for linux". There is a lot of competitiveness in those markets. The simple fact of being a "multimedia developer" gives a very specific profile and development type and that has a competitive difference compared to, for example: web developer (millions), or developer of apps for devices (UI type apps). Precisely having Linux as output is "a very specific need" of a particularly specific type of developer and market environment. I understand, Adobe teach you on that way. I'm using the dated AIR 30 because there is no reason at all to release a major update because everything seems to focus only on mobile and for sure I will not pay to Harman if there is 0 innovation on desktop or it's not relevant for me !įor last but not least, seems that some folks get used to think small. I already pay a fee for my IDE and other tools ! Have Linux it's not a blocker issue comparing to macOS and specially compared to Windows but I would pay only for that (on a reasonable fee for me). Without support for Linux, users will compare only features and any advantage is good.Īnd finally, in past we had Linux support (unfortunately very dated to be considered) and for Harman, seems that, this where they are specialist, so it seems possible, cheaper to do and very realistic. Yes, it's a small percentage but if I had support for Linux, I had advantaged. Just because of that I have a advantage on users that want to run on macOS (I have a few). On my use case, there are few competitors and ALL of then are Windows only, except me with macOS support. It happens on Android 10/11 devices, did not manage to reproduced it.I don't know other uses cases out there ! So someone with a x86_64 device can now get the proper native support when they download your app: but if the ANE only included armv7 and armv8 support then they'll not get the platform-specific ANE functionality, they'll just get the 'default' code.īeta Was this translation helpful? Give feedback.Īt (ActivityThread.java:3967)Īt $1500 (ActivityThread.java:233)Īt $H.handleMessage (ActivityThread.java:2006)Īt android.os.Handler.dispatchMessage (Handler.java:107)Īt android.os.Looper.loop (Looper.java:241)Īt (ActivityThread.java:7582)Īt .invoke (Native Method)Īt .RuntimeInit$n (RuntimeInit.java:492)Īt .ZygoteInit.main (ZygoteInit.java:941)Ĭaused by: :Īt (BaseDexClassLoader.java:196)Īt (ClassLoader.java:379)Īt (ClassLoader.java:312)Īt (AppComponentFactory.java:110)Īt .instantiateReceiver (CoreComponentFactory.java:60)Īt (ActivityThread.java:3960) The only thing to watch out for might be that an AAB includes all four CPU types: armv7, armv8, x86 and x86_64. So then it's basically as if the request from Animate was switched from -target apk -arch whatever to -target aab with the rest of the params unchanged.ĪNEs should work fine now because we've changed how we're doing these, the classes are being compiled and linked properly with Gradle rather than just the separate resource-bundling and code-linking that we had done before (where it lost the ability to reference resources in ANEs via the 'R.strings.id' sort of mechanism). Yes exactly: if you're using Animate, or another IDE where you can't select an "AAB" output type yet, then build as if you're doing an APK but uncomment the line so that you have CreateAndroidAppBundle=true in your config file.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |