Repository navigation
Android Gradle build failed with Zip64NotSupportedException #976
Copy link
Copy link
Open
Labels
externalpriority:p1High priority/Major issue but not blocking or Big percentage of customers affected.Bug SLA <=7daysHigh priority/Major issue but not blocking or Big percentage of customers affected.Bug SLA <=7daystype:bugA broken experienceA broken experience
Description
Expected behavior
Successful Android app build with msgraph-beta-sdk-java dependency
Actual behavior
When we try to build an Android App with msgraph-beta-sdk-java dependency we got Zip64NotSupportedException:
Caused by: com.android.tools.build.apkzlib.zip.compress.Zip64NotSupportedException: Zip64 EOCD locator found but Zip64 format is not supported: /Users/user/.gradle/caches/8.8/transforms/9fd679e3e134568b95e9ec02cc0912f4/transformed/jetified-microsoft-graph-beta-6.13.0.jar
at com.android.builder.files.ZipCentralDirectory.readCentralDirectoryRecord(ZipCentralDirectory.kt:145)
at com.android.builder.files.ZipCentralDirectory.initBuffer(ZipCentralDirectory.kt:76)
at com.android.builder.files.ZipCentralDirectory.access$initBuffer(ZipCentralDirectory.kt:38)
at com.android.builder.files.ZipCentralDirectory$directoryBuffer$2.invoke(ZipCentralDirectory.kt:47)
at com.android.builder.files.ZipCentralDirectory$directoryBuffer$2.invoke(ZipCentralDirectory.kt:47)
at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
at com.android.builder.files.ZipCentralDirectory.getDirectoryBuffer(ZipCentralDirectory.kt:47)
at com.android.builder.files.ZipCentralDirectory.readZipEntries(ZipCentralDirectory.kt:210)
at com.android.builder.files.ZipCentralDirectory.access$readZipEntries(ZipCentralDirectory.kt:38)
at com.android.builder.files.ZipCentralDirectory$entries$2.invoke(ZipCentralDirectory.kt:45)
at com.android.builder.files.ZipCentralDirectory$entries$2.invoke(ZipCentralDirectory.kt:45)
at kotlin.SynchronizedLazyImpl.getValue(LazyJVM.kt:74)
at com.android.builder.files.ZipCentralDirectory.getEntries(ZipCentralDirectory.kt:45)
at com.android.builder.files.RelativeFiles.fromZip(RelativeFiles.java:112)
at com.android.builder.merge.LazyIncrementalFileMergerInputs.load(LazyIncrementalFileMergerInputs.java:90)
... 40 more
Gradle Android Plugin version: 8.4.1
Gradle version: 8.8
Steps to reproduce the behavior
- Add msgraph-beta-sdk-java dependency to Android app project
- Use SDK in Android app source code
- Build Android App
Trying to build with and without Proguard enabled but got the same error
P.S. It looks like this issue is related to the beta Java SDK. Can successfully build Android App with msgraph-sdk-java dependency.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
externalpriority:p1High priority/Major issue but not blocking or Big percentage of customers affected.Bug SLA <=7daysHigh priority/Major issue but not blocking or Big percentage of customers affected.Bug SLA <=7daystype:bugA broken experienceA broken experience
Activity
Ndiritu commentedon Jun 11, 2024
Thanks for reporting this Vladyslav Heneraliuk (@vheneraliuk).
Just to be clear on your build attempts with Proguard disabled, do you disable your ProGuard files as well as set
minifyEnabledandshrinkResourcestofalse? Does this still throw the exception?vheneraliuk commentedon Jun 11, 2024
Yes, I can confirm I'm getting the same exception with
minifyEnabledandshrinkResourcesboth set tofalseNdiritu commentedon Jun 12, 2024
(Triage notes)
slowcar commentedon May 23, 2025
Any update on this? Found this issue as my build fails with the same error message after adding the beta sdk
Zip64 EOCD locator found but Zip64 format is not supported: C:\Users\user.gradle\caches\modules-2\files-2.1\com.microsoft.graph\microsoft-graph-beta\6.45.0\a5b7a676a0c8919478a734bfb482f04ec5b95947\microsoft-graph-beta-6.45.0.jar
baywet commentedon Jun 2, 2025
Hey everyone,
We've had significant reorganization of the team and this fell through the cracks, apologies.
The library needs zip64 to be enabled since it has many more files than 65k once built.
Why are you experiencing a different behaviour with v1? I'm suspecting that even though the same setting is enabled in v1, because we might be under the 65k limit, the jar ends up being "regular zip".
Now, it seems that this could be also related to the version of the android SDK in use, and the plugins. So I encourage you to report which versions you're using, try upgrading and see if that makes a difference.
slowcar commentedon Jun 4, 2025
I am on Android Studio 2024.3.2 Patch 1 (22.05.2025), Gradle 8.9.2, Wrapper 8.12-bin
I did not find anything related to zip64 in the gradle release notes.
Can you use the library with an Android project or is the Android toolchain no longer part of the test cases since the graph android sdk was discontinued?
baywet commentedon Jun 4, 2025
On the support question: the old android SDK is NOT supported anymore, and hasn't been for a while. The current Java SDK (v1/beta) are fully supported for java applications (server, desktop, etc...) and we provide some level of support with it for android applications (multiple teams at Microsoft use it to build Microsoft applications on Android). While we've been able to automate some tests (like checking we're not using APIs that require an android API level above 26), some other tests are done manually (like creating a new android application with the SDK) in "important times" (like new major releases). What's most likely happened here is that we did go through that test during the initial release, and then the SDK grew to a point where packaging switched to zip64.
I've spent some time investigating this and I can confirm I'm able to reproduce it (for beta only) with the latest version of Android studio (2024.3.2.15), gradle 8.14.1, in a new application (simple activity, level 26), even after upgrading all dependencies to latest stable.
Looking further into this problem, I managed to find a two years old issue on Google's side, which was never triaged properly due to lack of information. Information which I've provided, my hope is that with this (and maybe upvotes from anybody reading this), it'll re-active the issue to get triaged properly, so the can implement zip64 support.
https://issuetracker.google.com/issues/296794709
Besides upvoting that issue, here is a workaround for anybody using Microsoft Graph Beta APIs in an android application: generate your own SDK with the same generator we use to produce this SDK.
You'll essentially get the same experience (API surface), but only for the parts of the API you care about.
Let us know if you have any additional comments or questions.
slowcar commentedon Sep 16, 2025
Could i ask what command exactly is used to generate the client?
I have succeeded in building the sdk with kiota, but the generated class ContactsRequestBuilder does not contain a get request (and related inner classes) while the one in this project does.
This is the command i use:
./kiota generate --openapi https://aka.ms/graph/beta/openapi.yaml --language Java --class-name BaseGraphServiceClient --namespace-name com.microsoft.graph.beta --include-path /contacts/** --include-path /models/** --include-path /users/** --include-path /groups/** --backing-store --clean-output
baywet commentedon Sep 16, 2025
Thank you for the additional information.
That's most likely because of the filters and the fact that contact does not have a trailing slash in the description.
Add another include with /contacts (no trailing slash)
slowcar commentedon Sep 16, 2025
Thanks, that worked.
I have copied the CustomBatchRequestBuilder and GraphServiceClient from the git project, the rest is now generated.
slowcar commentedon Sep 24, 2025
Is there an update to the proguard rules for the kiota generated classes?
in https://github.com/microsoftgraph/msgraph-beta-sdk-java/blob/main/docs/proguard-rules.txt there is
but IJsonBackedObject no longer exists.
Is it sufficient to replace it with com.microsoft.kiota.store.BackedModel or are there others i have to add?
baywet commentedon Sep 24, 2025
Thank you for pointing this out. We probably forgot to update this file during the release of the last major version.
I think in this file anything Gson can be removed because we don't use attributes anymore.
This probably needs to be added with an entry for the different Kiota namespaces.
Once you figure out the correct configuration will be more than happy to take a request to update it.
There is probably the same file to update as well for V1.