-
Notifications
You must be signed in to change notification settings - Fork 538
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.
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
Prevent $(AndroidUseLatestPlatformSdk)
from using Unstable APIs
#1221
Labels
Area: App+Library Build
Issues when building Library projects or Application projects.
Milestone
Comments
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Jan 24, 2018
…` from using Unstable APIs Fixes dotnet#1221 Currently when a user sets `$(AndroidUseLatestPlatformSdk)` it will automatically use the Max ApiLevel. This is not always a stable ApiLevel. It is highly possible that it will be unstable. Users will generally want to keep to the Max Stable in this senario. This commit alters the code so that we use the latest Max Stable ApiLevel when using `$(AndroidUseLatestPlatformSdk)`. However we should still allow users to use the unstable ones if they really want to. This can be achieved in a number of ways 1. Turn off `$(AndroidUseLatestPlatformSdk)` and set the `$(TargetFrameworkVersion)` directly. 2. Leave `$(AndroidUseLatestPlatformSdk)` on and set the `$(TargetFrameworkVersion)` directly. So effectviely, just manually target the unstable Api. But it is something the user will need to think about and do manaully. By default we will only use to the latest stable ApiLevel.
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Feb 1, 2018
…` from using Unstable APIs Fixes dotnet#1221 Currently when a user sets `$(AndroidUseLatestPlatformSdk)` it will automatically use the Max ApiLevel. This is not always a stable ApiLevel. It is highly possible that it will be unstable. Users will generally want to keep to the Max Stable in this senario. This commit alters the code so that we use the latest Max Stable ApiLevel when using `$(AndroidUseLatestPlatformSdk)`. However we should still allow users to use the unstable ones if they really want to. This can be achieved in a number of ways 1. Turn off `$(AndroidUseLatestPlatformSdk)` and set the `$(TargetFrameworkVersion)` directly. 2. Leave `$(AndroidUseLatestPlatformSdk)` on and set the `$(TargetFrameworkVersion)` directly. So effectviely, just manually target the unstable Api. But it is something the user will need to think about and do manaully. By default we will only use to the latest stable ApiLevel.
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Feb 7, 2018
…` from using Unstable APIs Fixes dotnet#1221 Currently when a user sets `$(AndroidUseLatestPlatformSdk)` it will automatically use the Max ApiLevel. This is not always a stable ApiLevel. It is highly possible that it will be unstable. Users will generally want to keep to the Max Stable in this senario. This commit alters the code so that we use the latest Max Stable ApiLevel when using `$(AndroidUseLatestPlatformSdk)`. However we should still allow users to use the unstable ones if they really want to. This can be achieved in a number of ways 1. Turn off `$(AndroidUseLatestPlatformSdk)` and set the `$(TargetFrameworkVersion)` directly. 2. Leave `$(AndroidUseLatestPlatformSdk)` on and set the `$(TargetFrameworkVersion)` directly. So effectviely, just manually target the unstable Api. But it is something the user will need to think about and do manaully. By default we will only use to the latest stable ApiLevel.
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Feb 7, 2018
…` from using Unstable APIs Fixes dotnet#1221 Currently when a user sets `$(AndroidUseLatestPlatformSdk)` it will automatically use the Max ApiLevel. This is not always a stable ApiLevel. It is highly possible that it will be unstable. Users will generally want to keep to the Max Stable in this senario. This commit alters the code so that we use the latest Max Stable ApiLevel when using `$(AndroidUseLatestPlatformSdk)`. However we should still allow users to use the unstable ones if they really want to. This can be achieved in a number of ways 1. Turn off `$(AndroidUseLatestPlatformSdk)` and set the `$(TargetFrameworkVersion)` directly. 2. Leave `$(AndroidUseLatestPlatformSdk)` on and set the `$(TargetFrameworkVersion)` directly. So effectviely, just manually target the unstable Api. But it is something the user will need to think about and do manaully. By default we will only use to the latest stable ApiLevel.
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Feb 13, 2018
…` from using Unstable APIs Fixes dotnet#1221 Currently when a user sets `$(AndroidUseLatestPlatformSdk)` it will automatically use the Max ApiLevel. This is not always a stable ApiLevel. It is highly possible that it will be unstable. Users will generally want to keep to the Max Stable in this senario. This commit alters the code so that we use the latest Max Stable ApiLevel when using `$(AndroidUseLatestPlatformSdk)`. However we should still allow users to use the unstable ones if they really want to. This can be achieved in a number of ways 1. Turn off `$(AndroidUseLatestPlatformSdk)` and set the `$(TargetFrameworkVersion)` directly. 2. Leave `$(AndroidUseLatestPlatformSdk)` on and set the `$(TargetFrameworkVersion)` directly. So effectviely, just manually target the unstable Api. But it is something the user will need to think about and do manaully. By default we will only use to the latest stable ApiLevel.
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Feb 14, 2018
…` from using Unstable APIs Fixes dotnet#1221 Currently when a user sets `$(AndroidUseLatestPlatformSdk)` it will automatically use the Max ApiLevel. This is not always a stable ApiLevel. It is highly possible that it will be unstable. Users will generally want to keep to the Max Stable in this senario. This commit alters the code so that we use the latest Max Stable ApiLevel when using `$(AndroidUseLatestPlatformSdk)`. However we should still allow users to use the unstable ones if they really want to. This can be achieved in a number of ways 1. Turn off `$(AndroidUseLatestPlatformSdk)` and set the `$(TargetFrameworkVersion)` directly. 2. Leave `$(AndroidUseLatestPlatformSdk)` on and set the `$(TargetFrameworkVersion)` directly. So effectviely, just manually target the unstable Api. But it is something the user will need to think about and do manaully. By default we will only use to the latest stable ApiLevel.
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Feb 19, 2018
…` from using Unstable APIs Fixes dotnet#1221 Currently when a user sets `$(AndroidUseLatestPlatformSdk)` it will automatically use the Max ApiLevel. This is not always a stable ApiLevel. It is highly possible that it will be unstable. Users will generally want to keep to the Max Stable in this senario. This commit alters the code so that we use the latest Max Stable ApiLevel when using `$(AndroidUseLatestPlatformSdk)`. However we should still allow users to use the unstable ones if they really want to. This can be achieved in a number of ways 1. Turn off `$(AndroidUseLatestPlatformSdk)` and set the `$(TargetFrameworkVersion)` directly. 2. Leave `$(AndroidUseLatestPlatformSdk)` on and set the `$(TargetFrameworkVersion)` directly. So effectviely, just manually target the unstable Api. But it is something the user will need to think about and do manaully. By default we will only use to the latest stable ApiLevel.
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Feb 20, 2018
…` from using Unstable APIs Fixes dotnet#1221 Currently when a user sets `$(AndroidUseLatestPlatformSdk)` it will automatically use the Max ApiLevel. This is not always a stable ApiLevel. It is highly possible that it will be unstable. Users will generally want to keep to the Max Stable in this senario. This commit alters the code so that we use the latest Max Stable ApiLevel when using `$(AndroidUseLatestPlatformSdk)`. However we should still allow users to use the unstable ones if they really want to. This can be achieved in a number of ways 1. Turn off `$(AndroidUseLatestPlatformSdk)` and set the `$(TargetFrameworkVersion)` directly. 2. Leave `$(AndroidUseLatestPlatformSdk)` on and set the `$(TargetFrameworkVersion)` directly. So effectviely, just manually target the unstable Api. But it is something the user will need to think about and do manaully. By default we will only use to the latest stable ApiLevel.
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Feb 23, 2018
…` from using Unstable APIs Fixes dotnet#1221 Currently when a user sets `$(AndroidUseLatestPlatformSdk)` it will automatically use the Max ApiLevel. This is not always a stable ApiLevel. It is highly possible that it will be unstable. Users will generally want to keep to the Max Stable in this senario. This commit alters the code so that we use the latest Max Stable ApiLevel when using `$(AndroidUseLatestPlatformSdk)`. However we should still allow users to use the unstable ones if they really want to. This can be achieved in a number of ways 1. Turn off `$(AndroidUseLatestPlatformSdk)` and set the `$(TargetFrameworkVersion)` directly. 2. Leave `$(AndroidUseLatestPlatformSdk)` on and set the `$(TargetFrameworkVersion)` directly. So effectviely, just manually target the unstable Api. But it is something the user will need to think about and do manaully. By default we will only use to the latest stable ApiLevel.
jonpryor
pushed a commit
that referenced
this issue
Feb 23, 2018
…TABLE levels (#1228) Fixes: #1221 Currently when a user sets `$(AndroidUseLatestPlatformSdk)` it will automatically use the maximum known API level. This is not always a stable ApiLevel, e.g. when a preview API level has been bound, and the binding has been installed. Users will generally want to use the maximum *stable* API level when `$(AndroidUseLatestPlatformSdk)` is True. Alters things so that we use the maximum Stable API level when `$(AndroidUseLatestPlatformSdk)` is True. However, allow users to use unstable API levels if desired. This can be achieved by setting `$(TargetFrameworkVersion)` to the desired unstable framework version. (For example, when API-O was in preview, this would be `v7.99`. When API-P is presumably announced, it will be bound as `v8.99`.) This will require a *manual* change to the `.csproj`, as we do not anticipate the IDEs showing unstable API levels (though this could plausibly be done with sufficient warnings...).
jonpryor
pushed a commit
that referenced
this issue
Feb 27, 2018
…TABLE levels (#1228) Fixes: #1221 Currently when a user sets `$(AndroidUseLatestPlatformSdk)` it will automatically use the maximum known API level. This is not always a stable ApiLevel, e.g. when a preview API level has been bound, and the binding has been installed. Users will generally want to use the maximum *stable* API level when `$(AndroidUseLatestPlatformSdk)` is True. Alters things so that we use the maximum Stable API level when `$(AndroidUseLatestPlatformSdk)` is True. However, allow users to use unstable API levels if desired. This can be achieved by setting `$(TargetFrameworkVersion)` to the desired unstable framework version. (For example, when API-O was in preview, this would be `v7.99`. When API-P is presumably announced, it will be bound as `v8.99`.) This will require a *manual* change to the `.csproj`, as we do not anticipate the IDEs showing unstable API levels (though this could plausibly be done with sufficient warnings...).
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this issue
Aug 26, 2021
Changes: xamarin/monodroid@fb0d502...5676b84 * xamarin/monodroid@5676b84b4: Bump to xamarin/androidtools@0abc0d7c (dotnet#1223) * xamarin/monodroid@daf1aa909: [optimization] Replace 'new T[0]' with 'Array.Empty<T> ()' to reduce allocations. (dotnet#1221) * xamarin/monodroid@fb848118b: [tools/msbuild] Check `device.Properties.BuildVersionSdk` for `-1` (dotnet#1222) * xamarin/monodroid@489a389d1: [tools/msbuild] Check device additional output to see if its the same device. (dotnet#1218) * xamarin/monodroid@209a7c352: [tests/AndroidMSBuildTests] Remove Unused Unit Tests (dotnet#1215)
jonpryor
added a commit
that referenced
this issue
Aug 27, 2021
Changes: xamarin/monodroid@fb0d502...5676b84 * xamarin/monodroid@5676b84b4: Bump to xamarin/androidtools@0abc0d7c (#1223) * xamarin/monodroid@daf1aa909: [optimization] Replace 'new T[0]' with 'Array.Empty<T> ()' to reduce allocations. (#1221) * xamarin/monodroid@fb848118b: [tools/msbuild] Check `device.Properties.BuildVersionSdk` for `-1` (#1222) * xamarin/monodroid@489a389d1: [tools/msbuild] Check device additional output to see if its the same device. (#1218) * xamarin/monodroid@209a7c352: [tests/AndroidMSBuildTests] Remove Unused Unit Tests (#1215)
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Currently if a user sets
$(AndroidUseLatestPlatformSdk)
the system will pickup the very latest binding target framework, regardless of if it is stable or not.What we should be doing is using the latest Stable API rather than just grabbing the max.
That said we still want the user to be able to use the unstable API if they really want to. So regardless of
$(AndroidUseLatestPlatformSdk)
is set to true, if the user has set the$(TargetFrameworkVersion)
to the value of an unstable API we should allow the user to use it.So the new logic is as follows
$(AndroidUseLatestPlatformSdk)
= true, use the latest stable API$(TargetFrameworkVersion)
= and unstable version and$(AndroidUseLatestPlatformSdk)
= false, use the$(TargetFrameworkVersion)
.3.
$(TargetFrameworkVersion)
= and unstable version and$(AndroidUseLatestPlatformSdk)
= true, use the$(TargetFrameworkVersion)
The text was updated successfully, but these errors were encountered: