IssueTracker

Madalin, IIRC this can happen because of reuse of jdk.table.xml from earlier versions of Flamingo canaries (that were still using jdk11), right?

Exactly, because of the jdk.table migrations or reuse of old jdk.table from earlier AS versions is possible to end up with wrong JDK even that minimum required version is 17. This is similar to an already known issue b/206022542 when we end up having same situation after migrate from JDK 8 to 11.

From the attached logs we have the following JDKs presents in the jdk.table, this doesn't show the versions but following the screenshots they should be 11 except for 17 that was created using the latest AS version.

- 11: /Applications/Android Studio Preview.app/Contents/jbr/Contents/Home
- Android Studio default JDK: /Applications/Android Studio Preview.app/Contents/jbr/Contents/Home
- Embedded JDK: /Applications/Android Studio Preview.app/Contents/jbr/Contents/Home
- Android Studio java home: /Applications/Android Studio Preview.app/Contents/jbr/Contents/Home //11
- liberica-11: /Users/verapaneni/Library/Java/JavaVirtualMachines/liberica-11.0.15.1
- 17: /Applications/Android Studio Preview.app/Contents/jbr/Contents/Home //17

At the moment the workaround is to specify JDK 17 from Gradle Settings and delete the project .idea/misc.xml if present, to resolve project symbols using same JDK that was used for gradle daemon. Another alternative is to manually remove the linked jdk.table that is present under Google AS configuration given the version used, until we are still working in addressing this issues from root.

Perhaps it is the correct behaviour that it remains 11. Consider that

(1) we are switching to vendor-version JDK names because they are understood by the platform

(2) any existing IDE projects (i.e. already imported as an IDE project) should remain on their current JDK versions unless their Gradle/AGP/Kotlin versions are compatible/upgraded and thus projects should not be silently migrated to a different version (as it happened in 8 -> 11 transition and caused massive issues)

(3) even through we still consider the embedded JDK to be special we will give it a name following the pattern from (1)

I'd say that the JDK's named following the old style should remain at their old versions to keep projects compatible. However, I think what happened here while may be a desired behaviour won't happen in all cases.

First of all, let's recap a bit regarding Default JDK in AS. This jdk.table entry is created for a specific AS release channel during the Setup wizard where Android SDK and JDK are configured for the first time. Unfortunately AS doesn't expose any way to modify the initial selection, without being forced to manually change it on the jdk.table, taking in consideration the defined value is used to configure the JDK for the new created projects, with the exception when the STUDIO_GRADLE_JDK is present. This fact, causes the described problem when there's an update of the minimum JDK required between AS versions of the same release channel but not only, there are cases where for example the path isn't valid.

We stop relying on the Default JDK entry to configure the JDK for the new created project and instead we are going to use the embedded AS JDK, due that by default the AS is linked with a AGP version, guaranteeing in this way the correct JDK version for the recently created project.

In addition, we created a process that migrates projects away from hardcoded JDK naming like Embedded JDK, Android Studio default jdk and Android Studio java home to the platform standard vendor-version. The reason for this is those naming are very ambiguous to know exactly which provider and version are representing and end up with the possibility to point to a completely different JDK version for the same project on different machines.

Those changes are going to be landed on Android Studio G Canary 5, please provide any feedback once tested with the mentioned version. Thank you