Code Monkey home page Code Monkey logo

Comments (14)

ajwfrost avatar ajwfrost commented on August 18, 2024 1

That's just a note to say that we've updated the Android Gradle Plug-in because of the later build tools and Android SDK platform that you have on your machine.

We'll probably have to get rid of that .. it was meant to be informative, but Animate is presenting it as if it's a warning!

thanks

from adobe-runtime-support.

ajwfrost avatar ajwfrost commented on August 18, 2024 1

You don't need to do anything for that, it's adjusting things automatically. It is theoretically possible to update and configure various tools/settings to remove the notes, but they are fine.

I'm thinking it might be worth us removing those from the stdout which Animate picks up and displays, and just hiding them in our logging information!

thanks

from adobe-runtime-support.

ajwfrost avatar ajwfrost commented on August 18, 2024

Hi

The requirement for Java 17 actually comes from the Android Gradle Plugin, and this version of AGP is required because of the compile / build tools:

NOTE: Multiple Android build-tools folders exist, choosing the latest version (35.0.0 rc2) for packaging

Basically, the AIR SDK looks in your Android SDK folder to see what build tools are available, and always selects the latest ones.

We are looking at adjusting things so that either the tools version could be configurable, or so that we ignore the need for AGP 8.x if we're running on Java 11 still (there will be a warning emitted by AGP 7.x but - currently at least - it should still work).

thanks

from adobe-runtime-support.

yvant avatar yvant commented on August 18, 2024

Thanks for the quick answer. So my best option is to upgrade to java 17? I'm not really at ease with all the android environment / gradle etc.

from adobe-runtime-support.

ajwfrost avatar ajwfrost commented on August 18, 2024

Yes, the two choices currently would be:

  • Update to JDK 17 (or set your JAVA_HOME variable within C:\Users\Yvan\.airsdk\adt.cfg to point to the JBR folder within Android Studio...)
  • Remove the build tools (v34.x and 35.x) from Android Studio's SDK manager

from adobe-runtime-support.

yvant avatar yvant commented on August 18, 2024

Thanks!

from adobe-runtime-support.

yvant avatar yvant commented on August 18, 2024

So in the end I updated to openjdk version "17.0.11" 2024-04-16
OpenJDK Runtime Environment Temurin-17.0.11+9 (build 17.0.11+9)
to be able to build and the publish was successful. However, I recently got a mail from Google:

Upgrade your game to a newer com.google.android.play:core SDK version

com.google.android.play:core has added this note for core:1.8.3:

Update your Play Core Maven dependency to an Android 14 compatible version! Your current Play Core library is incompatible with targetSdkVersion 34 (Android 14), which introduces a backwards-incompatible change to broadcast receivers to improve user security. As a reminder, from August 31, Google Play requires all new app releases to target Android 14. Update to the latest Play Core library version dependency to avoid app crashes: https://developer.android.com/guide/playcore#playcore-migration

1 - What do I need to do to prevent this?
2 - Isn't it better to stick to java 11 and downgrade v34.x and v35.x Android SDK versions?
3 - Why was it ok to keep v34.x and v35.x Android SDK in AIR 50.x?

from adobe-runtime-support.

ajwfrost avatar ajwfrost commented on August 18, 2024

That's an interesting message and makes our choices a little more complex...

Just to answer the questions (well, the second/third ones): ADT has always looked at the available "build tools" folders that are in the Android SDK location, and picks up the last one. That "Multiple Android build-tools folders exist" came from the original Adobe code - but this is probably made more problematic by the fact we use the tools in this folder for the Gradle building. And this is where it then ends up with problems.

So our planned workarounds were:

  1. If someone is running with Java 11 and we don't have a Java 17 installation in a known location, then we could ignore the suggested update to AGP 8.x, which means that we would be able to build the project even though there would be a warning about using compile version 34 using AGP 7.x....
  2. With an updated set of options in the App Descriptor file, we could allow someone to specify the build tools version to use, which means that you could say your app needs to compile with v33, and we'd then know that AGP7.x / Java 11 is fine to use (and there would be no warnings etc).

The challenge with what you're trying there is that approach 1 wouldn't work: we could build it fine with the warning from AGP, but you'd still hit this issue with the Play Core Maven dependency (I think). And that's then because of the build tools being v34, which we can't change without approach 2 (or see below...)

But to answer your first question .. ultimately you need to be building this app using compile SDK and target SDK settings of v33. For the targetSDK, that's something you can have in your app descriptor file (if you don't already?), so something to add to your manifestAdditions section such as: <uses-sdk android:minSdkVersion="21" android:targetSdkVersion="33"/>

To change the compile SDK version, you would need to ensure we don't find any of the other build tools. So e.g. if I go in Windows to %localappdata%\android\sdk\build-tools I can see folders 31.00, 33.0.1, 33.0.2, 34.0.0 etc. If you remove the ones from 34 onwards (via Android SDK Manager) it should limit the compile version to 33. Alternatively if you want to just hide them from ADT, you can rename the source.properties file that's inside each of the folders, cos that's what we inspect to find out the version details...

Hope that helps. We'll look at getting out a build with the "approach 1" in it, but are also going to be pushing out 51.1 soon which will have "approach 2" that should give more flexibility to it all...

from adobe-runtime-support.

yvant avatar yvant commented on August 18, 2024

Thanks for the detailled answer. I'll try to set up the targetSdkVersion to , remove newer android sdk and publish it like that.
Should I still use java 17? Or is java 11 a better choice then?

from adobe-runtime-support.

ajwfrost avatar ajwfrost commented on August 18, 2024

Fingers crossed :-)
At this point, it shouldn't really matter which Java version is used

from adobe-runtime-support.

yvant avatar yvant commented on August 18, 2024

Now that I thing about it, latest ANEs require <uses-sdk android:minSdkVersion="24" android:targetSdkVersion="34"/>. How to handle this discrepancy?

from adobe-runtime-support.

ajwfrost avatar ajwfrost commented on August 18, 2024

Potentially there's a difference between the "compileSdk", "targetSdk" and build tools settings... which may mean that this could still be handled with an older version of the Android platform. But it perhaps depends on the exact requirements.

You mention here that the latest ANEs have a targetSdkVersion requirement of 34, but your other ANE gave an error: Your current Play Core library is incompatible with targetSdkVersion 34

So probably you just need to update that one...?

Ultimately, as per the Google message, everything should start switching to Android 14 = API 34, for which you're meant to use an Android Gradle Plug-in of version 8 or higher, requiring Java 17.. if you do have things that are not compatible with those then - if you're pushing out via the Play Store - you may need to get updates for them...

thanks

from adobe-runtime-support.

jeuxdaily avatar jeuxdaily commented on August 18, 2024

hi
I try to change some version off gradle and java
one result
is this
airsdk51

APK has been published

But is this work good or not?

from adobe-runtime-support.

jeuxdaily avatar jeuxdaily commented on August 18, 2024

thanks for your answer
so what can I do for this ?
What Java and Gradle can I put link in PATH?

from adobe-runtime-support.

Related Issues (20)

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.