My first venture in Android programming is not terribly simple. I need to port some mathematical modelling libraries, compiled from C and C++ code, to Android. The code is thoroughly portable, and runs on many platforms already but I have no experience with Android. I'm also partially sighted, which makes it very difficult for me to use IDEs, so I'm planning to do everything from the Linux command line.
I am not going to be building an app for distribution. The product I work on is libraries, which are licensed to ISVs, who use them in applications programs. The libraries will run on-device, and have no web or cloud interfaces or APIs of any kind. Customers who want to run them in the cloud already do that, using the Linux or Windows builds. They're fairly heavyweight code, which needs a fair bit of memory and floating-point for serious work, so I'm hoping to only build for 64-bit Android, or if a 32-bit build is necessary, to confine it to AArch32. I will have to build an app to run tests, but this will be an Android wrapper round the existing test harness.
So I seem to need to build my libraries into .so shared libraries, which is familiar from Linux. But since I'm not building for one specific app, and the testing process for these libraries is lengthy, even though it is fully automated, I'd like to build to be compatible with a range of levels of Android.
My initial customer is using NDK 14b. I could use that, or I could use the latest NDK, 16b. If I compile C and C++ code with NDK 16b, the same compiler (Clang), a compatible instruction set and the same C++ run-time (libc++) and target API (21) version as my customer, will they be able to use my shared libraries in their NDK 14b app?
The other way around is also interesting: if I used NDK 14b, and another customer comes along who uses NDK 16b, will shared libraries I've built with 14b work in their 16b-built app? I'd be using Clang, targeting an equal or earlier API to them, and the same instruction set and C++ run-time.
Thanks in advance,
John
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/d93eae76-10b3-4cd4-947b-c13545f6ff0a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
> will shared libraries I've built with 14b work in their 16b-built app?The question is whether your libs expose only JNI (and communicate directly with Java), or a C API, or a C++ API.
If your customers have other own native libs, you must make sure that you use the same ABI: if they build for arm64, you should too; if they build for armeabi-v7a, you must provide your libs for that ABI even if the device is capable of running the 64-bit version: the Android app will only choose one ABI to be installed on the device.
C++ compatibility is not guaranteed between NDK versions (passing exceptions included); C API will work, but delicate things like tracing native crashes may be broken.
We do not pass C++ exceptions through APIs, although we use them within C++ code.However, applications that use our libraries sometimes throw C++ exceptions from functions of theirs that we have called, through out libraries, and catch them above us in the call stack. Obviously that has potential to go wrong if C++ is not guaranteed compatible: we plan to insist on libc++, and we will compile C with -fexceptions to let C++ exceptions propagate through C stack frames.
> I am afraid that you cannot compile C with -fexceptions. The rule of thumb is to use C++ compiler for all your sources.
Seriously? That's a very worrying prospect. The C is auto-generated from a higher level language, which has no facility to generate C++, and I don't know what adaptations would have to be made to the files to make them compile as C++ and still have the APIs come out right.Can anyone else confirm this, before I have to start a major project?John
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/edde8d1c-5da5-4f12-a038-ee55af801382%40googlegroups.com.
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAH1xqg%3DX%2BMVbanK7N4AirTPW2CXZypV4SV9r3u03axz%2BQAvRqw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAFVaGhvDxQR7yGzfaswJiKDd3MtM_mFn1Z8FZuzq9Ji%3DU2TnaQ%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CALgsJz%3D2hsUvj2GZAHbaXiPy_pnttun2X%2B_Xq8cVK5JKATqT%2Bw%40mail.gmail.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAH1xqgknVh0D2OMLFZN6Jdor%2BY%2B2TrEpZXmb3OERA4ooU96R4A%40mail.gmail.com.
The STL that you and your users use need to be the same. For modern NDKs this means both using libc++, and the same ABI version of libc++. We don't break the ABI often, but it's possible that we may in the future.
Your best bet is to always use the exact same NDK to build every binary in the app.
Your best bet is to always use the exact same NDK to build every binary in the app.Sadly, this is not something that I can plan on.
-fexceptions actually does have an effect on C code if you're using a GNU extension: __attribute__((cleanup)). It will allow cleanups to run if an exception unwinds through your C function.Keep in mind that it is *not* safe to propagate exceptions past JNI though. Exceptions need to be caught and handled before you transition back to Java.
On Feb 28, 2018 08:53, "John Dallman" <jgdats...@gmail.com> wrote:
Also, why can't you compile C with -fexceptions? Does the compiler refuse it, it not work, or something else? I'm quite happy to restrict the C++ compiler it would work with to Clang++ and libc++, if that helps.Thanks,John
On Wed, Feb 28, 2018 at 1:17 PM, John Dallman <jgdats...@gmail.com> wrote:
> I am afraid that you cannot compile C with -fexceptions. The rule of thumb is to use C++ compiler for all your sources.Seriously? That's a very worrying prospect. The C is auto-generated from a higher level language, which has no facility to generate C++, and I don't know what adaptations would have to be made to the files to make them compile as C++ and still have the APIs come out right.Can anyone else confirm this, before I have to start a major project?John
On Wed, Feb 28, 2018 at 11:16 AM, Alex Cohn <sasha...@gmail.com> wrote:
On Tuesday, February 27, 2018 at 5:17:23 PM UTC+2, John Dallman wrote:We do not pass C++ exceptions through APIs, although we use them within C++ code.However, applications that use our libraries sometimes throw C++ exceptions from functions of theirs that we have called, through out libraries, and catch them above us in the call stack. Obviously that has potential to go wrong if C++ is not guaranteed compatible: we plan to insist on libc++, and we will compile C with -fexceptions to let C++ exceptions propagate through C stack frames.I am afraid that you cannot compile C with -fexceptions. The rule of thumb is to use C++ compiler for all your sources.BR,Alex
--
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 post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/edde8d1c-5da5-4f12-a038-ee55af801382%40googlegroups.com.
--
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.
--
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 post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAH1xqgncXmy1gq-SbYR%2B8YeeVWWS-XH%2BNMHU17Cdp1HKofsnJA%40mail.gmail.com.
What is "it"?
On Mon, Mar 5, 2018, 09:21 John Dallman <jgdats...@gmail.com> wrote:
On Fri, Mar 2, 2018 at 8:05 PM, 'Dan Albert' via android-ndk <andro...@googlegroups.com> wrote:Your best bet is to always use the exact same NDK to build every binary in the app.Sadly, this is not something that I can plan on.Ack. Almost nobody does this. Keep to the other guidelines and incompatibility issues will be fairly unlikely (and are more likely to be build failures than run-time failures).Hum. It's something that appears to be designed into the NDK, especially since the NDK went down to one set of headers. It evidently isn't widely used; presumably it isn't heavily tested either?Thanks,John
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAH1xqgncXmy1gq-SbYR%2B8YeeVWWS-XH%2BNMHU17Cdp1HKofsnJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAFVaGhucavS8uYu%2ByfwWRpxxZs41dTYGm1U49UkZj7Q1oPnfGg%40mail.gmail.com.
On Mon, Mar 5, 2018 at 6:30 PM, 'Dan Albert' via android-ndk <andro...@googlegroups.com> wrote:What is "it"?The ability to compile for older API versions.
Thanks,John
On Mon, Mar 5, 2018, 09:21 John Dallman <jgdats...@gmail.com> wrote:
On Fri, Mar 2, 2018 at 8:05 PM, 'Dan Albert' via android-ndk <andro...@googlegroups.com> wrote:Your best bet is to always use the exact same NDK to build every binary in the app.Sadly, this is not something that I can plan on.Ack. Almost nobody does this. Keep to the other guidelines and incompatibility issues will be fairly unlikely (and are more likely to be build failures than run-time failures).Hum. It's something that appears to be designed into the NDK, especially since the NDK went down to one set of headers. It evidently isn't widely used; presumably it isn't heavily tested either?Thanks,John
--
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 post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAH1xqgncXmy1gq-SbYR%2B8YeeVWWS-XH%2BNMHU17Cdp1HKofsnJA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
--
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 post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
Quite contrary. Any version of NDK can build "for older API" and this is well supported. There are some limitations, e.g. NDK r16 dropped platforms 9, 12 and 13. Moreover, your code compiled for android-21 will happily run on android-26. Also, a shared library built for android-21 will coexist with other libs built for android-26. There may be some issues if you have a static library for 21, and want to link it into a shared library for 26, but unless the linker complains about missing references, you are safe.It is really preferable to have all code compiled with the same version of NDK, as Dan wrote before. Furthermore, use the same toolchain (note that since NDK 13, GCC is no longer supported and does not receive backports). Also, make sure that different STLs are not mixed. The guidelines that Dan mentioned emphasise that the public APIs should not expose C++ objects, to mitigate problems with STL incompatibilities.
Whereas, if I'm following you correctly, I can use the latest NDK to build a complete app for an old API standard of Android, and that works fine. But I'm not in the app business. I'm in the component business.
I'd prefer to distribute these libraries as .so files, but this does not mean that they're set up for calling from JNI.
I can recommend that they use a specific NDK, but I can't force them to do so.
Is it different levels of completeness of Bionic LibC? Different availability of graphics functions?
Variations in object file format?
--
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+unsubscribe@googlegroups.com.
To post to this group, send email to andro...@googlegroups.com.
Visit this group at https://groups.google.com/group/android-ndk.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAH1xqg%3D%3D5Ac0xvDVE2XVMP70ByDG6CBKbxPCAgJ3w5S4rhvm6Q%40mail.gmail.com.
With iOS, the most nearly similar platform I have worked with, compiling for the API standard of an older iOS gives you something that works with the build tools for the older iOS, with no qualifications.
To view this discussion on the web visit https://groups.google.com/d/msgid/android-ndk/CAFVaGhtXY3pd_cMeqAuDP9%2BKFYFD84Cg5LA_3tVdYy%2BTNfniiQ%40mail.gmail.com.