:app:generateCrashlyticsSymbolFileRelease - Specified path for unstripped native libs is not a directory #1199

Kocjan · 2020-02-04T20:41:32Z

Describe your environment

    dependencies {
        classpath 'com.android.tools.build:gradle:3.5.3'
        classpath 'com.google.gms:google-services:4.3.3'
        classpath 'com.google.firebase:firebase-crashlytics-gradle:2.0.0-beta02'
        classpath 'com.google.firebase:firebase-appdistribution-gradle:1.3.1'
    }

Describe the problem

Steps to reproduce:

When I try to run:
./gradlew clean assembleRelease uploadCrashlyticsSymbolFileRelease

I get next error:

Execution failed for task ':app:generateCrashlyticsSymbolFileRelease'.
> java.io.IOException: Specified path for unstripped native libs is not a directory: /Users/martin/repos/example-app-android/app/obj

If I manually move all my NDK libs to ./app folder I get the same error with different path:

Execution failed for task ':app:generateCrashlyticsSymbolFileRelease'.
> java.io.IOException: Specified path for stripped native libs is not a directory: /Users/martin/repos/example-app-android/app/build/intermediates/transforms/stripDebugSymbol/release

In this second case the build command sometimes fails, sometimes not.

This issue started to appear after I moved from Fabric Crashlytics plugin to Firebase Crashlytics plugin.
In the Fabric case, I had the option to define: androidNdkOut and androidNdkLibsOut paths.
Is that missing in the new Firebase plugin?

Relevant Code:

Old code example:

    crashlytics {
        enableNdk true
        androidNdkOut "$buildDir/ndklibs/obj"
        androidNdkLibsOut "$buildDir/ndklibs/libs"
    }

New Code example:

            firebaseCrashlytics {
                nativeSymbolUploadEnabled true

            }

In the Firebase case, I didn't specify any paths.

To collect all ndk libs I use following code:

    configurations {
        ndkzip
    }

    task setupNdklibs(type: Sync) {
        dependsOn configurations.ndkzip
        from {
            configurations.ndkzip.collect { zipTree(it) }
        }
        into "$buildDir/ndklibs/"
    }
    build.finalizedBy setupNdklibs

and executing ./gradlew build

The text was updated successfully, but these errors were encountered:

google-oss-bot · 2020-02-04T20:41:33Z

I found a few problems with this issue:

I couldn't figure out how to label this issue, so I've labeled it for a human to triage. Hang tight.
This issue does not seem to follow the issue template. Make sure you provide all the required information.

mrichards · 2020-02-11T15:08:11Z

In the new Firebase Crashlytics plugin, the androidNdkOut and androidNdkLibsOut properties have been changed to strippedNativeLibsDir and unstrippedNativeLibsDir, and should be declared in firebaseCrashlytics within the variant block, where you declared nativeSymbolUploadEnabled true.

Those options aren't currently documented, though they will be shortly.

Kocjan · 2020-02-11T17:52:42Z

@mrichards thanks for the info, I will test it and let you know.

Kocjan · 2020-02-12T15:33:31Z

@mrichards I tested and I get the same issues, but now the problem is with the path:

> java.io.IOException: Specified path for unstripped native libs is not a directory: /Users/martin/repos/example-app-android/app/Users/martin/repos/example-app-android/app/build/ndklibs/libs

It looks like this task prepends <your-path-to-app>/app to strippedNativeLibsDir and unstrippedNativeLibsDir paths.
Code:

            firebaseCrashlytics {
                nativeSymbolUploadEnabled true
                strippedNativeLibsDir "$buildDir/ndklibs/obj"
                unstrippedNativeLibsDir "$buildDir/ndklibs/libs"
            }

I solved my problem using relative paths:

            firebaseCrashlytics {
                nativeSymbolUploadEnabled true
                // These paths are relative to the app/ folder
                strippedNativeLibsDir "build/ndklibs/obj"
                unstrippedNativeLibsDir "build/ndklibs/libs"
            }

But it looks like a issue with the app:generateCrashlyticsSymbolFileRelease task :)

mrichards · 2020-02-13T14:18:43Z

Glad you got it working! I'll take a look at the absolute path issue.

gordinmitya · 2020-02-22T15:47:59Z

Hello, thanks for your answer @mrichards
What should I do if I have multiple modules with native code in my project?
How do I specify paths?

nativeSymbolUploadEnabled true doesn't work

this is my output of find . -name "obj" in the root folder of project

./mace/build/intermediates/cmake/release/obj
./mace/build/intermediates/cmake/debug/obj
./mnn/build/intermediates/cmake/release/obj
./mnn/build/intermediates/cmake/debug/obj
./ncnn/build/intermediates/cmake/release/obj
./ncnn/build/intermediates/cmake/debug/obj

ihar-abramovich · 2020-02-28T16:48:36Z

Hello, thanks for your answer @mrichards
What should I do if I have a separate module with native code and include it in a project like aar?
Is it possible to work with new Crashlytics this way?

darrentaft · 2020-03-06T19:22:28Z

I'm trying to use this myself for the first time and seeing this same error. I don't do anything special with cmake, I don't override any default directories, and I didn't specify any androidNdkOut parameters with the Fabric version.
Having switched to Firebase Crashlytics, I can't get it to upload symbols due to error:

Execution failed for task ':app:generateCrashlyticsSymbolFileSportProdStoreRelease'.
> java.io.IOException: Specified path for stripped native libs is not a directory: /home/vsts/work/1/s/app/build/intermediates/stripped_native_libs/sportProdStoreRelease/out

Any clues on how I can debug this? Do I need to specify the xNativeLibsDir params? If so, with what values? FYI "sport" and "prod" are flavor dimensions, and "storeRelease" is the buildType.

Note: the app has a number of 3rd party libraries and a module that include includes libraries, but I don't have debug variants of them to specify unstripped libs.

synman · 2020-04-23T21:32:59Z

Thanks to mrichards on the new operatives. I had this issue today after doing some housekeeping (deleting old obj folders / etc) within my app module.

My app module does not have any (direct) native libraries within it -- I just have a couple jars I need packaged and keep them in app/libs.

firebaseCrashlytics {
      nativeSymbolUploadEnabled true
      strippedNativeLibsDir "libs"
       unstrippedNativeLibsDir "libs"
 }

marius-bardan · 2020-05-06T12:29:42Z

Since both properties are relative paths to 'app' dir, how should I reference other modules? For example, my native libs are in ':external' which sits on the same leve as ':app' dir.
setting something like the following doesn't work:
strippedNativeLibsDir "${rootProject.projectDir}/external/build/intermediates/stripped_native_libs/release/out/lib/"

4ntoine · 2020-05-08T06:14:04Z

Yup, i'm also interested. Let's say :app depends on another android library (aar) with shared libs. I believe during the build they are extracted and collected somewhere in build dir. However i did not find not stripped libs (that are coming from aar) after assembleRelease just to adjust the paths. Anyone?

marius-bardan · 2020-05-08T06:18:34Z

This is what I'm currently using. But cannot attest it's correct due to another bug (NPE thrown when trying to upload symbols).

firebaseCrashlytics {
    nativeSymbolUploadEnabled true
    unstrippedNativeLibsDir "build/intermediates/merged_native_libs/release/out/lib/"
    strippedNativeLibsDir "build/intermediates/stripped_native_libs/release/out/lib/"
}

4ntoine · 2020-05-08T06:20:47Z

@marius-bardan
It's interesting, i don't have the dirs that work for you. What's your versions (gradle and plugins)?

marius-bardan · 2020-05-08T06:22:42Z

com.android.tools.build:gradle:3.5.3
com.google.firebase:firebase-crashlytics-gradle:2.0.0

4ntoine · 2020-05-08T06:23:59Z

@marius-bardan

classpath 'com.android.tools.build:gradle:3.3.0'
classpath 'com.google.firebase:firebase-crashlytics-gradle:2.0.0-beta02'

will check yours

4ntoine · 2020-05-08T17:23:17Z

@marius-bardan
yup, with your versions the paths are correct. In my case the libs in ./app/build/intermediates/merged_native_libs/ were also stripped and it took some time to understand that it was "Release" build mode for 3rd-party lib (aar) and it contains already stripped libs. PS. I had to update Gradle version to 5.4.1 (minimum)

darrentaft · 2020-05-21T12:50:40Z

This issue is now intermittent for me. We use an Azure pipeline to build the app, so it's a fresh checkout and build every time on a clean environment with the same code. I just ran the pipeline 3 times in a row - first 2 failed with this error, 3rd time lucky.

kevinkokomani · 2020-05-28T22:15:02Z

@darrentaft To clarify, the issue you're referring to is the original "Specified path for unstripped native libs is not a directory" issue? If so, I'd be interested to know more about your 3 runs of the pipeline. Is there anything different you observed in the third run that made it work?

If you try to assemble and then upload symbols using manual Gradle tasks as a test, do you get the same error? What about if you make sure to manually clean between the ./gradlew assemble and ./gradlew uploadCrashlyticsSymbolFile? Maybe the Crashlytics plugin is having issues with custom build pipelines.

darrentaft · 2020-05-29T09:09:32Z

@kevinkokomani comparing the build runs, one thing I can see is that the build tasks don't appear to run in the same order every time. These are the tasks executed in the final steps before failure, just after it has finished building the native library. On the build that succeeded:

Task :app:compileTvSprintReleaseAmazonShaders
Task :app:generateTvSprintReleaseAmazonAssets
Task :app:mergeTvSprintReleaseAmazonAssets
Task :app:validateSigningTvSprintReleaseAmazon
Task :app:signingConfigWriterTvSprintReleaseAmazon
Task :app:mergeTvSprintReleaseAmazonJniLibFolders
Task :app:processTvSprintReleaseAmazonResources
Task :app:compileTvSprintReleaseAmazonKotlin
Task :app:mergeTvSprintReleaseAmazonNativeLibs
Task :app:stripTvSprintReleaseAmazonDebugSymbols
Task :app:processTvSprintReleaseAmazonJavaRes NO-SOURCE
Task :app:generateCrashlyticsSymbolFileTvSprintRelease
Task :app:uploadCrashlyticsSymbolFileTvSprintRelease
Task :app:generateCrashlyticsSymbolFileTvSprintReleaseAmazon
Task :app:uploadCrashlyticsSymbolFileTvSprintReleaseAmazon

Whereas on the build that failed:


> Task :app:compileTvSprintReleaseAmazonJavaWithJavac
Note: Some input files use or override a deprecated API.
Note: Recompile with -Xlint:deprecation for details.
Note: Some input files use unchecked or unsafe operations.
Note: Recompile with -Xlint:unchecked for details.

> Task :app:compileTvSprintReleaseAmazonSources
> Task :app:lintVitalTvSprintReleaseAmazon
> Task :app:mergeTvSprintReleaseAmazonShaders
> Task :app:compileTvSprintReleaseAmazonShaders
> Task :app:generateTvSprintReleaseAmazonAssets
> Task :app:mergeTvSprintReleaseAmazonAssets
> Task :app:validateSigningTvSprintReleaseAmazon
> Task :app:signingConfigWriterTvSprintReleaseAmazon
> Task :app:mergeTvSprintReleaseAmazonJniLibFolders
> Task :app:mergeTvSprintReleaseAmazonGeneratedProguardFiles
> Task :app:processTvSprintReleaseAmazonJavaRes NO-SOURCE
> Task :app:generateCrashlyticsSymbolFileTvSprintRelease
> Task :app:uploadCrashlyticsSymbolFileTvSprintRelease
> Task :app:generateCrashlyticsSymbolFileTvSprintReleaseAmazon FAILED
> Task :app:mergeTvSprintReleaseAmazonJavaResource
> Task :app:mergeTvSprintReleaseAmazonNativeLibs

FAILURE: Build failed with an exception.

See how the app:mergeTvSprintReleaseAmazonNativeLibs step is being executed AFTER app:generateCrashlyticsSymbolFileTvSprintReleaseAmazon for the failed build - is it maybe too late by then?

There are numerous points throughout the build where the execution order is different, so I don't know if any of them are relevant.

As for changing the pipeline - could the random order maybe be caused by me building 2 variants at the same time? This is the command it runs:

gradlew assembleTvSprintRelease assembleTvSprintReleaseAmazon uploadCrashlyticsSymbolFileTvSprintRelease uploadCrashlyticsSymbolFileTvSprintReleaseAmazon

kevinkokomani · 2020-05-29T16:37:32Z

Thanks for this info -- it might be worth a shot to run the assemble and the upload separately, at least as a test. We're aware of an issue that occurs where running the assemble and the uploadCrashlytics commands simultaneously can sometimes cause the upload to fail, or to upload the wrong files (the assemble doesn't finish in time for the upload, so the library's paths haven't been rebuilt yet). The non-deterministic nature of the issue you're describing makes it sound like the above could be affecting you.

Do you get similar behavior with the varied order of the build steps if you explicitly wait for gradlew assemble to finish before running gradlew uploadCrashlyticsSymbolFileTvSprintRelease?

darrentaft · 2020-06-10T15:20:52Z

Thanks @kevinkokomani ... I've been running with this for over a week now, and since moving the upload to a separate task, the issue hasn't reoccurred. The upload task alone takes around 8 seconds, so it's not really having any impact on our build process - I'm happy enough with that. Cheers.

mrichards · 2020-06-11T20:50:41Z

Crashlytics Gradle plugin v2.2.0 will fix both the task ordering issue and the absolute path issue. These two fixes together should make it easier to get symbols uploaded for 3rd party libraries using as described here.

We'll update this issue when the release goes live within the next couple of weeks.

mrichards · 2020-06-19T14:26:26Z

Crashlytics Gradle plugin v2.2.0 will fix both the task ordering issue and the absolute path issue. These two fixes together should make it easier to get symbols uploaded for 3rd party libraries using as described here.

Crashlytics Gradle plugin 2.2.0 is now live! Absolute paths should now work as expected.

If you've previously had trouble getting symbols uploaded for 3rd party native libs or non-standard NDK builds, please take a look at the doc linked above and give it another shot. We cleaned up the task configuration for generateCrashlyticsSymbolFile & uploadCrashlyticsSymbolFile, and added some improved error messaging. It should be easier to get it working for more complex builds now.

kenmorse · 2020-06-19T14:52:32Z

@mrichards — Still doesn't seem quite right: with the 2.2.0 plugin, now get "Crashlytics could not find NDK build tasks on which to depend. You many need to manually enforce task dependencies for generateCrashlyticsSymbolFileFlavorAmazonRelease" message.

rpattabi · 2020-06-21T11:45:59Z

@mrichards Even after updating the crashlytics plugin to 2.2.0, I get the same error. It still assumes the given path is relative path. If this was expected to work, how do you differentiate whether the given path is absolute or relative?

vfishv · 2020-06-22T14:35:48Z

😠 firebase-crashlytics-gradle:2.2.0 can NOT build but 2.1.1 works good

Crashlytics could not determine stripped/unstripped native library directories for project ':app', variant Release. These are required for generating symbol files when NDK build tasks cannot be automatically inferred. Please specify strippedNativeLibsDir and unstrippedNativeLibsDir in the firebaseCrashlytics extension.

google-oss-bot added the needs-triage label Feb 4, 2020

aguatno added api: crashlytics and removed needs-triage labels Feb 6, 2020

mrichards closed this as completed Jun 19, 2020

kenmorse mentioned this issue Jun 22, 2020

Message: "Crashlytics could not find NDK build tasks on which to depend." #1700

Closed

firebase locked and limited conversation to collaborators Jul 20, 2020

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

:app:generateCrashlyticsSymbolFileRelease - Specified path for unstripped native libs is not a directory #1199

:app:generateCrashlyticsSymbolFileRelease - Specified path for unstripped native libs is not a directory #1199

Kocjan commented Feb 4, 2020 •

edited

Loading

google-oss-bot commented Feb 4, 2020

mrichards commented Feb 11, 2020

Kocjan commented Feb 11, 2020

Kocjan commented Feb 12, 2020 •

edited

Loading

mrichards commented Feb 13, 2020

gordinmitya commented Feb 22, 2020 •

edited

Loading

ihar-abramovich commented Feb 28, 2020

darrentaft commented Mar 6, 2020

synman commented Apr 23, 2020

marius-bardan commented May 6, 2020

4ntoine commented May 8, 2020 •

edited

Loading

marius-bardan commented May 8, 2020

4ntoine commented May 8, 2020 •

edited

Loading

marius-bardan commented May 8, 2020

4ntoine commented May 8, 2020

4ntoine commented May 8, 2020 •

edited

Loading

darrentaft commented May 21, 2020

kevinkokomani commented May 28, 2020

darrentaft commented May 29, 2020

kevinkokomani commented May 29, 2020

darrentaft commented Jun 10, 2020

mrichards commented Jun 11, 2020

mrichards commented Jun 19, 2020

kenmorse commented Jun 19, 2020

rpattabi commented Jun 21, 2020

vfishv commented Jun 22, 2020 •

edited

Loading

:app:generateCrashlyticsSymbolFileRelease - Specified path for unstripped native libs is not a directory #1199

:app:generateCrashlyticsSymbolFileRelease - Specified path for unstripped native libs is not a directory #1199

Comments

Kocjan commented Feb 4, 2020 • edited Loading

Describe your environment

Describe the problem

Steps to reproduce:

Relevant Code:

google-oss-bot commented Feb 4, 2020

mrichards commented Feb 11, 2020

Kocjan commented Feb 11, 2020

Kocjan commented Feb 12, 2020 • edited Loading

mrichards commented Feb 13, 2020

gordinmitya commented Feb 22, 2020 • edited Loading

ihar-abramovich commented Feb 28, 2020

darrentaft commented Mar 6, 2020

synman commented Apr 23, 2020

marius-bardan commented May 6, 2020

4ntoine commented May 8, 2020 • edited Loading

marius-bardan commented May 8, 2020

4ntoine commented May 8, 2020 • edited Loading

marius-bardan commented May 8, 2020

4ntoine commented May 8, 2020

4ntoine commented May 8, 2020 • edited Loading

darrentaft commented May 21, 2020

kevinkokomani commented May 28, 2020

darrentaft commented May 29, 2020

kevinkokomani commented May 29, 2020

darrentaft commented Jun 10, 2020

mrichards commented Jun 11, 2020

mrichards commented Jun 19, 2020

kenmorse commented Jun 19, 2020

rpattabi commented Jun 21, 2020

vfishv commented Jun 22, 2020 • edited Loading

Kocjan commented Feb 4, 2020 •

edited

Loading

Kocjan commented Feb 12, 2020 •

edited

Loading

gordinmitya commented Feb 22, 2020 •

edited

Loading

4ntoine commented May 8, 2020 •

edited

Loading

4ntoine commented May 8, 2020 •

edited

Loading

4ntoine commented May 8, 2020 •

edited

Loading

vfishv commented Jun 22, 2020 •

edited

Loading