[LibZipSharp] Android projects which use Support packages are failing to build on Windows due issue extracting resources #134
Conversation
This file contains 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
… to build on Windows due issue extracting resources Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=42835 Fixes an issue where IsDirectory was returning false for directories. This is because while the Size is 0 the compressed size is NOT 0. This is probably because the data has to be stored somehow in the zip :). So for directories we'll check that the Size is zero and that the string ends in a '/' Ths commit Bumps the submodule for LibZipSharp to bring in the fix.
radekdoulik
pushed a commit
to radekdoulik/xamarin-android
that referenced
this pull request
Aug 12, 2016
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=42835 Android projects which use the Support packages are failing to build on Windows due an issue where IsDirectory was returning false for directories. This is because while the Size is 0 the compressed size is NOT 0. This is probably because the data has to be stored somehow in the zip :). So for directories we'll check that the Size is zero and that the string ends in a '/' Ths commit Bumps the submodule for LibZipSharp to bring in the fix.
radical
pushed a commit
that referenced
this pull request
May 8, 2018
api-O.xml.in will have `<typeParameters/>` in `<constructor/>` It is because some types have `Class<T>` as some arguments to the contructor and to resolve that `T` the API describes it.
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Sep 15, 2021
Changes: https://github.com/xamarin/xamarin-android-tools/compare/9b658b29bd41157151f5515619d0d90dc062563d...440e6bee787e979e5cf8e23d50ee22025ae7b506 * dotnet/android-tools@440e6be [Xamarin.Android.Tools.AndroidSdk] Update SDK component for API-31 (dotnet#134)
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Sep 15, 2021
Changes: https://github.com/xamarin/xamarin-android-tools/compare/9b658b29bd41157151f5515619d0d90dc062563d...a5194e93498e7f12225d87e2811415a45f742116 * dotnet/android-tools@a5194e9: [Xamarin.Android.Tools.AndroidSdk] Downgrade build-tools to API-30 * dotnet/android-tools@440e6be: [Xamarin.Android.Tools.AndroidSdk] Update SDK component for API-31 (dotnet#134)
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Sep 16, 2021
Context: https://developer.android.com/studio/releases/platform-tools Changes: https://github.com/xamarin/xamarin-android-tools/compare/9b658b29bd41157151f5515619d0d90dc062563d...a5194e93498e7f12225d87e2811415a45f742116 * dotnet/android-tools@a5194e9: [Xamarin.Android.Tools.AndroidSdk] Downgrade build-tools to API-30 * dotnet/android-tools@440e6be: [Xamarin.Android.Tools.AndroidSdk] Update SDK component for API-31 (dotnet#134) One of the (undocumented) changes between Android SDK Platform-tools package r30.0.4 and r31.0.3 is that `platform-tools/api/annotations.zip` was *removed*. This removal would cause the `_GenerateBinding` target in `Mono.Android.targets` to fail, as it's used by `generator.exe --annotations`: mono --debug=casts "/Users/builder/azdo/_work/2/s/xamarin-android/bin/Release/lib/xamarin.android/xbuild/Xamarin/Android/generator.exe" \ --annotations="/Users/builder/Library/Android/sdk/platform-tools/api/annotations.zip" \ … … error BG0000: System.IO.DirectoryNotFoundException: Could not find a part of the path "/Users/builder/Library/Android/sdk/platform-tools/api/annotations.zip". at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share, System.Int32 bufferSize, System.Boolean anonymous, System.IO.FileOptions options) at System.IO.FileStream..ctor (System.String path, System.IO.FileMode mode, System.IO.FileAccess access, System.IO.FileShare share) at (wrapper remoting-invoke-with-check) System.IO.FileStream..ctor(string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare) at System.IO.File.OpenRead (System.String path) at Xamarin.AndroidTools.AnnotationSupport.AndroidAnnotationsSupport.ParseArchive (System.String file) at Xamarin.AndroidTools.AnnotationSupport.AndroidAnnotationsSupport.Load (System.String annotationsZipFile) at Xamarin.Android.Binder.CodeGenerator.GenerateAnnotationAttributes (System.Collections.Generic.List`1[T] gens, System.Collections.Generic.IEnumerable`1[T] zips) at Xamarin.Android.Binder.CodeGenerator.Run (Xamarin.Android.Binder.CodeGeneratorOptions options, Java.Interop.Tools.Cecil.DirectoryAssemblyResolver resolver) at Xamarin.Android.Binder.CodeGenerator.Run (Xamarin.Android.Binder.CodeGeneratorOptions options) at Xamarin.Android.Binder.CodeGenerator.Main (System.String[] args) `annotations.zip` has apparently moved into the platform package, and has been there since API-26: % ls -1tr ~/android-toolchain/sdk/platforms/*/data/annotations.zip $HOME/android-toolchain/sdk/platforms/android-26/data/annotations.zip $HOME/android-toolchain/sdk/platforms/android-27/data/annotations.zip $HOME/android-toolchain/sdk/platforms/android-28/data/annotations.zip $HOME/android-toolchain/sdk/platforms/android-29/data/annotations.zip $HOME/android-toolchain/sdk/platforms/android-30/data/annotations.zip $HOME/android-toolchain/sdk/platforms/android-31/data/annotations.zip Update the `_GenerateBinding` target so that the "new" platform copy of `annotations.zip` is used, if present.
jonpryor
added a commit
to jonpryor/xamarin-android
that referenced
this pull request
Sep 20, 2021
Context: dotnet#6300 Context: dotnet/java-interop#883 Changes: https://github.com/xamarin/xamarin-android-tools/compare/9b658b29bd41157151f5515619d0d90dc062563d...a5194e93498e7f12225d87e2811415a45f742116 * dotnet/android-tools@a5194e9: [Xamarin.Android.Tools.AndroidSdk] Downgrade build-tools to API-30 * dotnet/android-tools@440e6be: [Xamarin.Android.Tools.AndroidSdk] Update SDK component for API-31 (dotnet#134) Note: while this xamarin-android-tools bump updates the Android SDK [Platform Tools][0] version to 31.0.3, we are *not* updating `$(XAPlatformToolsVersion)` to 31.0.3. As such, there will be a mismatch between what we build xamarin-android against, vs. the default suggested platform-tools package potentially installed via the `/t:InstallAndroidDependencies` target. The reason to *not* bump `$(XAPlatformToolsVersion)` is that attempting to do so breaks the `src/Mono.Android` build: 1. platform-tools r31.0.3 doesn't contain `platform-tools/api/annotations.zip`, which is used by `generator` to emit certain custom attributes such as `RequiresPermission`. 2. While (1) can be worked around by instead using `$(AndroidSdkDirectory)/platforms/android-*/data/annotations.zip`, this introduces API changes reported by the `_CheckApiCompatibility` target, in particular changes due to custom attribute string changes. These string changes happen because Google ships *invalid XML* in `data/annotations.zip` for API-29+ (?!): <!-- annotations.zip!android/accounts/annotations.xml --> - <item name="android.accounts.AccountManager android.accounts.AccountManagerFuture<android.os.Bundle> addAccount(java.lang.String, java.lang.String, java.lang.String[], android.os.Bundle, android.app.Activity, android.accounts.AccountManagerCallback<android.os.Bundle>, android.os.Handler)"> + <item name="android.accounts.AccountManager android.accounts.AccountManagerFuture<android.os.Bundle> addAccount(java.lang.String, java.lang.String, java.lang.String[], android.os.Bundle, android.app.Activity, android.accounts.AccountManagerCallback<android.os.Bundle>, android.os.Handler)"> `AccountManagerCallback<android.os.Bundle>` is not a valid value within an XML attribute. This change doesn't break the build, but instead causes [`AndroidAnnotationSupport`][1] to hit a "fallback" codepath which uses HtmlAgilityPack, and this causes attribute values to "gain" `quot;`: -[global::Android.Runtime.RequiresPermission ("android.permission.MANAGE_ACCOUNTS")] +[global::Android.Runtime.RequiresPermission ("quot;android.permission.MANAGE_ACCOUNTS"")] See also: dotnet/java-interop#883 After manual review, no other file removals appear to be problematic, so @jonpryor asserts that it should be acceptable for `$(XAPlatformToolsVersion)` and `$(AndroidSdkPlatformToolsVersion)` to be inconsistent with each other. [0]: https://developer.android.com/studio/releases/platform-tools [1]: https://github.com/xamarin/java.interop/blob/1e8f5137345db3160c99265ff3a56c43a132194f/src/Xamarin.Android.Tools.AnnotationSupport/AndroidAnnotationsSupport.cs#L58-L87
jonpryor
added a commit
that referenced
this pull request
Sep 20, 2021
Context: #6300 Context: dotnet/java-interop#883 Changes: https://github.com/xamarin/xamarin-android-tools/compare/9b658b29bd41157151f5515619d0d90dc062563d...a5194e93498e7f12225d87e2811415a45f742116 * dotnet/android-tools@a5194e9: [Xamarin.Android.Tools.AndroidSdk] Downgrade build-tools to API-30 * dotnet/android-tools@440e6be: [Xamarin.Android.Tools.AndroidSdk] Update SDK component for API-31 (#134) Note: while this xamarin-android-tools bump updates the Android SDK [Platform Tools][0] version to 31.0.3, we are *not* updating `$(XAPlatformToolsVersion)` to 31.0.3. As such, there will be a mismatch between what we build xamarin-android against, vs. the default suggested platform-tools package potentially installed via the `/t:InstallAndroidDependencies` target. The reason to *not* bump `$(XAPlatformToolsVersion)` is that attempting to do so breaks the `src/Mono.Android` build: 1. platform-tools r31.0.3 doesn't contain `platform-tools/api/annotations.zip`, which is used by `generator` to emit certain custom attributes such as `RequiresPermission`. 2. While (1) can be worked around by instead using `$(AndroidSdkDirectory)/platforms/android-*/data/annotations.zip`, this introduces API changes reported by the `_CheckApiCompatibility` target, in particular changes due to custom attribute string changes. These string changes happen because Google ships *invalid XML* in `data/annotations.zip` for API-29+ (?!): <!-- annotations.zip!android/accounts/annotations.xml --> - <item name="android.accounts.AccountManager android.accounts.AccountManagerFuture<android.os.Bundle> addAccount(java.lang.String, java.lang.String, java.lang.String[], android.os.Bundle, android.app.Activity, android.accounts.AccountManagerCallback<android.os.Bundle>, android.os.Handler)"> + <item name="android.accounts.AccountManager android.accounts.AccountManagerFuture<android.os.Bundle> addAccount(java.lang.String, java.lang.String, java.lang.String[], android.os.Bundle, android.app.Activity, android.accounts.AccountManagerCallback<android.os.Bundle>, android.os.Handler)"> `AccountManagerCallback<android.os.Bundle>` is not a valid value within an XML attribute. This change doesn't break the build, but instead causes [`AndroidAnnotationSupport`][1] to hit a "fallback" codepath which uses HtmlAgilityPack, and this causes attribute values to "gain" `quot;`: -[global::Android.Runtime.RequiresPermission ("android.permission.MANAGE_ACCOUNTS")] +[global::Android.Runtime.RequiresPermission ("quot;android.permission.MANAGE_ACCOUNTS"")] See also: dotnet/java-interop#883 After manual review, no other file removals appear to be problematic, so @jonpryor asserts that it should be acceptable for `$(XAPlatformToolsVersion)` and `$(AndroidSdkPlatformToolsVersion)` to be inconsistent with each other. [0]: https://developer.android.com/studio/releases/platform-tools [1]: https://github.com/xamarin/java.interop/blob/1e8f5137345db3160c99265ff3a56c43a132194f/src/Xamarin.Android.Tools.AnnotationSupport/AndroidAnnotationsSupport.cs#L58-L87
jonathanpeppers
pushed a commit
that referenced
this pull request
Sep 21, 2021
Context: #6300 Context: dotnet/java-interop#883 Changes: https://github.com/xamarin/xamarin-android-tools/compare/9b658b29bd41157151f5515619d0d90dc062563d...a5194e93498e7f12225d87e2811415a45f742116 * dotnet/android-tools@a5194e9: [Xamarin.Android.Tools.AndroidSdk] Downgrade build-tools to API-30 * dotnet/android-tools@440e6be: [Xamarin.Android.Tools.AndroidSdk] Update SDK component for API-31 (#134) Note: while this xamarin-android-tools bump updates the Android SDK [Platform Tools][0] version to 31.0.3, we are *not* updating `$(XAPlatformToolsVersion)` to 31.0.3. As such, there will be a mismatch between what we build xamarin-android against, vs. the default suggested platform-tools package potentially installed via the `/t:InstallAndroidDependencies` target. The reason to *not* bump `$(XAPlatformToolsVersion)` is that attempting to do so breaks the `src/Mono.Android` build: 1. platform-tools r31.0.3 doesn't contain `platform-tools/api/annotations.zip`, which is used by `generator` to emit certain custom attributes such as `RequiresPermission`. 2. While (1) can be worked around by instead using `$(AndroidSdkDirectory)/platforms/android-*/data/annotations.zip`, this introduces API changes reported by the `_CheckApiCompatibility` target, in particular changes due to custom attribute string changes. These string changes happen because Google ships *invalid XML* in `data/annotations.zip` for API-29+ (?!): <!-- annotations.zip!android/accounts/annotations.xml --> - <item name="android.accounts.AccountManager android.accounts.AccountManagerFuture<android.os.Bundle> addAccount(java.lang.String, java.lang.String, java.lang.String[], android.os.Bundle, android.app.Activity, android.accounts.AccountManagerCallback<android.os.Bundle>, android.os.Handler)"> + <item name="android.accounts.AccountManager android.accounts.AccountManagerFuture<android.os.Bundle> addAccount(java.lang.String, java.lang.String, java.lang.String[], android.os.Bundle, android.app.Activity, android.accounts.AccountManagerCallback<android.os.Bundle>, android.os.Handler)"> `AccountManagerCallback<android.os.Bundle>` is not a valid value within an XML attribute. This change doesn't break the build, but instead causes [`AndroidAnnotationSupport`][1] to hit a "fallback" codepath which uses HtmlAgilityPack, and this causes attribute values to "gain" `quot;`: -[global::Android.Runtime.RequiresPermission ("android.permission.MANAGE_ACCOUNTS")] +[global::Android.Runtime.RequiresPermission ("quot;android.permission.MANAGE_ACCOUNTS"")] See also: dotnet/java-interop#883 After manual review, no other file removals appear to be problematic, so @jonpryor asserts that it should be acceptable for `$(XAPlatformToolsVersion)` and `$(AndroidSdkPlatformToolsVersion)` to be inconsistent with each other. [0]: https://developer.android.com/studio/releases/platform-tools [1]: https://github.com/xamarin/java.interop/blob/1e8f5137345db3160c99265ff3a56c43a132194f/src/Xamarin.Android.Tools.AnnotationSupport/AndroidAnnotationsSupport.cs#L58-L87
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Fixes https://bugzilla.xamarin.com/show_bug.cgi?id=42835
Fixes an issue where IsDirectory was returning false for directories.
This is because while the Size is 0 the compressed size
is NOT 0. This is probably because the data has to be stored
somehow in the zip :).
So for directories we'll check that the Size is zero and that
the string ends in a '/'
Ths commit Bumps the submodule for LibZipSharp to bring in the fix.