IssueTracker

this does what you want:

  adb shell ls '"hello world"'

why two sets of quotes? because there are two shells. your local one, and the remote one. if you want the remote shell to pass a single argument to ls, you need to pay the local shell a pair of quotes so that it passes a single argument to the remote shell, and then another pair of quotes to the remote shell.

if you find this confusing, just "adb shell" lets you talk directly to the remote shell.

Thank you for filing the report, and creating a sample project. What is the API of the device you are deploying the APK to?

Ok, I can confirm using "minifyEnabled false" has same behaviour, so it's not R8.
I use a x86_64 emulator with target Android 9.0.
Can you reproduce it with my repo ?

Does the APK contain the .so files if you build from the command line via `./gradlew assembleDebug`?

Also, can you try running Run->Debug from Android Studio after adding the following block to the defaultConfig block of your app's build.gradle (https://google.github.io/android-gradle-dsl/current/com.android.build.gradle.internal.dsl.NdkOptions.html):

ndk {
    abiFilters 'x86', 'armeabi-v7a'
}

Thank you to point me in the right direction !

A: `./gradlew assembleDebug` works properly
C: x86_64 emulator with target Android 9.0 does NOT work
D: x86 emulator with target Android 9.0 works !
E: x86_64 emulator  and "ndk.abiFilters 'x86', 'armeabi-v7a'" works !

It looks like,
with Android Studio 3.4.2 my x86 library works on x86_64 too. The code and building.
with Android Studio 3.5.1 it filters so library to target Emulator, except I apply ndk.abiFilters

Great, there is a work around, but it was very confusion and you were involved to point out, what's wrong here.
Maybe you introduce a warning/error during compile time ?
Anyway, I've to introduce a x86_64 so library as well

Glad that workaround works.

Thanks for all the additional info.

Yes, you're right that there's still an issue here. We should automatically package the x86 .so files if there are no x86_64 .so files available, as outlined here: http://issuetracker.google.com/133782953#comment25 (I've marked that bug as a duplicate of this one).

Looks like this was caused by ag/Ie0479eb156750daa78d4176a9a19cfc360fe94c3

To fix this, my plan is to still package just the .so files for one ABI from the list of target ABIs injected by AS, but add a  warning when we don't package the first target ABI in the list. To determine *which* ABI(s) are available to package, my plan is to look at the output of the MergeNativeLibsTask.

There will still be an issue if, for example, the app module has x86 and x86_64 .so files but the library module only has x86 .so files. In that case, even with the fix, we'd package only the x86_64 .so files, so the APK would be missing the .so files from the library. But in that case, it should be apparent that the library needs to add support for x86_64.

We've opted *not* to change the behavior here but instead to show a warning like this:
"There are no .so files available to package in the APK for x86_64."

Comment#5 suggests a temporary workaround for this, but the real fix is to ask the authors of the external libraries to add support for 64bit architectures (or upgrade to the latest version of the libraries if they've added support already). See https://developer.android.com/distribute/best-practices/develop/64-bit

I've opened Issue 143764512 for the use case of wanting to test 32bit native libraries on a physical device without having a 32bit device on hand.

It'll be hard to convince library authors to add support for x86_64 because such devices are basically nonexistent.
Unity for example never supported x86_64 and they are even removing x86 in the 2019.3 release https://blogs.unity3d.com/2019/03/05/android-support-update-64-bit-and-app-bundles-backported-to-2017-4-lts/

@comment#11 That's incorrect, x86_64 are plenty in Chromebooks, this is 64 bits. x86 is less popular but the most efficient option to run an emulator nowadays, so it'll not be that hard to convince library authors if you bring these right arguments to support both x86 architectures.