Api level 27 enumification #1045
Merged
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
atsushieno
added
the
use-merge-commit
Contributor
Author
|
This depends on #1044 |
atsushieno
force-pushed
the
api-level-27-enumification
branch
from
8994834 to
97c16c5
Compare
Contributor
|
This PR needs a xamarin-android-api-compatibility bump. |
Contributor
|
I do not understand how/why this PR depends on PR #1044. :-( |
Contributor
Author
|
Because, these changes were generated based on the changes on 1044. If we apply these changes without that PR, the technology we generated these changes are lost, and we cannot make further changes anymore. |
atsushieno
force-pushed
the
api-level-27-enumification
branch
2 times, most recently
from
8113543 to
fb57278
Compare
Contributor
Author
|
I'm feeling sorry but I brought somewhat messy situation here. PR #1044 is practically required but it expects map.csv changes that otherwise causes regression due to the fact that the changes contain API Level 27 changes brought by this PR. This PR with the updated xamarin-android-api-compatibility should cause no regression. So after merging this PR, #1044 will become green. So nominally PR #1044 now depends on this PR while this PR depends on that in practice. Therefore, could this PR be merged first and then go for 1044? |
Contributor
Once it's green, Yes. |
Contributor
Author
|
Okay, it's green now. |
api-*.xml.in can be generated dynamically (up to [*1]) but enumification helper tools still depended on DroidDoc, meaning that we cannot remove package download dependencies. This fixes the situation by eliminating the dependencies. Especially it is easier to just parse api-*.xml.in to extract int consts from Java API. ... thought so? It turnd out to not be that easy. Unlike DroidDoc, api-*.xml.in does not contain "api-since" information, so we need to parse ALL the API XML. And they cannot be **precise** because we only have a subset of the API definitions. For example, "since API Level 1" now becomes "since API Level 10" because we don't have api-1.xml.in (not even api-4.xml.in). So they will become non-precise. (A slightly better possibility to "fix" this is to parse `android-sdk-whatever/platform-tools/api/api-versions.xml`, but it won't contain "already vanished" constants so it will be incomplete either. I didn't bother to do "better" so far. We don't need that for enumification.) Therefore, there is a lot of changes in `map.csv` to reflect those "insignificant" changes to remap "API since" column (e.g. from "1" to "10"). Regeneration from api-LEVEL.xml.in instead of DroidDoc has some other side effects; some consts are back to the list so that we don't have to manually copy existing mapped consts that could not be generated from the latest DroidDocs (due to disappearance) anymore. Instead we have to remove manually-mapped constants (either from the sources or `map.csv`). Therefore, a handful of heading lines in `map.csv` were removed, and some definitions in `enum-conversion-mappings.xml` are back. [*1] dotnet#1038
Contributor
Author
|
Let me actually rebase so that "use-merge-commit" makes better sense. |
atsushieno
force-pushed
the
api-level-27-enumification
branch
from
fb57278 to
914f95f
Compare
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Dec 6, 2017
Bumps to xamarin-android-api-compatibility/master/9cfa6cc9
When attempting to bump monodroid to use a recent xamarin-android, the
API consistency checks failed:
<h1>### API BREAK BETWEEN v4.3 and v4.4</h1>
...
<h3>Type Changed: Android.Views.Animations.Transformation</h3>
<p>Removed properties:</p>
<pre>
<span class='removed removed-property breaking' data-is-breaking>public static int TypeAlpha { get; set; }</span>
<span class='removed removed-property breaking' data-is-breaking>public static int TypeBoth { get; set; }</span>
<span class='removed removed-property breaking' data-is-breaking>public static int TypeIdentity { get; set; }</span>
<span class='removed removed-property breaking' data-is-breaking>public static int TypeMatrix { get; set; }</span>
</pre>
This breakage was introduced by commit 9a73c4c/PR dotnet#1045, which
unfortunately wasn't caught at the time.
Specifically, commit a301764:
diff --git a/src/Mono.Android/map.csv b/src/Mono.Android/map.csv
index 74319bc..dc707d0 100644
--- a/src/Mono.Android/map.csv
+++ b/src/Mono.Android/map.csv
...
-1,Android.Views.Animations.TransformationTypes,Alpha,android/view/animation/Transformation.TYPE_ALPHA,1
...
+19,Android.Views.Animations.TransformationTypes,Alpha,android/view/animation/Transformation.TYPE_ALPHA,1
Update `src/Mono.Android/map.csv` so that `Transformation.TYPE_ALPHA` and
related enum values are changed in API-18+, not API-19+. This fixes the
inter-API-level compatibility issue.
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
3 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.