https://bugs.documentfoundation.org/show_bug.cgi?id=174043
Bashar Al Halabi <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |NOTABUG Status|NEEDINFO |RESOLVED --- Comment #2 from Bashar Al Halabi <[email protected]> --- Thanks for the question, and you are right: this does not affect any app that LibreOffice builds. I combined two setups that LibreOffice does not combine itself, and the report should have said so. Our use case: a third-party Android app (not the Viewer) that embeds LibreOfficeKit through its C API (libreofficekit_hook_2, documentLoad, saveAs) for offline DOC/DOCX to PDF conversion, Writer only, built from the unmodified 26.8.1.1 tag. I used --enable-android-lok because configure describes it as the "non-modified LOK" mode for an app other than the one in android/. For the rc files I then followed android/source/build.gradle.kts, which is the Viewer's recipe. The Viewer is built without --enable-android-lok, so it never reaches the SynchronizeExtensionRepositories() call in lo_initialize (desktop/source/lib/init.cxx, #if HAVE_FEATURE_ANDROID_LOK). And an in-tree --enable-android-lok build still links liblo-native-code.so with -g core -g writer -g calc -g draw -g edit (android/source/Makefile), so the deployment constructors are present there. The first problem comes from my Writer-only component selection, the second from using the Viewer's rc files for an android-lok build. My sentence that the Viewer "may hit only the second problem" was wrong: it hits neither. Closing as NOTABUG. One question, since you know the Android side: for an app that embeds LibreOfficeKit through the C API on Android outside the Viewer, would you recommend --enable-android-lok, or building the way the Viewer does? Knowing which configuration is expected to keep working would help us stay on a supported path. -- You are receiving this mail because: You are the assignee for the bug.
