GitHub Actions no longer builds MAUI (Android): Java SDK 11.0 or above is required when using .NET 6 or higher

[iamalexmang]

Description

Starting today the Android builds fail on GitHub Actions using GitHub's runners.

Specifically, a build that ran fine 6h ago, now fails with "Java SDK 11.0 or above is required when using .NET 6 or higher"

Steps to Reproduce

No response

Link to public reproduction project repository

No response

Version with bug

7.0.101

Is this a regression from previous behavior?

Not sure, did not test other versions

Last version that worked well

7.0.100

Affected platforms

Android

Affected platform versions

No response

Did you find any workaround?

No response

Relevant log output

Error: C:\Users\runneradmin\AppData\Local\Microsoft\dotnet\packs\Microsoft.Android.Sdk.Windows\33.0.95\targets\Microsoft.Android.Sdk.Tooling.targets(20,5): error XA0031: Java SDK 11.0 or above is required when using .NET 6 or higher. Download the latest JDK at: https://aka.ms/msopenjdk [D:\a\MAE-Alerte\MAE-Alerte\src\Alerte\Mobile\Mobile\Mobile.csproj::TargetFramework=net7.0-android]

[ErisApps]

Hii, I saw a related issue on the runner-images github repo, which should contain a workaround for this issue that you described. It can be found here: actions/runner-images#8837

[jfversluis]

I've seen this mentioned a couple of times now. I think what happens is that the images are being updated to use .NET 8 while your project is still on .NET < (less than) 8. Somehow this error is triggered.

A couple of possible solutions here:

• Use a global.json that pins your project to .NET 7
• Use the actions/setup-dotnet step to select .NET 7 and do your build after that. You might need to install the .NET MAUI workload after doing this to make sure it's available
• Update your project to .NET 8
• There is also a the actions/setup-java to select the Java version, but seeing that it has worked before it seems weird that you'd have to do this, although it probably works.

As far as I know there is not much we can do about this on our end, this is just the pain with hosted build agents and a period where multiple things update I guess.

If someone could confirm that one of these solutions work and which one, that would be great!

[ghost]

Hi @iamalexmang. We have added the "s/needs-info" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[cdefgah]

I get this issue in Azure Pipelines, the error was the same. Fixed it adding this code to pipelines.yml file:

      - task: JavaToolInstaller@0
        displayName: "Install Java Support"
        inputs:
          versionSpec: '11'
          jdkArchitectureOption: 'x64'
          jdkSourceOption: 'PreInstalled'

Probably there's a similar workaround for GH Actions.

[iamalexmang]

@jfversluis the action which started failing I:

1. Run setup-dotnet, specifying the .NET version, like this:

   - name: Setup .NET SDK ${{ env.DOTNETVERSION }}
     uses: actions/setup-dotnet@v2
       with:  
         dotnet-version: '${{ env.DOTNETVERSION }}'
   

2. Second, I also Install .NET Maui already:

   - name: Install .NET MAUI
     shell: bash
     run: |
       dotnet nuget locals all --clear 
       dotnet workload install maui --source https://aka.ms/dotnet6/nuget/index.json --source https://api.nuget.org/v3/index.json
       dotnet workload install android ios maccatalyst tvos macos maui wasm-tools --source https://aka.ms/dotnet6/nuget/index.json --source https://api.nuget.org/v3/index.json
   

This effectively rules out the second bullet point.
I agree that setting up Java should not be the case..., but neither should be upgrading to .NET 8, IMHO.

[jfversluis]

but neither should be upgrading to .NET 8, IMHO.

I understand you shouldn't feel like you have to, but this is the problem with using hosted runners that are out of your control. They will update things that might break the config you got running simply because there are so many moving parts and each project is unique.

Just as a side-question: why the hesitance to move to .NET 8?

In either case, the Java step does fix things as well as other options on this list. Unfortunately this is out of our control and not something we can fix on the SDK side, this is more a build system configuration issue. As such, closing it here.

[pauldendulk]

I solved this by specifying the java version in the github action

    - uses: actions/setup-java@v3
      with:
        distribution: 'temurin'
        java-version: '17'

As describe in the page jfversluis pointed to https://github.com/actions/setup-java

I understand these are 'moving parts' but I expect a regular net 7.0 MAUI project to still build a week after the release of net 8.0.

[iamalexmang]

I am of the opinion that even though these are moving parts, as long as a framework is supported and installed, projects targeting that framework and that framework alone should not suddenly stop working because of a fresh new release...
As per https://dotnet.microsoft.com/en-us/platform/support/policy/dotnet-core, the end of support for .NET 7 is May 14th, 2024.

Just as a side-question: why the hesitance to move to .NET 8?

Reason behind not upgrading head-first to a fresh new release of a framework are plenty and cover a spectrum starting from "moving parts" - which are commonly too many for enterprise applications, and end with the inability to support working system, including but not limited to the continuous integration and continuous deployment systems.

Second, the reason for using hosted agents, similarly, had to do with the ability to support and be supported by frameworks and systems which are within their support period. For instance, if I'd run the agents myself, I'd require an agent per project, per teams and per builds, so pretty much one for each 5 devs or so. All of these would then have to be maintained and updated not for just one technology, but for the plethora of technologies targeted by the plethora of projects within the organization.

Third, it's ridiculous in my humble opinion that if the project targets .NET 7 (which is well within its support period), one would have to upgrade to .NET 8 not because of its benefits, but because of the hosted runner. Let's be honest here: it's Microsoft framework, running after all on Microsoft's agents, targetting Microsoft's workload (MAUI) which stops working not because of a Microsoft framework, but Java, but not because the project is targeting Java, but rather because of an upgrade script or image on the Microsoft agent not properly being installed. This is specifically why

this is out of our control and not something we can fix on the SDK side

isn't much of an argument.

Exactly THIS should be in your control!

[iamalexmang]

as well as other options on this list

What other options? Again, running setup-dotnet doesn't fix it, nor does installing MAUI.

[taori]

this works for me:

  - name: Install .NET MAUI
    shell: pwsh
    run: |
      dotnet workload install maui --source https://aka.ms/dotnet6/nuget/index.json --source https://api.nuget.org/v3/index.json
      dotnet workload install android maui wasm-tools --source https://aka.ms/dotnet6/nuget/index.json --source https://api.nuget.org/v3/index.json
      
  - uses: actions/setup-java@v2
    with:
      distribution: 'microsoft'
      java-version: '11'