Skip to content

Commit

Permalink
[Xamarin.Android.Build.Tasks] unable to open file as zip archive? (#…
Browse files Browse the repository at this point in the history
…7759)

Fixes? #6067

Context: https://gist.github.com/grendello/55b9a74c80c611dd48b726ee6f16d3c9
Context: dotnet/android-libzipsharp#125

Context: #7622

Changes: https://github.com/xamarin/monodroid/compare/50faac94c6a0c27864564829ac83f3988c82f8ef...602aca98245744882a129206b79b5a5e093dae44

  * xamarin/monodroid@602aca982: Bump androidtools for new LibZipSharp (xamarin/monodroid#1287)
  * xamarin/monodroid@1f52d5873: [tools/msbuild] Deploy *resources.dll from PackageReference (xamarin/monodroid#1276)

Changes: xamarin/androidtools@f11d163...c0bcb66

  * xamarin/androidtools@c0bcb66: Bump xamarin-android-tools for new LibZipSharp (xamarin/androidtools#377)

Changes: dotnet/android-tools@099fd95...dbe42bf

  * dotnet/android-tools@dbe42bf: Bump LibZipSharp version (dotnet/android-tools#204)

Sometimes in our tests we see an error from LibZipSharp which claims
a file cannot be opened as a valid ZIP archive:

	error ANDZA0000: Unable to open '…/example.apk' as zip archive

The reason for this is ZIP format corruption happening sometimes in
the `<BuildApk/>` task.

The way the process works is that we first run `aapt2` to produce
an APK archive named `packaged_resources`, which we then copy to the
destination APK (using standard `File.Copy()`) and open it to append
our content.  The first item we always append is the `classes.dex`
file which is also the **only** corrupted entry in the broken APK
files.

ZIP files contain two records describing each entry in the archive:

 1. in the Central Directory (located at the end of the file)

 2. local header in the ZIP data stream, offset of which is contained
    in the above Central Directory record.

After close examination, it appears that the broken APK files contain
(1) for `classes.dex` but not (2).  Instead of (2) we see a *copy*
of `packaged_resource` package's Central Directory record:

	% zipinfo -vv example.apk
	…
	Central directory entry #9:
	---------------------------

	  There are an extra 2 bytes preceding this file.

	  classes.dex

	  offset of local header from start of archive:   21680
	…

In particular, "There are an extra 2 bytes preceding this file" is a
sign that something "isn't right".  If we use `hexdump` to look at
the 128 bytes starting at offset 21680:

	% hexdump -C -s 21680 -n 128 example.apk 
	000054b0  50 4b 01 02 00 00 00 00  00 00 08 00 00 00 21 00  |PK............!.|
	000054c0  5e b2 00 5e cc 03 00 00  5c 0b 00 00 13 00 00 00  |^..^....\.......|
	000054d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 41 6e  |..............An|
	000054e0  64 72 6f 69 64 4d 61 6e  69 66 65 73 74 2e 78 6d  |droidManifest.xm|
	000054f0  6c 50 4b 01 02 00 00 00  00 00 00 00 00 00 00 21  |lPK............!|
	00005500  00 5c 71 d9 26 d2 05 00  00 d2 05 00 00 1d 00 00  |.\q.&...........|
	00005510  00 00 00 00 00 00 00 00  00 00 00 fd 03 00 00 72  |...............r|
	00005520  65 73 2f 64 72 61 77 61  62 6c 65 2d 6d 64 70 69  |es/drawable-mdpi|

we see that it starts with "PK", the common magic signature for zip
archives, and the following bytes { 0x1 0x2 } indicate that this is a
*central directory* entry, while it *should* be { 0x3, 0x4 } for a
*local header* entry.

The corruption may be caused by invalid stream position after we open
the `packaged_resources` copy and append `classes.dex` entry to it;
see dotnet/android-libzipsharp#125 for details.

We believe that the changes to `ZipArchive.stream_callback()` in
dotnet/android-libzipsharp#125 alongside additional calls to `Flush()` after
adding `classex.dex` **may** fix the problem.

If it doesn't, we should consider copying data from
`packaged_resources` to the final APK entry by entry by decompressing
them from the original archive and adding them to the destination one.
  • Loading branch information
grendello authored Feb 28, 2023
1 parent 922a369 commit 0b2a982
Show file tree
Hide file tree
Showing 4 changed files with 4 additions and 3 deletions.
2 changes: 1 addition & 1 deletion .external
Original file line number Diff line number Diff line change
@@ -1,2 +1,2 @@
xamarin/monodroid:main@50faac94c6a0c27864564829ac83f3988c82f8ef
xamarin/monodroid:main@602aca98245744882a129206b79b5a5e093dae44
mono/mono:2020-02@6dd9def57ce969ca04a0ecd9ef72c0a8f069112d
2 changes: 1 addition & 1 deletion Directory.Build.props
Original file line number Diff line number Diff line change
Expand Up @@ -40,7 +40,7 @@

<!-- Common <PackageReference/> versions -->
<PropertyGroup>
<LibZipSharpVersion>2.0.7</LibZipSharpVersion>
<LibZipSharpVersion>2.1.0</LibZipSharpVersion>
<MicroBuildCoreVersion>1.0.0</MicroBuildCoreVersion>
<MonoCecilVersion>0.11.4</MonoCecilVersion>
<NewtonsoftJsonPackageVersion>13.0.1</NewtonsoftJsonPackageVersion>
Expand Down
2 changes: 1 addition & 1 deletion external/xamarin-android-tools
1 change: 1 addition & 0 deletions src/Xamarin.Android.Build.Tasks/Tasks/BuildApk.cs
Original file line number Diff line number Diff line change
Expand Up @@ -183,6 +183,7 @@ void ExecuteWithAbi (string [] supportedAbis, string apkInputPath, string apkOut
string apkName = dex.GetMetadata ("ApkName");
string dexPath = string.IsNullOrWhiteSpace (apkName) ? Path.GetFileName (dex.ItemSpec) : apkName;
AddFileToArchiveIfNewer (apk, dex.ItemSpec, DalvikPath + dexPath, compressionMethod: dexCompressionMethod);
apk.Flush ();
}

if (EmbedAssemblies && !BundleAssemblies) {
Expand Down

0 comments on commit 0b2a982

Please sign in to comment.