Gradle/AGP brings in inconsistent builds which prevents androidaudioplugin-manager.aar from MavenLocal about aap-core HOT 15 CLOSED

I have created a reverting branch that uses Gradle 7.6 and AGP 7.4.2, and the problem still persists. There are workaround builds that resolves aap-core and aap-lv2 modules from git submodules, and they successfully builds. But aap-lv2-mda on GitHub Actions (e.g. this), unlike local builds on Android Studio, resulted in missing lv2 assets(!). The build system still blocks...

from aap-core.

The same workaround is added in main branch in aap-lv2 and aap-lv2-mda i.e. their dependencies { ... } is full of implementation (project (...)) instead of module name artifacts. We will stick to that solution until we could get working builds...

We keep this issue open until then.

from aap-core.

The MavenLocal problem also seems to affect the new realtime preset setter implementation. It works well if androidaudioplugin-manager is resolved via project(...). Looks like it is caused by the same dependency resolution failure.

from aap-core.

When I tried to build the release version 0.2.8 (with aap-core 0.7.8, both without -pre), the revised version of aap-lv2 that resolves aap-core aars somehow broke aap-ayumi build because of missing libandroidaudioplugin-lv2.so(!)

Gradle and/or AGP with NDK support is such a wild field.

Fortunately, aap-lv2-mda effect plugins generate valid audio outputs from those MavenLocal .aars this time, I decided to go with MavenLocal for this release. The same issue would come back at any time so I leave this issue open.

from aap-core.

Actually the observation ^ was wrong, the audio resource resolution failure issue that occurs only with MavenLocal was never gone. We have to revert the change and find some viable solution (but how?? I have no idea at all).

from aap-core.

It also prevents aap-lv2 package releases because Maven publication task results in publishing androidaudioplugin.aar and androidaudioplugin-manager.aar to Nexus OSSRH (because they are dependencies). I have no idea how many more problems Gradle will bring in by trying hard to fix/support it so I leave it as is.

from aap-core.

Now the same problem occurs in aap-juce apps. Sigh.

from aap-core.

This also affects testImplementation. So if a project has testImplementation(libs.aap.testing) it will also cause the problem. I had been stuck at aap-ayumi for a while due to this issue.

from aap-core.

After facing the same issue at ktmidi, I figured that it's not going to work because we cannot "publish" the dependency modules. Either we need to figure out how to exclude them or we need to fix this issue.

from aap-core.

I have bumped Gradle to 8.5 and AGP to 8.2.2, and the problem still persists.

from aap-core.

Same for Gradle 8.6-rc1 and AGP 8.4.0-alpha07.

from aap-core.

Comparing androidaudioplugin-manager.aar from ~/.m2/repository/org/androidaudioplugin/androidaudioplugin-manager/0.8.0/, the native libraries are certainly different:

$  issue-174  ls -l working/lib/arm64-v8a
total 35600
-rw-r--r--  1 atsushi  staff    75584 Jan  1  1981 libaapbarebonepluginsample.so
-rw-r--r--  1 atsushi  staff  4381656 Jan  1  1981 libandroidaudioplugin-manager.so
-rw-r--r--  1 atsushi  staff  9321360 Jan  1  1981 libandroidaudioplugin.so
-rw-r--r--  1 atsushi  staff  1822720 Jan  1  1981 libc++_shared.so
-rw-r--r--  1 atsushi  staff  2620112 Jan  1  1981 liboboe.so
$  issue-174  ls -l problematic/lib/arm64-v8a 
total 16304
-rw-r--r--  1 atsushi  staff    75584 Jan  1  1981 libaapbarebonepluginsample.so
-rw-r--r--  1 atsushi  staff   442896 Jan  1  1981 libandroidaudioplugin-manager.so
-rw-r--r--  1 atsushi  staff  5716576 Jan  1  1981 libandroidaudioplugin.so
-rw-r--r--  1 atsushi  staff  1822720 Jan  1  1981 libc++_shared.so
-rw-r--r--  1 atsushi  staff   280128 Jan  1  1981 liboboe.so

Since they are already different at .aar level, dealing with native libs at app level would not make any difference. Yet, those options on androidaudioplugin-manager/build.gradle.kts did not matter:

• packaging.jniLibs.keepDebugSymbols.add("**/*.so")
• packaging.jniLibs.useLegacyPackaging = true

from aap-core.

Here are what I found so far:

• It is a matter of Release build. Debug build does not matter.
• It seems caused by something in libandroidaudioplugin-manager.so being stripped.
• It does not seem to be related to keepDebugSymbols in build.gradle.kts
  • the input library libandroidaudioplugin-manager.so is already stripped (explained later)
    • and it should not be a matter of "debug symbols"
  • AGP resolves those native libraries without stripping when we use implementation(project(...)). This smells like a bug, but does not matter this time
    • Release builds should respect our cxx compiler flags (explaned later), nonetheless.
  • It is not a Prefab issue, or any Gradle task around it (e.g. inflexible to be unable to add export_libraries options - it is true, but does not matter this time)
  • It is not an issue StripDebugSymbolsTask itself - the task seems working as expected in general
• It is rather one or more CMake issues.
  • The problem is that no matter what arguments we pass to cmake section in build.gradle.kts, they cannot beat the optimization flagsCMAKE_BUILD_TYPE.
  • Neither CMAKE_CXX_FLAGS nor CMAKE_CXX_FLAGS_RELEASE works.
  • arguments("-DCMAKE_BUILD_TYPE=Debug") on release configuration makes it work again, but that means we are left not optimized on release builds, so it's better to avoid it

from aap-core.

https://gitlab.kitware.com/cmake/cmake/-/issues/23378

from aap-core.

arguments("-DCMAKE_CXX_FLAGS_RELWITHDEBINFO=-O2 -g -DNDEBUG") is not working, and arguments("-DCMAKE_CXX_FLAGS_RELWITHDEBINFO=-O2 -g") is working, somehow.

We can go without -DNDEBUG.

from aap-core.