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.

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

[Xamarin.Android.Tools.AndroidSdk] Unstable framework versions are used #25

Merged
merged 4 commits into from Apr 16, 2018

Conversation

dellis1972
Copy link
Contributor

We had a bug on our logic to calculate the MaxStableVersion.
The first time through the LoadVersions method MaxStableVersion
would ALWAYS be null. As a result regardless of whether the
first version was stable or not it would be assigned to the
property. This would then cause build failures later down the
build process because we were using an unstable api.

So the fix it to completely ignore unstable apis. This way the
first STABLE api we find will be the first value we assign.

…ed when $(AndroidUselatestPlatformSDK)=true

We had a bug on our logic to calculate the `MaxStableVersion`.
The first time through the `LoadVersions` method `MaxStableVersion`
would ALWAYS be `null`. As a result regardless of whether the
first version was stable or not it would be assigned to the
property. This would then cause build failures later down the
build process because we were using an unstable api.

So the fix it to completely ignore unstable apis. This way the
first STABLE api we find will be the first value we assign.
@jonpryor
Copy link
Member

I'd also suggest a test which does:

var versions = new AndroidVersions (
    new[]{new AndroidVersion (100, "100", "100-Test", "Z", false)});
Assert.IsNull (versions.MaxStableVersion);
Assert.IsNull (versions.MinStableVersion);

@jonpryor jonpryor merged commit 50af063 into xamarin:master Apr 16, 2018
jonpryor pushed a commit that referenced this pull request Apr 17, 2018
…ed (#25)

Context: xamarin/xamarin-android#1511

Within xamarin-android, when building with
`$(AndroidUseLatestPlatformSdk)`=True -- which is supposed to use the
latest *stable* API level -- builds would instead use the latest API
level, [*even if unstable*][0]:

[0]: http://xqa.blob.core.windows.net/gist/log-83bd0e75034940db9ae887a8f5c03d98.txt

	ResolveSdksTask: (TaskId:7)
	  AndroidApiLevel:  (TaskId:7)
	  TargetFrameworkVersion: v8.0 (TaskId:7)
	  UseLatestAndroidPlatformSdk: True (TaskId:7)
	  ...
	ResolveSdksTask Outputs: (TaskId:7)
	  AndroidApiLevel: 127 (TaskId:7)
	  AndroidApiLevelName: Z (TaskId:7)
	  TargetFrameworkVersion: v108.1.99 (TaskId:7)
	  SupportedApiLevel: 127 (TaskId:7)
	  ...

Note that in the repro, API-127 ("Z") is *Unstable* (as per
`AndroidApiInfo.xml`), yet it's used for the build.

The cause is due to our logic to calculate
`AndroidVersions.MaxStableVersion`. The first time through the
`AndroidVersions.LoadVersions()` method the
`AndroidVersions.MaxStableVersion` property will *always* be `null`.
As a result the *first* `version` value would *always* be assigned to
`AndroidVersions.MaxStableVersion`, even if not stable!

	// Old and busted
	foreach (var version in versions) {
	  installedVersions.Add (version);
	  if (MaxStableVersion == null || (version.Stable && MaxStableVersion.TargetFrameworkVersion < version.TargetFrameworkVersion)) {
	    MaxStableVersion = version;
	  ...

Whether or not `AndroidVersions.MaxStableVersion` *could* be unstable
was dependent on the order of directory traversal, which isn't sorted
(nor should it be!), meaning behavior could *also be random*. (Fun!)

If `AndroidVersions.MaxStableVersion` *were* an unstable API level,
xamarin-android builds when `$(AndroidUseLatestPlatformSdk)`=True
would be unpredictable, as an API binding with no API compatibility
requirements could be used.

The fix is to completely ignore unstable apis. This way the first
stable api we find will be the first value we assign.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants