IssueTracker

Fixed in CL 9735373

Should be available in 4.0 canary 5+

Can you look in the app's build > intermediates > merged_native_libs > debug > out directory and tell me which of the .so files are there?

After making some other changes the .so file is being packaged again. Not sure what caused the error in the first place.

Ok. Thanks. Closing this bug for now, but please reopen if it happens again.

It started happening again but now none of the .so files are included. To answer your previous question the content of the APK matches what's in build > intermediates > merged_native_libs > debug > out (i.e. they are both empty).

Anything else I can try?

How are you building your project? From the IDE? From the command line with ./gradlew assembleDebug?

Where exactly in your project are the original source files for these native librariest?

Can you upload a simple project with similar structure even if it doesn't reproduce the issue?

Can you try with 3.6.0-alpha02 instead of 3.5.0-beta03?

So I managed to fix it seemingly by clearing the build cache. But I also cleaned and restarted my computer. The issue happened both from AS and the command line which makes me think it is a cache issue. I don't know how the cache works but if it caches which native libraries is in a library that might explain it.

Now I'm using beta03 without issues.

I want to investigate this a bit more on my side. Can you tell me where the .so files are coming from exactly? Are they in the libraries' src/jniLibs folders?

They are all coming from libraries that are published using maven as an AAR

External libraries? If so, can you say which one(s)?

Only one of them is public; Crashlytics NDK (https://firebase.google.com/docs/crashlytics/ndk-reports)

Thanks.

I'm not able to reproduce on my end, so I'm closing for now.

Please re-open if you hit the issue again or can supply any more info.

I also experienced this when updating from gradle plugin 3.4.1 to 3.5.0-rc01. I noticed that the libs were only missing for debug build types when deploying to a 64 but device.  When the problem occurred, I had this in my build.gradle:

buildTypes {
        debug {
            packagingOptions {
                // note: this is only relevant to debug builds because in release we build separate APKs per abi
                // we don't have any 64bit libs for gpen, and since we cannot mix 32bit and 64bit whe must
                // exclude other 64bit libs
                exclude 'lib/armeabi/libsqlcipher.so'
                exclude 'lib/arm64-v8a/libsqlcipher.so'
                exclude 'lib/x86_64/libsqlcipher.so'
            }
        }
    }

However, removing this section solved the problem.

Note: when building release APKs, the libs are (regardless of presence of packagingOptions section) included as expected (this make sense because the packagingOptions section is only for debug buildType).
Note2: when rolling back to gradle plugin 3.4.1, everything works fine.

Which .so files are being excluded?

Can you upload a toy project which reproduces the issue?

Thanks for the toy project, but I'm not able to reproduce the issue.

Here's what I'm doing to try to reproduce. Let me know if there's something different I need to do.

AndroidStudio version: 3.5-rc1
Android Gradle Plugin version: 3.5-rc1
Emulator device: Nexus 5X API 28 x86
OS: Linux

I open the project and hit the green arrow to "Run 'app'". I then examine the APK in app/build/outputs/apk/debug/app-debug.apk. The apk contains the lib/x86/libsqlcipher.so entry.

I think you need to use a 64 bit emulator image

Ah, okay, but the packagingOptions are explicitly excluding the 64 bit native libs, right? Wouldn't you expect them to be missing from the APK?

I would expect the same behavior as with plugin 3.4.2 - the 64 bit libs are omitted, but the 32 bit libs are included.

I'll have to confirm, but I suspect excluding the 32 bit libs is the intended behavior... it's faster to build and deploy without the 32 bit native libs.

What's the use-case for needing the 32 bit native libs when deploying to a 64 bit device?

When a 64 bit lib is not included in the project. Also it's good to be able to test a 32 bit build on real device without having to have a 32 bit device.

Reassigning to chying@ since the device abi info is coming from Studio. chying@, is there a way to configure studio to include 32-bit .so files even if the device is 64-bit?

@15: you say "Note: when building release APKs, the libs are (regardless of presence of packagingOptions section) included as expected (this make sense because the packagingOptions section is only for debug buildType)."

This is actually incorrect. packageOptions is a global option. this is not an option that is specific to build type, so it applies to ALL variants. (the fact that you can put it inside buildType is a "feature" of Gradle).

I think the issue here is that Studio injects the ABI for gradle to build only the ABI that matches the device, and this collides with custom packaging filtering. In order to properly fix this we would need to have a more focused DSL that we can understand and make sure that the values set in the DSL do not collide with the ABI injected by Studio. Thankfully we do have such a DSL!

you should be able to do:

buildTypes {
        debug {
            ndkOptions {
              abiFilter 'x86', 'armeabi'
            }
        }
    }

This should contain the list that you want to package, not the list to exclude.

Scott, we should make sure our handling of injected ABI make sure that it's actually packaged. If not we should find a compatible ABI that is.

This probably means that we want to inject not one ABI but a list of ABIs (devices publish a list of ABI in priority order).

Thanks, yes, I just tried it, and adding the abiFIlters to the toy project causes the 32-bit .so files to be packaged, as desired.

Quick correction to the syntax though:

buildTypes {
        debug {
            ndk {
              abiFilters 'x86', 'armeabi'
            }
        }
    }

Thanks Xavier and Scott. Yes, this ndk {} approach works in my project too.

I'm still a bit confused about the packagingOptions. Okay, so it's in the wrong place, but it still has an impact. I guess you're saying it would have the same impact if it was in the correct place and that the packaging issue is a result of AndroidStudio's deployment packaging, not the variant being built?

It's just that because ndk.abiFilters is specific to ABI filtering, we have logic to use that information and the injected ABIs (from Studio) to make it work together.

We don't try to make sense of packagingOptions for 2 reasons:
- it's the not expected way one should remove an ABI so we just didn't think about it.
- Even if we wanted to, it's much harder to look at the list of exclude and *understand* that you were trying to remove the 64 bit ABI. We'd have to actually build all the ABIs and then compare the list of generated so files with what you are trying to exclude to see that you are indeed excluding *all* the so and so therefore, maybe, you meant to remove the full ABI. It's just too complicated for our logic to use this signal when handling the injected ABI.

This bug thread actually includes 2 separate bugs.

The first one, discussed until Comment #14, appears to be a duplicate of Issue 141536986 (based on Comment #11), which has a workaround and a pending fix.

The second one, discussed from Comment #15 onward, is a duplicate of Issue 142342272, and still needs to be addressed according to Xav's Comment #25. I'm marking this bug a duplicate of that issue and will track work there.

After updating from gradle 6.2.2 to 6.5, I noticed that the code in #26 no longer works (at least in Gradle DSL). The abiFilters line gives this:

.../build.gradle.kts:91:17: Unresolved reference. None of the following candidates is applicable because of receiver type mismatch:
public inline operator fun <T : Any, C : NamedDomainObjectContainer<TypeVariable(T)>> TypeVariable(C).invoke(configuration: NamedDomainObjectContainerScope<TypeVariable(T)>.() -> Unit): TypeVariable(C) defined in org.gradle.kotlin.dsl
public operator fun <T> Closure<TypeVariable(T)>.invoke(): TypeVariable(T) defined in org.gradle.kotlin.dsl
public operator fun <T> Closure<TypeVariable(T)>.invoke(x: Any?): TypeVariable(T) defined in org.gradle.kotlin.dsl
public operator fun <T> Closure<TypeVariable(T)>.invoke(vararg xs: Any?): TypeVariable(T) defined in org.gradle.kotlin.dsl
public operator fun <V> Callable<TypeVariable(V)>.invoke(): TypeVariable(V) defined in org.gradle.kotlin.dsl
public operator fun <T> Action<in TypeVariable(T)>.invoke(target: TypeVariable(T)): Unit defined in org.gradle.kotlin.dsl
public operator fun <T> NamedDomainObjectProvider<TypeVariable(T)>.invoke(action: TypeVariable(T).() -> Unit): Unit defined in org.gradle.kotlin.dsl
public operator fun ArtifactHandler.invoke(configuration: ArtifactHandlerScope.() -> Unit): Unit defined in org.gradle.kotlin.dsl
public operator fun DependencyConstraintHandler.invoke(configuration: DependencyConstraintHandlerScope.() -> Unit): Unit defined in org.gradle.kotlin.dsl
public inline operator fun <T> ExtraPropertiesExtension.invoke(initialValueProvider: () -> TypeVariable(T)): InitialValueExtraPropertyDelegateProvider<TypeVariable(T)> defined in org.gradle.kotlin.dsl
public operator fun <T> ExtraPropertiesExtension.invoke(initialValue: TypeVariable(T)): InitialValueExtraPropertyDelegateProvider<TypeVariable(T)> defined in org.gradle.kotlin.dsl
public operator fun <T> Spec<TypeVariable(T)>.invoke(arg: TypeVariable(T)): Boolean defined in org.gradle.kotlin.dsl
public inline operator fun TaskContainer.invoke(configuration: TaskContainerScope.() -> Unit): TaskContainer defined in org.gradle.kotlin.dsl

Actually, this is not because of updating gradle, but rather after updating android build tools from 4.0.1 to 4.1.0.

Thanks!  4.1.0-rc01

I confirm the first one DOES NOT work and the second one DOES work (so I'll use that).

By the way, I use getByName("debug") instead of debug {} which doesn't compile.

you can visit here https://castleapk.net/