InvalidPathException while making apks from signed bundle

[AhmadIzaz]

I am trying to make an apks from signed bundle generated from android studio but I am able to generated apks from debug bundle but when i am trying to do this from signed bundle , I am facing an issue. Here are the logs i am facing.

[BT:0.10.2] Error: java.nio.file.InvalidPathException: Trailing char < > at index 10: res/raw/??
java.lang.RuntimeException: java.nio.file.InvalidPathException: Trailing char < > at index 10: res/raw/??
at com.android.tools.build.bundletool.io.ConcurrencyUtils.waitFor(ConcurrencyUtils.java:59)
at com.android.tools.build.bundletool.io.ConcurrencyUtils.waitForAll(ConcurrencyUtils.java:42)
at java.base/java.util.function.Function.lambda$andThen$1(Function.java:88)
at java.base/java.util.stream.ReferencePipeline.collect(ReferencePipeline.java:582)
at com.android.tools.build.bundletool.io.ApkSerializerManager.serializeApks(ApkSerializerManager.java:180)
at com.android.tools.build.bundletool.io.ApkSerializerManager.populateApkSetBuilder(ApkSerializerManager.java:101)
at com.android.tools.build.bundletool.commands.BuildApksManager.executeWithZip(BuildApksManager.java:229)
at com.android.tools.build.bundletool.commands.BuildApksManager.execute(BuildApksManager.java:110)
at com.android.tools.build.bundletool.commands.BuildApksCommand.execute(BuildApksCommand.java:524)
at com.android.tools.build.bundletool.BundleToolMain.main(BundleToolMain.java:74)
at com.android.tools.build.bundletool.BundleToolMain.main(BundleToolMain.java:46)
Caused by: java.util.concurrent.ExecutionException: java.nio.file.InvalidPathException: Trailing char < > at index 10: res/raw/??
at com.google.common.util.concurrent.AbstractFuture.getDoneValue(AbstractFuture.java:502)
at com.google.common.util.concurrent.AbstractFuture.get(AbstractFuture.java:461)
at com.google.common.util.concurrent.AbstractFuture$TrustedFuture.get(AbstractFuture.java:83)
at com.android.tools.build.bundletool.io.ConcurrencyUtils.waitFor(ConcurrencyUtils.java:49)
... 10 more
Caused by: java.nio.file.InvalidPathException: Trailing char < > at index 10: res/raw/??
at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:191)
at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
at java.base/java.nio.file.Path.of(Path.java:147)
at java.base/java.nio.file.Paths.get(Paths.java:69)
at com.android.tools.build.bundletool.io.ApkSerializerHelper.lambda$shouldCompress$4(ApkSerializerHelper.java:309)
at java.base/java.util.stream.MatchOps$1MatchSink.accept(MatchOps.java:90)
at java.base/java.util.Spliterators$ArraySpliterator.tryAdvance(Spliterators.java:958)
at java.base/java.util.stream.ReferencePipeline.forEachWithCancel(ReferencePipeline.java:127)
at java.base/java.util.stream.AbstractPipeline.copyIntoWithCancel(AbstractPipeline.java:502)
at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:488)
at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:474)
at java.base/java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:230)
at java.base/java.util.stream.MatchOps$MatchOp.evaluateSequential(MatchOps.java:196)
at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:234)
at java.base/java.util.stream.ReferencePipeline.anyMatch(ReferencePipeline.java:528)
at com.android.tools.build.bundletool.io.ApkSerializerHelper.shouldCompress(ApkSerializerHelper.java:309)
at com.android.tools.build.bundletool.io.ApkSerializerHelper.entryOptionForPath(ApkSerializerHelper.java:294)
at com.android.tools.build.bundletool.io.ApkSerializerHelper.writeProtoApk(ApkSerializerHelper.java:254)
at com.android.tools.build.bundletool.io.ApkSerializerHelper.writeToZipFile(ApkSerializerHelper.java:155)
at com.android.tools.build.bundletool.io.ApkSerializerHelper.writeToZipFile(ApkSerializerHelper.java:144)
at com.android.tools.build.bundletool.io.SplitApkSerializer.writeToDisk(SplitApkSerializer.java:75)
at com.android.tools.build.bundletool.io.SplitApkSerializer.writeSplitToDisk(SplitApkSerializer.java:53)
at com.android.tools.build.bundletool.io.ApkSetBuilderFactory$ApkSetArchiveBuilder.addSplitApk(ApkSetBuilderFactory.java:105)
at com.android.tools.build.bundletool.io.ApkSerializerManager$ApkSerializer.serialize(ApkSerializerManager.java:376)
at com.android.tools.build.bundletool.io.ApkSerializerManager.lambda$null$3(ApkSerializerManager.java:184)
at com.google.common.util.concurrent.TrustedListenableFutureTask$TrustedFutureInterruptibleTask.runInterruptibly(TrustedListenableFutureTask.java:117)
at com.google.common.util.concurrent.InterruptibleTask.run(InterruptibleTask.java:38)
at com.google.common.util.concurrent.TrustedListenableFutureTask.run(TrustedListenableFutureTask.java:77)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:834)

[kvafy]

Looking at sources of JDK 8, it looks like one of your modules contains a file under res/raw which ends with a whitespace. Sanitizing file names should help.

[AhmadIzaz]

android studio does not let you create any file that end with white spaces. actually this is done by dexguard obfuscation, dexguard obfuscation is renaming the files and leaving space at then . I have tested that without dexguard i can make release apk but with that i keep getting this error. I have a lot of things to prevent but still same

[netomi]

This is a DexGuard related issue. By default only simple characters are used for obfuscation of resource files when building app bundles. Due to some bug, this configuration does not work with DexGuard 8.4 when building on Windows environments. This is fixed in DexGuard 8.5, this issue can be closed unless bundletool wants to support the usual UTF-8 characters that DexGuard uses for obfuscation purposes (I have nothing against that ;-)

[plecesne]

We'd love to fix it, but it's not an easy fix unfortunately. We rely on the OS Path matcher to match files that need to remain uncompressed. We would need to implement our own matcher possibly to address this, which is a heavy change.

[netomi]

From what I see at

bundletool/src/main/java/com/android/tools/build/bundletool/io/ApkSerializerHelper.java

Line 135 in 5ac94cb

this.uncompressedPathMatchers =

, you only seem to use the glob syntax. Would you be willing to accept a patch to replace the PatchMatcher use with something else? We use a quite powerful matching mechanism in ProGuard that fully supports this glob syntax and could put it under Apache license.

[plecesne]

Hey @netomi , that sounds like a good idea.
If you can publish a library with Apache 2.0 license on Maven, then I'd be OK having the OS file path matcher swapped with a call to that library.

[AhmadIzaz]

Yes @netomi I did report them that issue and they said that they will fix this and i received an email from them that we have fixed this in 8.5

[AhmadIzaz]

@netomi @plecesne Thanks

[netomi]

@AhmadIzaz they / DexGuard + me == same guys

[netomi]

Got confirmation that releasing this part of ProGuard under Apache license is ok. We use it for the very same purpose throughout the codebase (not only matching filenames but also for other purposes, e.g. classnames).

[plecesne]

I will run this by our security team.

[netomi]

I have created a repository at https://github.com/netomi/stringmatchers. It contains an implementation of a PathMatcher, some unit tests can found here: https://github.com/netomi/stringmatchers/blob/master/src/test/java/proguard/util/PathMatcherTest.java

The testStreams() method outlines the usage similar to the way bundletool uses the PathMatcher from the JDK atm, so it could be easily adapted.

Please let me know if this would be interesting for you, we can modify the code as you want, it currently committed with GPL license but we will be shortly releasing parts related to classfile handling of ProGuard under Apache license at https://github.com/guardsquare and these utilities will also be included. This is a stripped down version of the original class, removing everything that you probably dont want / need.

[kvafy]

@netomi , thank you for the wait. We are ready to move forward with adopting the stringmatchers library. Is netomi/stringmatchers going to be the official repository, or do you want to re-publish under the guardsquare account?

Either way, one requirement we have is publishing the library on Maven so that it can be consumed by the Gradle build.

[netomi]

Thanks for the feedback. We will publish it under the guardsquare account and push it also to maven if needed. Publishing it under my personal account was just done to speed up things and give you the chance to see if it would be suitable for your use-case.

In case you have any suggestions regarding the API we are happy to adjust as needed.

Regarding my statement with full compatibility of the glob syntax: I was not fully correct in this regard, the following pattern is not yet supported:

*.{java,class} | Matches file names ending with .java or .class

I assume this is not used atm, we can add it if you need it.

[kvafy]

Looking at the definition of a glob (here), there actually are more features that are currently not supported by the library:

• {optionA,optionB}
• [single.character], [a-z]
• escaped special characters

We're analyzing whether this syntax is actually being used at the moment.

[netomi]

I have updated the stringmatcher project to support braces ({optionA, optionB}) and brackets ([a-z]). We will further clean up this implementation, add unit tests and add the support for escaped special characters so it will be fully compatible with the glob syntax as used by the JDK.

[plecesne]

Now fixed in 0.12.0.

[netomi]

Thanks for fixing that and sorry that we did not move faster with our own implementation. Your own looks clean and nice though!

[abhishekgpta]

Hi,
@plecesne still facing this issue bundletool 0.13.4, Java 14

[plecesne]

@abhishekgpta Could you please give more details? Can you share the stacktrace?

[abhishekgpta]

@plecesne sure,
command::java -jar bundletool.jar install-apks --apks=my_app.apks

[BT:0.13.4] Error: Illegal char <"> at index 0: "C:\python
java.nio.file.InvalidPathException: Illegal char <"> at index 0: "C:\python
        at java.base/sun.nio.fs.WindowsPathParser.normalize(WindowsPathParser.java:182)
        at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:153)
        at java.base/sun.nio.fs.WindowsPathParser.parse(WindowsPathParser.java:77)
        at java.base/sun.nio.fs.WindowsPath.parse(WindowsPath.java:92)
        at java.base/sun.nio.fs.WindowsFileSystem.getPath(WindowsFileSystem.java:229)
        at com.android.tools.build.bundletool.model.utils.SdkToolsLocator.locateBinaryOnSystemPath(SdkToolsLocator.java:240)
        at com.android.tools.build.bundletool.model.utils.SdkToolsLocator.locateAdb(SdkToolsLocator.java:189)
        at com.android.tools.build.bundletool.commands.InstallApksCommand.lambda$fromFlags$1(InstallApksCommand.java:127)
        at java.base/java.util.Optional.orElseGet(Optional.java:362)
        at com.android.tools.build.bundletool.commands.InstallApksCommand.fromFlags(InstallApksCommand.java:124)
        at com.android.tools.build.bundletool.commands.InstallApksCommand.fromFlags(InstallApksCommand.java:115)
        at com.android.tools.build.bundletool.BundleToolMain.main(BundleToolMain.java:88)
        at com.android.tools.build.bundletool.BundleToolMain.main(BundleToolMain.java:46)

[plecesne]

This is a separate issue, it happens when trying to locate ADB.
It seems that there is a double quote character in your $PATH system variable.
Bundletool should be more lenient.
In the meantime, you can fix your $PATH if you want to be unblocked.

[abhishekgpta]

@plecesne thanks for the reply