When working on a patch for Nextcloud’s Android app, my builds suddenly started failing after I had pulled the latest upstream changes.

When building, the task :app:dexBuilderGenericDebug , which is part of the standard build process, failed with dozens of “File name too long” errors like:

java.nio.file.FileSystemException: /home/myuser/devrepo/nextcloud-android/app/build/intermediates/global_synthetics_project/genericDebug/dexBuilderGenericDebug/out/com/owncloud/android/ui/adapter/ReceiveExternalFilesAdapter$ReceiveExternalViewHolder$$InternalSyntheticLambda$2$6636dd2b6ebd75843672790eb9fec557e7c7714a7c99b5385b15a5972ca7d9f8$0.globals: File name too long

Using git-bisect, I was able to quickly identify the problematic commit. As part of an upgrade to Gradle 9, the Android Gradle Plugin was also updated:

-androidPluginVersion = '8.13.2'
+androidPluginVersion = "9.0.0"

The problem seems to be that the Android Gradle Plugin generates synthetic lambda class names that can exceed Linux’s file name length limit. Typically, a file name can be 255 characters (and full path 4096), but this is different if you layer eCryptFS with filename encryption on top of these file systems (as installed in Ubuntu with an encrypted home directory).

Then, the max filename is only 143 characters (source), which many of the lambda class names exceed (the one from the example above is 156 characters long)

I did verify this, and the console command confirmed this:

$ getconf NAME_MAX /home/myuser/
143

This seems to be a bug in the 9.0.0 release, so until it is fixed, the options are:

1. Create an unencrypted partition and build your app from there
2. Downgrade the plugin to 8.13.2 again

I would also assume that minifying the code could also help – but that’s not an option for debug builds.