ERROR: Packaging Android Resources in <target> failed: (Exit 1)

When using rules_android 0.7.1 on a big codebase, we are getting an error Too many open files. Happens on the PackageAndroidResources action.

Things we have tried (didn't work):

Added -XX:+MaxFDLimit to the jvm_flags in java.bzl's _run method.

Things we have tried (worked for is):

Calling ulimit -n 65536 here.
Adjusting the ResourceLinker to merge .zip files in batches.

Dev env. and tools:

Using patched bazel 7.7.1
Using rules_android 0.7.1 (including this patch: Bencodes@cc2c826).
OS: Tahoe 26.2

Adjusting the ResourceLinker to merge .zip files in batches.

This sounds interesting. Do you have a PR for this?

Adjusting the ResourceLinker to merge .zip files in batches.

This sounds interesting. Do you have a PR for this?

There's no PR, just tried it locally.

We also hit the same error when using mi-v3 on a large codebase. The error happens for DesugarDexSharding action.

Thanks for the update. It sounds like the easiest fix is to batch the file list in PackageAndroidResources from the tool perspective. Do you have a gigantic number of transitive resources or something? We haven't hit this limit internally.

yes our production app is big (don't have exact number thou). Any chance that batch merging logic can be used for DesugarDexSharding as well? We are consistently hitting it. ulimit -n workaround didn't help in this case.

Do you have a stack trace for DesugarDexSharding's crash? I'd prefer not to add this batching logic everywhere in the codebase. I suspect that these two tools are not the only ones that would be affected by a gigantic number of resource files...

Here's the snippet (let me know if that's not enough)

ERROR: non zero exit: worker spawn failed for DesugarDexSharding
java.lang.IllegalStateException: Desugar failed with exit code: 1
        at com.google.devtools.build.android.DesugarDexShardingAction.desugar(DesugarDexShardingAction.java:166)
        at com.google.devtools.build.android.DesugarDexShardingAction.processRequest(DesugarDexShardingAction.java:391)
        at com.google.devtools.build.android.DesugarDexShardingAction.processRequestForWorker(DesugarDexShardingAction.java:335)
        at com.google.devtools.build.android.DesugarDexShardingAction.lambda$runPersistentWorker$0(DesugarDexShardingAction.java:319)
        at com.google.devtools.build.lib.worker.WorkRequestHandler$WorkRequestCallback.apply(WorkRequestHandler.java:252)
        at com.google.devtools.build.lib.worker.WorkRequestHandler.respondToRequest(WorkRequestHandler.java:480)
        at com.google.devtools.build.lib.worker.WorkRequestHandler.lambda$startResponseThread$1(WorkRequestHandler.java:433)
        at java.base/java.lang.Thread.run(Thread.java:1583)
bazel-out/darwin_arm64-dbg-android-ST-e30d6f35036d/bin/<redacted path>/example.abi.jar
java.io.UncheckedIOException: bazel-out/darwin_arm64-dbg-android-ST-e30d6f35036d/bin/<redacted path>/example.abi.jar
        at com.android.tools.r8.ArchiveClassFileProvider.d(R8_8.9.35_b4dbea2f8bdfdf2cab3ae611558fd558945d3a458bfc50ef035fc9f5ad630d56:22)
        at com.android.tools.r8.ArchiveClassFileProvider.c(R8_8.9.35_b4dbea2f8bdfdf2cab3ae611558fd558945d3a458bfc50ef035fc9f5ad630d56:4)
        at com.android.tools.r8.ArchiveClassFileProvider.<init>(R8_8.9.35_b4dbea2f8bdfdf2cab3ae611558fd558945d3a458bfc50ef035fc9f5ad630d56:27)
        at com.android.tools.r8.ArchiveClassFileProvider.<init>(R8_8.9.35_b4dbea2f8bdfdf2cab3ae611558fd558945d3a458bfc50ef035fc9f5ad630d56:1)
        at com.google.devtools.build.android.r8.Desugar.desugar(Desugar.java:449)
        at com.google.devtools.build.android.r8.Desugar.processRequest(Desugar.java:604)
        at com.google.devtools.build.android.DesugarDexShardingAction.desugar(DesugarDexShardingAction.java:164)
        at com.google.devtools.build.android.DesugarDexShardingAction.processRequest(DesugarDexShardingAction.java:391)

I think the desugar-related file descriptor limit might be difficult to fix or work around. It sounds like the problem is that there are too many files inside the input jar. I'm not sure how we'd properly batch that, since there may be inter-class references, and selecting the wrong batch of classfiles for batch desugaring could cause problems.

@ted-xie

@ted-xie one way we were able to resolve the MI issue is by adding -XX:-MaxFDLimit to BASE_JVMOPTS.

I can a separate issue for MI error in order to have them tracked separately. let me know.
EDIT: Separate issue #484

Navigation Menu

Repository navigation

ERROR: Packaging Android Resources in <target> failed: (Exit 1) #449

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

ERROR: Packaging Android Resources in <target> failed: (Exit 1) #449

Description

Activity

ted-xie commented on Mar 18, 2026

snazhmudinov commented on Mar 22, 2026

snazhmudinov commented on Apr 13, 2026

ted-xie commented on Apr 13, 2026

snazhmudinov commented on Apr 13, 2026

ted-xie commented on Apr 13, 2026

snazhmudinov commented on Apr 13, 2026

ted-xie commented on Apr 13, 2026

snazhmudinov commented on Apr 14, 2026

snazhmudinov commented on Apr 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions