android 64 OpenSSL fails to Load

[Ian F 1]

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

 

 

[Remy Lebeau 1436]

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

[Ian F 1]

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

[Remy Lebeau 1436]

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.

[DelphiUdIT 187]

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

[Remy Lebeau 1436]

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?

 

[DelphiUdIT 187]

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

[at3s 4]

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.

[Remy Lebeau 1436]

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.

[Fr0sT.Brutal 900]

Doesn't Android have OpenSSL built-in?

[DelphiUdIT 187]

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

[Remy Lebeau 1436]

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

[Fr0sT.Brutal 900]

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?

[DelphiUdIT 187]

With this configuration (see libcrypto. so path for example ) you will load your OpenSSL libs.

 

[Remy Lebeau 1436]

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

[Fr0sT.Brutal 900]

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 ?

[Remy Lebeau 1436]

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.

[Fr0sT.Brutal 900]

@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