Rando ANDZA0000: Unable to open app.apk as a zip archive #6067
Assignees
Labels
Area: App+Library Build
Issues when building Library projects or Application projects.
bug
Component does not function as intended.
Milestone
Comments
jonpryor
added
Area: App+Library Build
|
Other ways to diagnose: $ unzip -t com.xamarin.debuggerattribute.apk
Archive: com.xamarin.debuggerattribute.apk
testing: AndroidManifest.xml OK
testing: res/drawable-mdpi-v4/icon.png OK
testing: res/drawable-hdpi-v4/icon.png OK
testing: res/drawable-xhdpi-v4/icon.png OK
testing: res/drawable-xxhdpi-v4/icon.png OK
testing: res/drawable-xxxhdpi-v4/icon.png OK
testing: res/layout/main.xml OK
testing: resources.arsc OK
file #9: bad zipfile offset (local header sig): 51032
testing: lib/arm64-v8a/libxamarin-app.so OK
testing: lib/x86/libxamarin-app.so OK
testing: lib/arm64-v8a/libSystem.IO.Compression.Native.so OK
testing: lib/arm64-v8a/libSystem.Native.so OK
testing: lib/arm64-v8a/libSystem.Security.Cryptography.Native.Android.so OK
testing: lib/arm64-v8a/libmonosgen-2.0.so OK
testing: lib/arm64-v8a/libmonodroid.so OK
testing: lib/arm64-v8a/libxamarin-debug-app-helper.so OK
testing: lib/x86/libSystem.IO.Compression.Native.so OK
testing: lib/x86/libSystem.Native.so OK
testing: lib/x86/libSystem.Security.Cryptography.Native.Android.so OK
testing: lib/x86/libmonosgen-2.0.so OK
testing: lib/x86/libmonodroid.so OK
testing: lib/x86/libxamarin-debug-app-helper.so OK
At least one error was detected in com.xamarin.debuggerattribute.apk.
Central directory entry #9:
---------------------------
There are an extra 2 bytes preceding this file.
classes.dex
offset of local header from start of archive: 51032
(000000000000C758h) bytes
file system or operating system of origin: Unix
version of encoding software: 6.3
minimum file system compatibility required: MS-DOS, OS/2 or NT FAT
minimum software version required to extract: 2.0
compression method: deflated
compression sub-type (deflation): maximum
file security status: not encrypted
extended local header: no
file last modified on (DOS date/time): 2021 Jul 1 08:50:32
32-bit CRC value (hex): ec5ca9fd
compressed size: 72278 bytes
uncompressed size: 317776 bytes
length of filename: 11 characters
length of extra field: 0 bytes
length of file comment: 0 characters
disk number on which file begins: disk 1
apparent file type: binary
Unix file attributes (100644 octal): -rw-r--r--
MS-DOS file attributes (00 hex): none
There is no file comment.
Central directory entry #10:
---------------------------
There are an extra 9 bytes preceding this file.
lib/arm64-v8a/libxamarin-app.so |
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Jul 2, 2021
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Jul 6, 2021
|
We have another apparent instance of this bug: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=4979360&view=ms.vss-test-web.build-test-results-tab&runId=23547392&resultId=100040&paneView=attachments |
dellis1972
added a commit
to dellis1972/xamarin-android
that referenced
this issue
Aug 5, 2021
jonpryor
pushed a commit
that referenced
this issue
Feb 28, 2023
…7759) Fixes? #6067 Context: https://gist.github.com/grendello/55b9a74c80c611dd48b726ee6f16d3c9 Context: dotnet/android-libzipsharp#125 Context: #7622 Changes: http://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.
|
We think (hope? pray?) that this was fixed by PR #7759. |
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
It's our favorite, hysenbugs!
There is no repro!
Context:
Sometimes, the
DebuggerAttribute"Full", False, True)unit test (and others?) will fail:The cause of the error is that
zipaligndoesn't like the file:The file does exist; it is attached here as com.xamarin.debuggerattribute.zip.
Aside:
zipalignsource: https://android.googlesource.com/platform/build.git/+/refs/heads/master/tools/zipalign/Lots of spitballing and investigation later, and we we see that
zipdetails -vvdoesn't like it:It appears that either the
resources.arscentry, or the followingclasses.dexentry, is somehow broken;7zipreports:Something isn't kosher here.
@grendello eventually concludes:
It looks like this is due to something we're doing, but we're not sure what, why, or how to fix it.
The text was updated successfully, but these errors were encountered: