IssueTracker

EDIT: Hold on, I think my test is invalid. I'll reply with another comment with attached logs if I can repro it. I'm testing it again. Apologies for the confusion.

ORIGINAL COMMENT:
Hmm I'm not able to reproduce this anymore. I'm not sure what changed. Maybe the old build cache caused some issues. But after doing a clean & build, I am not seeing this.

Feel free to close this issue, if it happens again I'll let you know.

Yep, I'm still able to reproduce the issue. Sorry for the confusion. Attached are my build logs (with `--info` and `--debug` enabled in compiler options). I also attached the idea logs directory.

These steps don't reproduce the issue for me:
(1) Create new C++ project
(2) Paste snippet from comment #1 into app\build.gradle
(3) Select fullDebug variant and x86 ABI
(3) Delete app\build and app\.cxx folders (to be sure there's no leftovers)
(4) Using x86 emulator...
(5) Run -> Run 'app'
(6) From shell:
macbookpro:MyApplication112 jomof$ find . -name *.o
./app/.cxx/cmake/fullDebug/x86/CMakeFiles/native-lib.dir/native-lib.cpp.o
macbookpro:MyApplication112 jomof$ find . -name *.so
./app/build/intermediates/cmake/fullDebug/obj/x86/libnative-lib.so
./app/build/intermediates/merged_native_libs/fullDebug/out/lib/x86/libnative-lib.so
./app/build/intermediates/stripped_native_libs/fullDebug/out/lib/x86/libnative-lib.so

I do see a couple spurious warnings at step (6) :
  Cannot build selected target ABI: x86, no suitable splits configured: armeabi-v7a;
  ABIs [x86] set by 'android.injected.build.abi' gradle flag contained 'X86' not targeted by this project.
But I think these are ignorable for this purpose.

I will work on reproducing again tomorrow

I am still seeing this but oddly on only one of my projects:

```
> Task :ZPayService:externalNativeBuildFullDebug
Build ZPayService_x86
ninja: Entering directory `E:\code\zps\source\ZPayService\.cxx\cmake\fullDebug\x86'
[1/45] Copying third party binaries
[2/45] Linking CXX static library output\lib\libZPayUtilities.a
[3/45] Linking CXX static library output\lib\libWallet.a
[4/45] Building CXX object ZPayService/Interface/CMakeFiles/ZPayServiceInterface.dir/Source/ZPay/Packets/StartTransaction/StartTransactionCommand.cpp.o
...
[33/45] Building CXX object ZPayService/Interface/CMakeFiles/ZPayServiceInterface.dir/Source/ZPay/Protocol/Kizi.cpp.o

> Task :ZPayService:externalNativeBuildFullDebug
[34/45] Building CXX object ZPayService/Interface/CMakeFiles/ZPayServiceInterface.dir/Source/ZPay/Vas/Google/GoogleVasApplication.cpp.o
...
[43/45] Building CXX object ZPayService/Interface/CMakeFiles/ZPayServiceInterface.dir/Source/ZPay/ZPayServer.cpp.o
[44/45] Linking CXX static library output\lib\libZPayServiceInterface.a
[45/45] Linking CXX shared library ..\..\..\..\build\intermediates\cmake\fullDebug\obj\x86\libZPayService.so
Build ZPayService_armeabi-v7a
ninja: Entering directory `E:\code\zps\source\ZPayService\.cxx\cmake\fullDebug\armeabi-v7a'
[0/1] Re-running CMake...
```

Notice how it says `Build ZPayService_x86` then `Build ZPayService_armeabi-v7a`? I have an x86 device selected in the drop down at the top right next to the run configuration selection. I enabled `--info --debug` in compiler options and rebuilt from scratch. Please see attached logs.

I'm attaching an MCVE. This is a stripped down version of the project in question. I'm able to reproduce the issue when I build:

```
> Task :ZPayService:externalNativeBuildFullDebug
Build ZPayService_x86
ninja: Entering directory `E:\code\mcve_building_all_variants3\ZPayService\.cxx\cmake\fullDebug\x86'
[1/6] Building CXX object ZPayService/ZPayUtilities/CMakeFiles/ZPayUtilities.dir/Source/ZPay/BerTlv.cpp.o
[2/6] Building CXX object ZPayService/Interface/CMakeFiles/ZPayServiceInterface.dir/Source/ZPay/ZPayServer.cpp.o
[3/6] Linking CXX static library ZPayService\ZPayUtilities\libZPayUtilities.a
[4/6] Linking CXX static library ZPayService\Interface\libZPayServiceInterface.a
[5/6] Building CXX object ZPayService/CMakeFiles/ZPayService.dir/Source/JniZPayServiceMain.cpp.o
[6/6] Linking CXX shared library ..\..\..\..\build\intermediates\cmake\fullDebug\obj\x86\libZPayService.so
Build ZPayService_armeabi-v7a
ninja: Entering directory `E:\code\mcve_building_all_variants3\ZPayService\.cxx\cmake\fullDebug\armeabi-v7a'
[1/6] Building CXX object ZPayService/ZPayUtilities/CMakeFiles/ZPayUtilities.dir/Source/ZPay/BerTlv.cpp.o
[2/6] Building CXX object ZPayService/Interface/CMakeFiles/ZPayServiceInterface.dir/Source/ZPay/ZPayServer.cpp.o
[3/6] Linking CXX static library ZPayService\ZPayUtilities\libZPayUtilities.a
[4/6] Linking CXX static library ZPayService\Interface\libZPayServiceInterface.a
[5/6] Building CXX object ZPayService/CMakeFiles/ZPayService.dir/Source/JniZPayServiceMain.cpp.o
[6/6] Linking CXX shared library ..\..\..\..\build\intermediates\cmake\fullDebug\obj\armeabi-v7a\libZPayService.so
```

Note that sometimes I also see that `c++_shared.so` is not packaged with the APK. See attached screenshot.

Comparatively, if I run this gradle build I get the correct file structure:

    .\gradlew.bat :PaymentService:installx86debug

The files I see:

lib/x86/libc++_shared.so
lib/x86/libZPayService.so

Even if I pick "x86Debug" in the Build Variants panel of Android Studio, I do not see these libs included in the APK. It's only the command line build that inserts them in the APK.

Hey Robert,
For #11, how did you kick off the build? Doesn't the "Full" in :ZPayService:externalNativeBuildFullDebug indicate to build both ABIs in your mcve?
When I set the active build variant to x86Debug and build I get what look like the right .so files:
./ZPayService/build/intermediates/merged_native_libs/x86Debug/out/lib/x86/libc++_shared.so
./ZPayService/build/intermediates/merged_native_libs/x86Debug/out/lib/x86/libZPayService.so
./ZPayService/build/intermediates/stripped_native_libs/x86Debug/out/lib/x86/libc++_shared.so
./ZPayService/build/intermediates/stripped_native_libs/x86Debug/out/lib/x86/libZPayService.so
./ZPayService/build/intermediates/cmake/x86Debug/obj/x86/libc++_shared.so
./ZPayService/build/intermediates/cmake/x86Debug/obj/x86/libZPayService.so
./ZPayService/build/intermediates/intermediate-jars/x86/debug/jni/x86/libc++_shared.so
./ZPayService/build/intermediates/intermediate-jars/x86/debug/jni/x86/libZPayService.so
./PaymentService/build/intermediates/merged_native_libs/x86Debug/out/lib/x86/libc++_shared.so
./PaymentService/build/intermediates/merged_native_libs/x86Debug/out/lib/x86/libZPayService.so
./PaymentService/build/intermediates/stripped_native_libs/x86Debug/out/lib/x86/libc++_shared.so
./PaymentService/build/intermediates/stripped_native_libs/x86Debug/out/lib/x86/libZPayService.so

What is #11? I kicked off the build by doing CTRL+F5 to "Run on device", which is supposed to only build the relevant architectures for the target device, IIRC. At least, that's the behavior I've observed the past few years until now. Yes, my "full" flavor includes x86 and armeabi-v7a architectures. But that's only if I "assembleRelease" on Gradle command line, or run "Make Project" in Android Studio. If I CTRL+F5 to run on device or ALT+F5 to debug on device, it used to only build ARM if I had an ARM device, or x86 if I targeted an x86 device. But it never did both.

Sorry for the shorthand, I was referring to comment #11 in this bug dated September 17.
Is it possible you've mapped CTRL+F5 to something? As far as I can tell that's not a standard keystroke for Android Studio. Neither my Windows, Mac, or Linux machines has that keystroke bound to anything in Android Studio. And I don't see it referenced in https://developer.android.com/studio/intro/keyboard-shortcuts (but that list could easily be missing stuff)

If I go by menu I use Run->Run 'PaymentService' (SHIFT+F10) has then I only see x86 built:
jomof@jomof:~/projects/mcve$ find . -name *.so
./ZPayService/build/intermediates/merged_native_libs/fullDebug/out/lib/x86/libc++_shared.so
./ZPayService/build/intermediates/merged_native_libs/fullDebug/out/lib/x86/libZPayService.so
./ZPayService/build/intermediates/stripped_native_libs/fullDebug/out/lib/x86/libc++_shared.so
./ZPayService/build/intermediates/stripped_native_libs/fullDebug/out/lib/x86/libZPayService.so
./ZPayService/build/intermediates/cmake/fullDebug/obj/x86/libc++_shared.so
./ZPayService/build/intermediates/cmake/fullDebug/obj/x86/libZPayService.so
./ZPayService/build/intermediates/intermediate-jars/full/debug/jni/x86/libc++_shared.so
./ZPayService/build/intermediates/intermediate-jars/full/debug/jni/x86/libZPayService.so
./PaymentService/build/intermediates/merged_native_libs/fullDebug/out/lib/x86/libc++_shared.so
./PaymentService/build/intermediates/merged_native_libs/fullDebug/out/lib/x86/libZPayService.so
./PaymentService/build/intermediates/stripped_native_libs/fullDebug/out/lib/x86/libc++_shared.so
./PaymentService/build/intermediates/stripped_native_libs/fullDebug/out/lib/x86/libZPayService.so

That's why I was confused, I do not see a comment #11 (well, I didn't until your comment just now). See attached screenshot.

Also there's another screenshot showing my keymap. Sorry for the confusion, I did customize my mapping using the VisualStudio template (as a base) that Android Studio provides.

Also can you please test on Windows? That's the platform I'm running all these tests on. Not sure why platform would matter, but for completeness if you try it we can at least rule it out.

Oh, I assumed you saw the same comments as me. Good to have learned that.
Yeah, I'll check on Windows too

I can repro on Windows with AS 3.5. Now trying 3.6 to determine whether its a Windows-only issue or if it was fixed after 3.5 somehow.

Sorry, I was wrong. I still don't repro even on 3.5 with Windows. I had pressed CTRL+F9 (Make Project) instead of SHIFT+F10 (Run 'Payment Service')
Steps I used:
1) Download and unzip mcve from comment #7
2) Install CMake 3.15 and put it on the path
3) Put ninja.exe on the path
4) Open mcve in Android Studio (I tried 3.5 and 3.6)
5) Change Android Studio's current build variant to 'fullDebug'
6) Set the current emulator to 'Pixel 2 API 29 x86'
7) Press SHIFT+F10  (Run 'Payment Service')
App builds only x86 and runs successfully:
c:\Users\jomof\Downloads\mcve>dir *.so /s/b
c:\Users\jomof\Downloads\mcve\PaymentService\build\intermediates\merged_native_libs\fullDebug\out\lib\x86\libc++_shared.so
c:\Users\jomof\Downloads\mcve\PaymentService\build\intermediates\merged_native_libs\fullDebug\out\lib\x86\libZPayService.so
c:\Users\jomof\Downloads\mcve\PaymentService\build\intermediates\stripped_native_libs\fullDebug\out\lib\x86\libc++_shared.so
c:\Users\jomof\Downloads\mcve\PaymentService\build\intermediates\stripped_native_libs\fullDebug\out\lib\x86\libZPayService.so
c:\Users\jomof\Downloads\mcve\ZPayService\build\intermediates\cmake\fullDebug\obj\x86\libc++_shared.so
c:\Users\jomof\Downloads\mcve\ZPayService\build\intermediates\cmake\fullDebug\obj\x86\libZPayService.so
c:\Users\jomof\Downloads\mcve\ZPayService\build\intermediates\intermediate-jars\full\debug\jni\x86\libc++_shared.so
c:\Users\jomof\Downloads\mcve\ZPayService\build\intermediates\intermediate-jars\full\debug\jni\x86\libZPayService.so
c:\Users\jomof\Downloads\mcve\ZPayService\build\intermediates\merged_native_libs\fullDebug\out\lib\x86\libc++_shared.so
c:\Users\jomof\Downloads\mcve\ZPayService\build\intermediates\merged_native_libs\fullDebug\out\lib\x86\libZPayService.so
c:\Users\jomof\Downloads\mcve\ZPayService\build\intermediates\stripped_native_libs\fullDebug\out\lib\x86\libc++_shared.so
c:\Users\jomof\Downloads\mcve\ZPayService\build\intermediates\stripped_native_libs\fullDebug\out\lib\x86\libZPayService.so

Just to make sure, I see you are looking at output files, that's not what I was looking at. I was watching the build logs and noticed that both armeabi-v7a and x86 showed up and translation units were being compiled twice. Did you keep an eye on that as well?

Let me check that

Looking at the log, I only see x86 compilation:
> Task :ZPayService:externalNativeBuildFullDebug
Build ZPayService_x86
ninja: Entering directory `C:\src\mcve\mcve\ZPayService\.cxx\cmake\fullDebug\x86'
[1/6] Building CXX object ZPayService/ZPayUtilities/CMakeFiles/ZPayUtilities.dir/Source/ZPay/BerTlv.cpp.o
[2/6] Building CXX object ZPayService/Interface/CMakeFiles/ZPayServiceInterface.dir/Source/ZPay/ZPayServer.cpp.o
[3/6] Linking CXX static library ZPayService\ZPayUtilities\libZPayUtilities.a
[4/6] Building CXX object ZPayService/CMakeFiles/ZPayService.dir/Source/JniZPayServiceMain.cpp.o
[5/6] Linking CXX static library ZPayService\Interface\libZPayServiceInterface.a
[6/6] Linking CXX shared library ..\..\..\..\build\intermediates\cmake\fullDebug\obj\x86\libZPayService.so

> Task :ZPayService:mergeFullDebugJniLibFolders

Looking at result .o:
c:\src\mcve>dir *.o /s/b
c:\src\mcve\mcve\ZPayService\.cxx\cmake\fullDebug\x86\ZPayService\CMakeFiles\ZPayService.dir\Source\JniZPayServiceMain.cpp.o
c:\src\mcve\mcve\ZPayService\.cxx\cmake\fullDebug\x86\ZPayService\Interface\CMakeFiles\ZPayServiceInterface.dir\Source\ZPay\ZPayServer.cpp.o
c:\src\mcve\mcve\ZPayService\.cxx\cmake\fullDebug\x86\ZPayService\ZPayUtilities\CMakeFiles\ZPayUtilities.dir\Source\ZPay\BerTlv.cpp.o

Looking at an earlier log file you sent I noticed:
12:31:16.859 [WARN] [com.android.build.gradle.internal.cxx.logging.ErrorsAreFatalThreadLoggingEnvironment] ABIs [x86_64,x86,armeabi-v7a,armeabi,arm64-v8a] set by 'android.injected.build.abi' gradle flag contained 'ARMEABI, ARM64_V8A, X86_64' not targeted by this project.

That's five ABIs that gradle has been instructed to build (by Android Studio) but we only support four ABIs in any case. I think ARMEABI is the extra one.
So I need to see if I can track down what can cause Android Studio to do that. Looking around in your project, do you see 'armeabi' anywhere (excluding armeabi-v7a cases)

I did a global search for the regex:

armeabi(?!-v7a)

I got no hits. So this is something coming from Android Studio and/or the NDK perhaps?

That's good information. It's surely a bug though I'm not sure it's the direct cause of your problem.
By the way, any chance you have multiple devices attached (or device + emulator)? It should be fine, I'm just trying to eliminate variables

At the time I tested, which was a while back, I don't remember unfortunately. Sometimes I do have multiple devices connected, and in those cases the architectures will be different (x86 and armeabi-v7a). However I never use emulators, since our software depends on specific hardware components.

Sorry I know that's not very helpful. Hopefully you can track down the bug. Thanks for your time and responsiveness!

Notes for myself:
The only way that I can see that the particular set of ABIs (x86_64,x86,armeabi-v7a,armeabi,arm64-v8a) could be produced is if there are multiple devices received by MakeBeforeRunTaskProvider.java (cs/android/tools/adt/idea/android/src/com/android/tools/idea/gradle/run/MakeBeforeRunTaskProvider.java?l=424) and one is x86_64 and another is arm64-v8a. In that case, the lookup table LaunchableAndroidDevice.ABI_MAPPINGS would expand the ABI list to the five ABIs I mentioned earlier.
I'm not sure if there's a way to get multiple devices in this list without explicitly doing "Run on multiple devices".

Also, I found comments (cs/android/tools/adt/idea/android/src/com/android/tools/idea/gradle/run/AndroidDeviceSpec.kt?l=76) that suggest that Android Studio considers the list of android.injected.build.abi to be a list of order preference rather than a complete list of what should be built. If C++ just built the first available ABI in the list (x86) then this bug would be resolved. However, I don't know how "Run on multiple devices" could work if we always build just one ABI so I think that's not the answer.

At this point, the question I need to answer is how are there multiple devices when the repro steps only indicate one device selected.

@Robert, does this issue still repro in your production environment?

@Robert, a second followup question. Would the actual physical devices be 64-bit?

(cc'ing dunno, as he may have an idea of what is going on, as this may be related to changes made for "Apply Changes").

Wrt to AndroidDeviceSpec comment, this class is only used when using the "APK from app bundle"  option in the run configuration.

Sorry for the delay. Yes, the physical devices are 64-bit, however we only build 32-bit versions of our applications because they are not coded properly for 64-bit environments.

I'm going to run this test again for you and let you know if it still happens. If there is any information I can give you about this device to help you out, please let me know.

Sorry I was mistaken a bit. We have 2 models of ARM devices, and 1 model of x86. The 2 arm devices are 32 bit. Specifically the one I likely tested with is `armv71`. The x86 device is 64-bit.

So I ran this test again on 3.6 Beta 4 and I'm not able to repro. Something got fixed at some point.

The only left over issue is why you are seeing armeabi in the list, I'm not sure if that's an issue. At the very least, getting an understanding of why it is present and documenting that here may help everyone in the future. If you have time for it.

Thanks Jomo.

It's correct that we view the ABI list as a precedence list rather than a complete list of what to build. So I've made that change (build # 9735373). I believe it will fix https://issuetracker.google.com/140124424 as well.

The one thing that still bothers me is that in the log files attached to this bug that ABI list contains both arm and x86 family ABIs. From looking at the code, I can't explain a way for that to happen. Maybe that code path has changed since the version that produced the log, but that's probably being too optimistic.

I did verify that run on multiple devices still works and that's the only thing I can see that even has a chance of causing the mixed ABI list.

Because of my uncertainty I don't want to ask to put this in 3.6 beta. That puts the arrival of this fix in 4.0.

Robert, if you do look at 4.0 (> canary 4) at some point and find that this bug still reproduces please reactivate this bug.