Repository navigation
[templates] Default $(SupportedOSPlatformVersion) to 24. - #9656
Conversation
|
This "fixes" the issue going forward. Should we also add a warning when Edit: I guess this is part of the #9527 proposal. |
jpobst
changed the title
$(SupportedOSPlatformVersion) to `24.$(SupportedOSPlatformVersion) to 24.
jonathanpeppers
left a comment
jonathanpeppers
left a comment
There was a problem hiding this comment.
If $(SupportedOSPlatformVersion) is blank, should we also hardcode 24 here?
My gut feeling is "no", because it makes sense to me that if it isn't set, it should default to the minimum supported, vs. the "minimum recommended". My sense of what makes sense may be completely wrong. Any idea in what scenarios |
This may depend on if we intend to add a warning when targeting |
|
I think we can take this as-is for now, and follow up with more with: |
* main: Bump to dotnet/sdk@2d6bc4f67d 10.0.100-alpha.1.25060.8 (#9669) [templates] Default `$(SupportedOSPlatformVersion)=24`. (#9656) Bump to dotnet/sdk@a93a592ce9 10.0.100-alpha.1.25056.1 (#9395) LEGO: Pull request (#9667) [tests] use the 'TestName' property (#9664)
3 participants
Fixes: #9517
Context: dotnet/android-libraries#767
Context: dotnet/android-libraries#767 (comment)
For .NET 10, update the
dotnet new androidtemplate so that$(SupportedOSPlatformVersion)is 24, bumping from the current default of 21.The reason for this is that "desugaring" "moves" Java methods to locations that we don't expect, which can result in
AbstractMethodErrors at runtime. Setting the minimum SDK version to >= 24 avoids this desugaring step, preventing the Java methods from being moved in a manner we don't expect, and thus avoiding theAbstractMethodError.Note that 21 will still be the supported minimum for those that need it, however this will keep most users who do not need to support devices that old from having desugaring issues.