IssueTracker

Hi, was this a regression after you upgrade your NDK or upgrade your Android Studio?

Neither of them. There were no change to AS (4.1-RC1) nor NDK versions.

I just changed my old scripts in build.gradle to the android recommended method i.e.

externalNativeBuild { ndkBuild { path file('jni/Android.mk') } }

If I reverted the change to my old script, everything is working again. The old scripts uses

ndk.dir=/opt/android/android-sdk/ndk-bundle

as defined in local.properties file

The source.properties files indicate the version as:

Pkg.Desc = Android NDK Pkg.Revision = 21.3.6528147

Hi, the problem is that when Android Gradle Plugin executes ndk-build, it is missing the '-C' + projectDir + '/jni' part in your custom task. Therefore, the current working directory is the module root (parent of the jni directory). Hence the error.

The fix is to add the following to your build.gradle

android {
    ...
    defaultConfig {
        ...
        externalNativeBuild {
            ndkBuild {
                arguments "-Cjni"
            }
        }
    }
}

Please reopen the bug if you have further issues. Thanks!

Please provide the full syntax for the externalNativeBuild scripts. gradle sync throws the following error message when I added the recommended argument statement to the script (or change to arguments('-Cjni'))

A problem occurred evaluating project ':aTalk'.

No signature of method: build_6xrerbyg3j4aatiomvrbavr6i.android() is applicable for argument types: (build_6xrerbyg3j4aatiomvrbavr6i$_run_closure4) values: [build_6xrerbyg3j4aatiomvrbavr6i$_run_closure4@497bb461]

externalNativeBuild {
    ndkBuild {
        path file('jni/Android.mk')
        arguments "-Cjni"
    }
} 

There are actually two different types of exteranlNativeBuild blocks. The block in #4 needs to be put inside defaultConfig. So you would end up with something like

android {
    ...
    defaultConfig {
        ...
        externalNativeBuild {
            ndkBuild {
                arguments "-Cjni"
            }
        }
    }
    ...
    externalNativeBuild {
        ndkBuild {
            path file('jni/Android.mk')
        }
    }
}

Hi, you can filter ABIs with abiFilters.

Can you share the project with your changes on build.gradle?

It's a current limitation that native builds cannot be shared across different variants. We are aware of this and would like to improve the situation. For now you may be able to workaround the problem by moving the native code into a separate module with a single variant and make the main module depending on it.

Could you elaborate what you mean by "a. user now has to define what ABI to build for the adb debug; previously no such option and it is auto selected."? What was your workflow for debugging? After using externalNativeBuild, how exactly do you define the ABI to build?

Regarding app crash after deployment, do you have the same problem with the Android emulator?

This option is for the code editor (for example ABI-specific macro expansion). It won't affect deployment. When you deploy to a device, the right ABI would be built regardless of what you select in the "Build Variant" window. Is this not the behavior you have seen?

Without some background and familiarity with this project, it's difficult for me to understand why the app crashes. From logcat, it appears the assertion at line 74 in <project>\aTalk\jni\opensles\org_atalk_impl_neomedia_device_OpenSLESSystem.c failed (I appended && 1, && 2, && 3, etc to each assertion expression and found this out). I have never used OpenSLES. Maybe it's better to ask on stackoverflow.

Thanks! Problem #2 is a bug in AGP and we will fix it in future releases.

Here's the log of updated JacocoTaskDelegate (slightly redacted, quickly recorded right now, will provide diff later, forgot to record it)

> Task :app:jacocoJaguarDefaultMarketDebug
Task :app:jacocoJaguarDefaultMarketDebug in app Starting
Build cache key for task ':app:jacocoJaguarDefaultMarketDebug' is f56b624293460efdadba067dfe542182
Task ':app:jacocoJaguarDefaultMarketDebug' is not up-to-date because:
  Input property 'inputClasses' file /Users/fobo66/StudioProjects/JLRICRAndroid-Redev/app/build/intermediates/compile_and_runtime_not_namespaced_r_class_jar/jaguarDefaultMarketDebug/R.jar has changed.
  Input property 'inputClasses' file /Users/fobo66/StudioProjects/JLRICRAndroid-Redev/app/build/intermediates/javac/jaguarDefaultMarketDebug/classes/com/jlr/jaguar/analytics/Event$Action.class has changed.
  Input property 'inputClasses' file /Users/fobo66/StudioProjects/JLRICRAndroid-Redev/app/build/intermediates/javac/jaguarDefaultMarketDebug/classes/com/jlr/jaguar/analytics/Event$Category.class has changed.
1) Step 1 in [ms]: 5
2) Out of date done in [ms]: 12
3) Removed done in [ms]: 18

AAPT2 aapt2-4.0.1-6197926-osx Daemon #0: shutdown
AAPT2 aapt2-4.0.1-6197926-osx Daemon #1: shutdown
AAPT2 aapt2-4.0.1-6197926-osx Daemon #2: shutdown
AAPT2 aapt2-4.0.1-6197926-osx Daemon #3: shutdown

> Task :app:jacocoJaguarDefaultMarketDebug
Processing incrementally took [ms]: 228660
...
Stored cache entry for task ':app:jacocoJaguarDefaultMarketDebug' with cache key f56b624293460efdadba067dfe542182
Task :app:jacocoJaguarDefaultMarketDebug in app Finished
:app:jacocoJaguarDefaultMarketDebug (Thread[Execution worker for ':' Thread 11,5,main]) completed. Took 3 mins 53.87 secs.
:app:dexBuilderJaguarDefaultMarketDebug (Thread[Execution worker for ':' Thread 11,5,main]) started.

Here's the diff:

Common subdirectories: jaguarDefaultMarketDebug/META-INF and jaguarDefaultMarketDebug2/META-INF
Common subdirectories: jaguarDefaultMarketDebug/com and jaguarDefaultMarketDebug2/com

There are a lot of files inside, but it seems that they're identical

I've added extra logs and found out that this code appears to be the issue (JacocoTaskDelegate.java line 209):

// remove old output
        for (Path basePath : basePathToRemove.keys()) {
            for (Path toRemove : basePathToRemove.get(basePath)) {
                Action action = calculateAction(toRemove.toFile(), basePath.toFile());
                if (action == Action.IGNORE) {
                    continue;
                }

                Path outputPath =
                        getOutputPath(basePath, toRemove, output.get().getAsFile().toPath());
                PathUtils.deleteRecursivelyIfExists(outputPath);
            }
        }

        System.err.println("4) Removed old output done in [ms]: " + (System.currentTimeMillis() - start));

Here's the log:

...
4) Removed old output done in [ms]: 201628
Processing incrementally took [ms]: 201693
...

Only removed/modified paths should be removed, and I'd expect to have only a handful of those. Can you add some more logging in that loop e.g printing all basePath values in the outer loop and all toRemove in the inner loop?

Looks like it tries to remove anything inside app/build/tmp/kotlin-classes/jaguarDefaultMarketDebug. My Studio hanged when I've added extra logs, so I'll try to dig daemon logs if they are available, maybe there's more paths

Well, daemon logs stopped when still processing kotlin-classes because daemon was killed by me. Log file was 2.5 GB.

It seems that kotlin incremental compilation produces completely different outputs in the 1st and in the 2nd build, but then I find it strange that in comment #20 you found no difference between the two.

If all Kotlin sources are being re-processed, I think that might explain why it takes so long. For each modified path:

• AGP is using RegExp to figure out if it needs to copy/ignore/instrument that class file (should be cheap)
• AGP computes output location for that file (should be cheap)
• AGP deletes output location and all subdirectories (this can be costly)

And this difference seems to extend to Java classes as well. In the deamon log from #17, for the jacoco task that took 4 mins 13.872 secs, I can see:

• 1543 instrumented Java classes
• 2516 instrumented Kotlin classes

How many classes there are in total if you count all class files under app/build/tmp/kotlin-classes/jaguarDefaultMarketDebug/ and app/build/intermediates/javac/jaguarDefaultMarketDebug? It could be that the changed files actually inline R.jar constants that change between builds.

Also, can you test my hypothesis that output deletion takes a bunch of time by commenting it out? It may produce incorrect output, but it is useful as a way to test the hypothesis.

As far as I can see, not all Kotlin classes were using R.jar constants, but classpath for Kotlin compile task was changed, thus causing it to full rebuild:

Task ':app:compileJaguarDefaultMarketDebugKotlin' is not up-to-date because:
  Class path of task ':app:compileJaguarDefaultMarketDebugKotlin' has changed from 05dc8665ddde555057e95b579121aa9a to 15effd282854557decb2b289286f94b8.
The input changes require a full rebuild for incremental task ':app:compileJaguarDefaultMarketDebugKotlin'.

There were roughly 2,679 class files

Also, with removed output deletion it worked fine in 5 seconds, it wasn't stuck, and I will check coverage reports as soon as they complete

I've managed to reproduce the issue, and it turns out the root cause is the same as https://issuetracker.google.com/154069245. There AGP was invoking keys on multimap instead of keySet() method, causing each entry to be processed multiple times. We'd execute that loop N^2 times where N is the number of changed files.

This has been fixed already in AGP 4.2. I'll cherry-pick a fix to 4.1 branch.

This will be fixed in the Android Gradle plugin 4.1.2. Change I7ce00c5a63a737e7c59f27b5c962a6d2d30d2f41.