Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

[.NET 10] invent a "recommended min OS version" for 24 #9527

Open
jonathanpeppers opened this issue Nov 19, 2024 · 2 comments
Open

[.NET 10] invent a "recommended min OS version" for 24 #9527

jonathanpeppers opened this issue Nov 19, 2024 · 2 comments
Assignees
@dellis1972 @jonathanpeppers
Labels
Area: App+Library Build Issues when building Library projects or Application projects.
Milestone
.NET 10

Comments

@jonathanpeppers
Copy link
Member

jonathanpeppers commented Nov 19, 2024 •
edited
Loading

Android framework version

net9.0-android

Affected platform version

any

Description

We would like to bump the minimum Android OS version to 24 (instead of 21), but we need to do it in a non-disruptive way.

I propose something like:

  • SupportedOSPlatformVersion=24 in project templates
  • If blank, SupportedOSPlatformVersion=24 is the default
  • Customers can opt into lower SupportedOSPlatformVersion=21, for example
  • We emit a build warning for SupportedOSPlatformVersion < 24

Steps to Reproduce

Ideally, it would:

  1. dotnet new android
  2. dotnet build
  3. I see minSdkVersion="24" in the resulting .apk

Did you find any workaround?

Set SupportedOSPlatformVersion=24 manually.
@jonathanpeppers jonathanpeppers added the Area: App+Library Build Issues when building Library projects or Application projects. label Nov 19, 2024
@jonathanpeppers jonathanpeppers added this to the .NET 10 milestone Nov 19, 2024
@dotnet-policy-service dotnet-policy-service bot added the needs-triage Issues that need to be assigned. label Nov 19, 2024
@rolfbjarne
Copy link
Member

There's some work towards changing the default SupportedOSPlatformVersion to the minimum valid value across all of .NET - if that could be tweaked a little bit to say the default SupportedOSPlatformVersion is a recommended value each individual SDK sets, then that could work for this:

  • Introduce a new RecommendedSupportedOSPlatformVersion property, which Android could set to 24 (for iOS we could set it to the minimum we support, unless we have a reason to do otherwise).
  • If RecommendedSupportedOSPlatformVersion is not set, then .NET keeps the same behavior as today (or change the default to the minimum, either way would work).

There are a couple of advantages:

  • No hardcoding values in the user's csproj, which will eventually end up invalid one day.
  • Telemetry is actually useful: if an app has SupportedOSPlatformVersion=21, we'll know it's on purpose, and not by accident.

CC @Redth

@Redth
Copy link
Member

Redth commented Nov 19, 2024

This seems like a good approach to me. It may also help with Windows' concern over changing implicit behaviour / current defaults. I could see us setting this value in the MAUI SDK for Windows if they were willing to add logic to check for the value and use it if no other explicit value is specified already.

@jpobst jpobst removed the needs-triage Issues that need to be assigned. label Nov 20, 2024
@jpobst jpobst mentioned this issue Jan 8, 2025
Merged
jonpryor pushed a commit that referenced this issue Jan 10, 2025
@jpobst
[templates] Default $(SupportedOSPlatformVersion)=24. (#9656)
6754e05 
Fixes: #9517

Context: #9527
Context: dotnet/java-interop@1f27ab5
Context: dotnet/android-libraries#767
Context: dotnet/android-libraries#767 (comment)

[Desugaring][0] is an Android SDK build step which rewrites Java
bytecode so that some Java 8+ language constructs can be used on
older Android versions, containing a Dalvik VM that doesn't natively
support those constructs.  The primary examples are interface static
methods and interface default methods, which *moves* methods from the
declaring type to a *different* `$-CC`-suffixed type.

For example, consider
[`ImageAnalysis.Analyzer.getDefaultTargetResolution()`][1], which is
an interface default method:

	// Java
	/* partial */ class ImageAnalysis {
	    /* partial */ interface Analyzer {
	        default Size getDefaultTargetResolution() {…}
	    }
	}

Our bindings for `androidx.camera.core` expect the
`getDefaultTargetResolution()` method to be on `Analyzer`:

	// C#
	[Register("androidx/camera/core/ImageAnalysis$Analyzer", "", "AndroidX.Camera.Core.ImageAnalysis/IAnalyzerInvoker")]
	public partial interface IAnalyzer : IJavaObject, IDisposable, IJavaPeerable {
	    unsafe Size? DefaultTargetResolution
	    {
	        [Register("getDefaultTargetResolution", "()Landroid/util/Size;", "GetGetDefaultTargetResolutionHandler:AndroidX.Camera.Core.ImageAnalysis/IAnalyzer, Xamarin.AndroidX.Camera.Core")]
	        get {
	            return Java.Lang.Object.GetObject<Size>(_members.InstanceMethods.InvokeVirtualObjectMethod("getDefaultTargetResolution.()Landroid/util/Size;", this, null).Handle, JniHandleOwnership.TransferLocalRef);
	        }
	    }
	}

When desugaring is used, the `Analyzer` interface is changed,
moving the default interface method body to a separate type:

	/* partial */ interface Analyzer {
	    Size getDefaultTargetResolution();      // interface declaration
	}
	/* partial */ class Analyzer$-CC {
	    Size getDefaultTargetResolution() {…}   // default implementation
	}

The movement of methods across types breaks our JNI-based bindings,
which don't have easy support for such movements.  The movement of
`getDefaultTargetResolution()` causes C# apps attempting to invoke the
`ImageAnalysis.IAnalyzer.DefaultTargetResolution` property *crash*:

	JNI DETECTED ERROR IN APPLICATION: JNI CallObjectMethodA called with pending exception java.lang.AbstractMethodError: abstract method "android.util.Size androidx.camera.core.ImageAnalysis$Analyzer.getDefaultTargetResolution()"

The workaround is to *not desugar* the app, which can be done by
setting `$(SupportedOSPlatformVersion)`=24, which sets the minimum
supported Android version to Android 7.0, released 2016-Aug-22.

We could fix this, but the fix is only needed for apps which need to
run on Android 6.0 API-23 and earlier devices.  As these devices are
so old, we'd rather focus on more important issues.

Attempt to improve things by updating the `dotnet new android`
template in .NET 10 so that the default
`$(SupportedOSPlatformVersion)` value is 24, up from 21.  This will
avoid the entire desugaring problem for new apps (until they set
`$(SupportedOSPlatformVersion)` to 23 or lower…).

Note that Android 5.0 / API-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.

[0]: https://developer.android.com/studio/write/java8-support
[1]: https://developer.android.com/reference/androidx/camera/core/ImageAnalysis.Analyzer#getDefaultTargetResolution()
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@dellis1972 dellis1972

@jonathanpeppers jonathanpeppers

Labels
Area: App+Library Build Issues when building Library projects or Application projects.
Projects
None yet
Milestone
.NET 10
Development

No branches or pull requests
5 participants
@jpobst @rolfbjarne @Redth @dellis1972 @jonathanpeppers