Azure Pipelines: Error NETSDK1139: The target platform identifier android was not recognized

I have a .NET MAUI mobile app project and since yesterday it was built ok in Azure DevOps until yesterday.

Then I start getting this error:

> Error NETSDK1139: The target platform identifier android was not
> recognized

I have specified target platform as net7.0-android in my csproj file.

 <TargetFrameworks>net7.0-android;net7.0-ios</TargetFrameworks>

Upon executing this task

      - task: NuGetCommand@2
        displayName: "Performing NuGet restore"
        inputs:          
          command: restore
          VstsFeed: "xxx.xxxx/Lib"

Nuget restore has called after dotnet restore that executed ok.

      - task: NuGetAuthenticate@0
        displayName: "NuGet Authenticate"

      - task: DotNetCoreCLI@2
        displayName: "Performing DotNet Restore"
        inputs:
          command: restore
          feedsToUse: 'select'
          VstsFeed: "xxx.xxxx/Lib"

      - task: NuGetCommand@2
        displayName: "Performing NuGet restore"
        inputs:          
          command: restore
          VstsFeed: "xxx.xxxx/Lib"

I suppose the windows agent image is missing some workloads now.

I install workloads using the following command:

      - task: Bash@3
        displayName: "Install MAUI support"
        inputs:
          targetType: 'inline'
          script: |
                    dotnet nuget locals all --clear
                    dotnet workload install maui
                    dotnet workload install maui-mobile
                    dotnet workload install android 
                    dotnet workload install maui-android                    

And when I call

> dotnet workload list

It shows that the following workloads are installed:

Then I called the command

> dotnet workload search

To list all available workloads and get this list:

What workload should I install to fix this issue?

I tried to install runtimes-windows workload too, but it did not help.

We have seen the same issue (starting only yesterday). We found that the reason was the update of the SDK version from 7.0.306 to 7.0.400. This update was done automatically in the build pipeline (and probably in yours as well).
Using the suggestion from SiddheshDesai we created a global.json to hardcode the SDK version to the previously working version:

{
  "sdk": {
    "version": "7.0.306",
    "rollForward": "disable"
  }
}

This workaround allowed building again. However, this is just a temporary workaround and it should be reverted once the issue is fixed.