Republish native libs to the old location

273 views
Skip to first unread message

alexey sakovets

unread,
Dec 10, 2024, 8:11:12 AM12/10/24
to android-ndk

Hi everyone! 

I am working on a large C++ project and we are also building for Android. Recently our team decided to update AGP to the latest version (8.7.2). We also have a bunch of python scripts to process our native libraries after the build. These scripts expect to find the libraries in a predefined location which looks like build/intermediates/cmake/debug/...

This scheme worked fine with AGP 7.4, but it broke with the update. AGP no longer stores native build outputs in build/intermediates/cmake/debug/...

Looking for a solution I glanced over AGP source code and found some mysterious variable called NDK_SO_REPUBLISH_DIR:

https://android.googlesource.com/platform/tools/base/+/refs/heads/mirror-goog-studio-main/build-system/gradle-core/src/main/java/com/android/build/gradle/internal/cxx/settings/MacroDefinitions.kt#365

The comment following the variable says:

A folder with a predictable name where final build outputs (mainly .so) are hard linked or copied after the build completes. The purpose is so scripts and other external tools have a known path, with no embedded hashcode, to locate these files.

It seems like an internal thing, but if not it is still unclear how am I supposed to use it. I have also found a commit which introduced a republishing  behaviour :

https://android.googlesource.com/platform/tools/base/+/9e175de84fa6e0d706101e35632d0c031f1bc6c7

But it does not seem to work. Perhaps it should be explicitly configured. Or I misunderstand something. Anyway I was wondering if there is a way to republish native build artifacts to the old location.

Any help would be appreciated.

Jomo Fisher

unread,
Dec 11, 2024, 4:47:47 PM12/11/24
to Dan Albert, andro...@googlegroups.com, Emre Kultursay
Is it possible to just use the merge directory? for example,
./app/build/intermediates/merged_native_libs/debug/mergeDebugNativeLibs/out/lib/arm64-v8a/libmyapplication.so
./app/build/intermediates/merged_native_libs/debug/mergeDebugNativeLibs/out/lib/x86_64/libmyapplication.so
./app/build/intermediates/merged_native_libs/debug/mergeDebugNativeLibs/out/lib/x86/libmyapplication.so
./app/build/intermediates/merged_native_libs/debug/mergeDebugNativeLibs/out/lib/armeabi-v7a/libmyapplication.so


On Wed, Dec 11, 2024 at 12:34 PM Dan Albert <dana...@google.com> wrote:

--
You received this message because you are subscribed to the Google Groups "android-ndk" group.
To unsubscribe from this group and stop receiving emails from it, send an email to android-ndk...@googlegroups.com.
To view this discussion visit https://groups.google.com/d/msgid/android-ndk/de640cc2-9756-48b3-a215-47c9ff25ff00n%40googlegroups.com.

Jomo Fisher

unread,
Dec 12, 2024, 4:58:03 AM12/12/24
to Emre Kultursay, Dan Albert, android-ndk
It works but it's not on by default and it doesn't seem to be required here. I prefer not to recommend it if it's not needed because it's added maintenance for them and for us.

On Thu, Dec 12, 2024, 1:45 AM Emre Kultursay <emreku...@google.com> wrote:
+1 to Jomo's answer.

@Jomo Fisher Is the republish mechanism not working (or not working as intended)? Should we remove it?


Jomo Fisher

unread,
Dec 12, 2024, 5:29:02 AM12/12/24
to Emre Kultursay, Dan Albert, android-ndk
It is the same mechanism that could be used to republish compile_commands.json for consumption by downstream tooling, along with some other scenarios, and we have discussed it in public bugs. It doesn't have a bug tail so there isn't *that* much usage. But there are probably projects that would miss it.

On Thu, Dec 12, 2024, 2:02 AM Emre Kultursay <emreku...@google.com> wrote:
I agree. Can/Should we delete that republishing mechanism (assuming we didn't document it officially)?

Alexey Sakovets

unread,
Dec 13, 2024, 1:17:58 PM12/13/24
to android-ndk
Yeah, that's what I eventually did. I was hesitant to do so in the first place, because these locations are susceptible to change and I thought there might be a better solution. But I guess it's just a maintenance burden. Thanks.

четверг, 12 декабря 2024 г. в 00:47:47 UTC+3, Jomo Fisher:
Reply all
Reply to author
Forward
0 new messages