Backport Android API-36 support. #10005
Conversation
jpobst
force-pushed
the
dev/jpobst/backport-api-36
branch
2 times, most recently
from
4af9680 to
de60f48
Compare
jpobst
force-pushed
the
dev/jpobst/backport-api-36
branch
from
de60f48 to
d3d476e
Compare
jpobst
requested review from
dellis1972,
grendello,
jonathanpeppers,
jonpryor and
pjcollins
as code owners
|
Shouldn't Have we run any API comparison between .NET 10's Mono.Android.dll and this new .NET 9 API-36 Mono.Android.dll? I assume they should be identical. |
I guess it could be. We generally do it when we ship in Nov, so there is a pretty long lag time between when we mark the Android API "stable" and when we the .NET is "stable". However, I guess we won't have that lag time for backporting. The downside is moving it here but not in Ultimately it probably doesn't matter too much either way. From a tooling perspective there is no difference between "Shipped" and "Unshipped" files, and I doubt we will be adding new API to .NET 9 in the future.
Not explicitly, but the |
3 participants
Context: #9914
Backport of #9914, et al to bring support for API-36 to .NET 9 (
net9.0-android36.0).Note our repository does not currently have build system support for having multiple stable API platform versions in a single .NET version. To work around this, this commit treats API-36 as an "unstable" API level for the context of our build system. However it removes the need for users to use
$(EnablePreviewFeatures)and thus is a stable platform version to our users.If we actually updated
$(AndroidLatestStableApiLevel)to36it would have (at least) the following issues:net9.0-androidwould switch fromnet9.0-android35.0tonet9.0-android36.0which we do not want. Once shipped,net9.0-androidshould not change meaning.Proper multi-stable support would require expanding
$(AndroidLatestStableApiLevel)to something akin to$(AndroidMinimumStableApiLevel)/$(AndroidMaximumStableApiLevel)or@(AndroidStableApiLevels). We have chosen not to invest in this work at this time.