Ian F 1 Posted February 28, 2023 Moving My application to D 11.2 Android 13 and android 64 bit on a Pixel 4 XL. get a message that openSSL fails to load Have put libcrypto.so and libssl.so for OpenSSL 1.0.2g Android\Android\armeabi-v7a in deployment to .\assets\internal\ ( this worked on the Android32 bit app D 10.4) these were downloaded from the indy sockets/ Openssl binarys using IdSSLOpenSSLHeaders.WhichFailedToLoad() I get the result "Failed to load /data/user/0/com.embarcadero.<MyApp>/files/libcrypto.so." Tried dropping them in the above directory but ended with the same result not clear if I have the wrong versions of the *.so files ( I think the pixel processor is armabi-V8) or whether I am placing the files in the wrong folder at Deployment have found some notes in my search's that perhaps I Should " statically build OpenSSL directly into your app binary" if this is necessary can anyone point me to some notes on how to achive this thanks in advance Ian Share this post Link to post
Remy Lebeau 1413 Posted February 28, 2023 (edited) 13 hours ago, Ian F said: using IdSSLOpenSSLHeaders.WhichFailedToLoad() I get the result "Failed to load /data/user/0/com.embarcadero.<MyApp>/files/libcrypto.so." Unfortunately, when Indy fails to load an OpenSSL library into memory on a non-Windows platform, it does not report WHY the library failed to load. Quote not clear if I have the wrong versions of the *.so files ( I think the pixel processor is armabi-V8) Sounds plausible, given that ARMv7 is 32bit whereas ARMv8 is 64bit. However, ARMv8 can run ARMv7 code, but only when running in ARMv7 mode. You will likely have to search around for (or compile yourself) OpenSSL 1.0.2 binaries for ARMv8. I don't have such binaries available (or else they would have already been checked in to Indy's GitHub repo) Quote have found some notes in my search's that perhaps I Should " statically build OpenSSL directly into your app binary" if this is necessary can anyone point me to some notes on how to achive this Indy isn't coded to support using OpenSSL statically except on iOS. You could try modifying the IdCompilerDefines.inc and IdSSLOpenSSLHeaders_static.pas files to support static OpenSSL on Android. But even then, you would still need suitable binaries for each CPU architecture that your app is targeting. Edited February 28, 2023 by Remy Lebeau Share this post Link to post
Ian F 1 Posted February 28, 2023 Thanks for your informative reply Have found some binaries at dfeprado / prebuilt-openssl-1.0.2f that might work Looking at some notes of yours on Stack overflow about Static Load It Currently Targets .a files if does this need to change to .so files for android and where about do the .a or .so files need to reside so the compiler finds them Regards Ian Share this post Link to post
Remy Lebeau 1413 Posted March 1, 2023 18 hours ago, Ian F said: Looking at some notes of yours on Stack overflow about Static Load It Currently Targets .a files if does this need to change to .so files for android No, because .so files are not static-link files. Per the documentation, the Android compiler uses .a files for static linking, same as the iOS compiler. 18 hours ago, Ian F said: and where about do the .a or .so files need to reside so the compiler finds them Anywhere you want, as long as it is on the compiler's search path. Share this post Link to post
DelphiUdIT 178 Posted March 1, 2023 (edited) I have the *.so OpenSSL 1.02 library for all Android SO (x86, x86_64, V7a, V8a) ... they are all date 14/06/2022 and may be the version is 1.02s I really don't know where i found them, and since I also use Indy SSL I researched all libraries for all supported systems. Like i told, I don't know who "create" the library but I used them and no problems were found. Bye openssl-1.02_Android.zip Edited March 1, 2023 by DelphiUdIT 1 Share this post Link to post
Remy Lebeau 1413 Posted March 2, 2023 22 hours ago, DelphiUdIT said: I have the *.so OpenSSL 1.02 library for all Android SO (x86, x86_64, V7a, V8a) ... they are all date 14/06/2022 and may be the version is 1.02s Thanks. I would like to check in this .zip file to Indy's GitHub repo, but first can you please verify that version number? 1.0.2u was released on Dec 20 2019. What does Indy's OpenSSLVersion() function (in the IdSSLOpenSSL unit) actually return when using these .so files? Share this post Link to post
DelphiUdIT 178 Posted March 2, 2023 (edited) This is the version of the arm 64 (arm64-V8a). The others should be the same. Fips means that are compiling with some cryptography function ? I thought fips modules could only be compiled with OPENSSL 3. Edited March 2, 2023 by DelphiUdIT Share this post Link to post
at3s 4 Posted March 2, 2023 I'm using libssl.so v 1.0.2r in my project and there was not a problem with the Android migration from Delphi 10.4 to 11.2. Sure, there are files for Android32 and Android64. Share this post Link to post
Remy Lebeau 1413 Posted March 3, 2023 4 hours ago, DelphiUdIT said: This is the version of the arm 64 (arm64-V8a). The others should be the same. Thanks. I have now added the .zip to Indy's repo. Share this post Link to post
Fr0sT.Brutal 900 Posted March 16, 2023 Doesn't Android have OpenSSL built-in? Share this post Link to post
DelphiUdIT 178 Posted March 16, 2023 5 hours ago, Fr0sT.Brutal said: Doesn't Android have OpenSSL built-in? In the past surely not. I always used "mine" libraries. Of course there are issues with versions (1.0.x, 1.1.x, 3.0.x), so it's best to distribute your own anyway. Bye Share this post Link to post
Remy Lebeau 1413 Posted March 16, 2023 (edited) 6 hours ago, Fr0sT.Brutal said: Doesn't Android have OpenSSL built-in? It used to, but Google dropped support for OpenSSL in favor of BoringSSL (their own customized fork of OpenSSL) in Android 6. See this answer on StackOverflow, which I posted about this issue at the time. Edited March 16, 2023 by Remy Lebeau 1 Share this post Link to post
Fr0sT.Brutal 900 Posted March 16, 2023 14 minutes ago, Remy Lebeau said: See this answer on StackOverflow, which I posted about this issue at the time. Could you please clarify? Quote But to make matters worse, BoringSSL uses the same library filenames as OpenSSL, and is pre-loaded at device startup, so it is not possible to deploy custom-built OpenSSL library binaries with your Android app. Android will simply use the pre-loaded BoringSSL binaries when the app tries to load the OpenSSL library filenames at runtime (regardless of whether you call Indy's IdOpenSSLSetLibPath() function). Is it all about lib filenames? Won't renaming OpenSSL lib files to, say, libeay_internal.so with appropriate change in units help? Share this post Link to post
DelphiUdIT 178 Posted March 16, 2023 With this configuration (see libcrypto. so path for example ) you will load your OpenSSL libs. Share this post Link to post
Remy Lebeau 1413 Posted March 16, 2023 (edited) 3 hours ago, Fr0sT.Brutal said: Is it all about lib filenames? Won't renaming OpenSSL lib files to, say, libeay_internal.so with appropriate change in units help? That would require recompiling the OpenSSL libs so could can still find each other using the new filenames. 2 hours ago, DelphiUdIT said: With this configuration (see libcrypto. so path for example ) you will load your OpenSSL libs. I think this may be device-specific. I've had some reports that OpenSSL libs couldn't be loaded if they were using the same filenames as the BoringSSL libs, and at the time (I don't know if this is still true) BoringSSL did use the original OpenSSL filenames. And I've had some reports of users successfully loading OpenSSL libs even on BoringSSL systems. The OpenSSL filenames are hard-coded in Indy. I would have to add a new API to the IdSSLOpenSSLHeaders unit to allow loading of user-defined filenames. Edited March 16, 2023 by Remy Lebeau Share this post Link to post
Fr0sT.Brutal 900 Posted March 17, 2023 11 hours ago, Remy Lebeau said: That would require recompiling the OpenSSL libs so could can still find each other using the new filenames. Ahh, the main issue is that OpenSSL's lib1 uses lib2 via hardcoded name not the Delphi unit ? Share this post Link to post
Remy Lebeau 1413 Posted March 17, 2023 12 hours ago, Fr0sT.Brutal said: Ahh, the main issue is that OpenSSL's lib1 uses lib2 via hardcoded name not the Delphi unit ? OpenSSL is an external 3rd party library written in C, so of course it can't use a Delphi unit. Also, OpenSSL uses 2 lib binaries that are LINKED together when they are compiled, the filenames are not hard-coded in code, they are established during the compile/link stages (ie, 1 lib statically imports functions from the other lib), hence why you would have to recompile OpenSSL in order to change its lib filenames. Share this post Link to post
Fr0sT.Brutal 900 Posted March 20, 2023 (edited) @Remy Lebeau yes, that's exactly what I thought. Probably didn't express that clear enough. On 3/17/2023 at 10:38 PM, Remy Lebeau said: why you would have to recompile OpenSSL in order to change its lib filenames BTW, harsh patching of lib names inside binaries also seems to work. I changed libeay|ssleay32 to libeay|ssleay99 and test app powered by QT connected successfully Edited March 20, 2023 by Fr0sT.Brutal Share this post Link to post