Could not load SSL library on the 64 bit Release version from Play Store

[Alex40 5]

Hello, I am having a weird issue which I don't know how to handle and your help would be appreciated ! I use Rad Studio 10.4.1, SSL libraries version: OpenSSL 1.0.2q  20 Nov 2018 ( I am not sure if there is a newer version, which is compatible) 

 

After a long time of searching the correct libcrypso.so and libssl.so files for the Android 64 build, I've finally managed to make my app working in Debug/Release - Development configuration and Release - Application Store.

Unfortunately, after we published the Release in the Play Store and downloaded the app, all users with 64 bit smartpfones are facing the problem - Could not load SSL library, same version in Debug/Release, installed from the Rad Studio works fine.

To be sure I am doing it right from my side I extracted an 64 bit .apk file from the .aab package to be sure I am installing the same build as in the Play Store and the app loaded the SSL libraries without any issues, it fails only when downloaded from the Store.

 

Smartphone brands tested with 64 bit Android, which failed: Samsung, Huawei, Xiaomi with Android versions from 9 to 11.

 

Smartphone brands tested with 32 bit Android, which succeeded: Lenovo.

 

Has anybody faced the same problem and if yes, how did he solve it? Do I need new version of SSL libraries and if yes, where can I download them from ? 

 

Thank you in advance for your help !

Edited January 25, 2021 by Alex40

[TurboMagic 92]

Have you made sure these files are in release config of 64 bit platform in deployment manager as well?

[Alex40 5]

Yes, of course. As I said. I've even exctracted the .aab file, which contains all together the 32 and 64 bit apks, and my 64 bit apk runs fine. I also test on Release, Development configuration, it's working. It's an issue with the Play Store hanging my libraries, but I am not sure what exactly it is.

2 hours ago, TurboMagic said:

Have you made sure these files are in release config of 64 bit platform in deployment manager as well?

[Keesver 23]

I can remember that Remy Lebeau posted some messages on this.  Searching for "openssl android remy" will bring you to StackOverflow.

[Alex40 5]

If you are talking about the post "Loading OpenSSL dynamic libraries arm & x86 (FMX, C++)", it is not related with my case at all. I am aware how to deploy the SSL and all other type of librarties. The problem occurs when the app is published to the Play Store. In all other cases my app runs as it should be, except when downloaded from the Play Store.

2 hours ago, Keesver said:

I can remember that Remy Lebeau posted some messages on this.  Searching for "openssl android remy" will bring you to StackOverflow.

[Remy Lebeau 1393]

Modern Android versions simply don't support OpenSSL anymore.  They use BoringSSL instead, which Indy does not support.  And on some (not all) Android devices, BoringSSL gets used even if the app tries to use OpenSSL dynamically.  So, unless you statically build OpenSSL directly into your app binary, using OpenSSL on Android is a hit-or-miss endeavour.

9 hours ago, Alex40 said:

Unfortunately, after we published the Release in the Play Store and downloaded the app, all users with 64 bit smartpfones are facing the problem - Could not load SSL library, same version in Debug/Release, installed from the Rad Studio works fine.

What does Indy's WhichFailedToLoad() function report when the error occurs?  Also, does Indy's OpenSSLVersion() function report anything?

[Alex40 5]

Then why the only moment ssl libraries are not loaded, is when the app is installed from the Play Store?! In all other cases it works?! I've tested on many phones, including mine, which now throws the same error, when I install the app from the Play Store. And I've also found on StackOverflow a similar issue as mine, which was solved by deploying "newer version of openssl libraries":
https://stackoverflow.com/questions/59602114/android-fmx-indy-ssl-works-on-debugging-but-not-from-playstore-download

37 minutes ago, Remy Lebeau said:

Modern Android versions simply don't support OpenSSL anymore.  They use BoringSSL instead, which Indy does not support.  And on some (not all) Android devices, BoringSSL gets used even if the app tries to use OpenSSL dynamically.  So, unless you statically build OpenSSL directly into your app binary, using OpenSSL on Android is a hit-or-miss endeavour.

 

1) OpenSSLVersion() does not report anything (returns empty result)

2) WhichFailedToload() returns: Failed to load /data/app/com.myapp.app/lib/arm64/libcrypto.so.

37 minutes ago, Remy Lebeau said:

 

What does Indy's WhichFailedToLoad() function report when the error occurs?  Also, does Indy's OpenSSLVersion() function report anything?

Edited January 25, 2021 by Alex40

[Remy Lebeau 1393]

2 hours ago, Alex40 said:

Then why the only moment ssl libraries are not loaded, is when the app is installed from the Play Store?! In all other cases it works?!

I can't answer that.

2 hours ago, Alex40 said:

And I've also found on StackOverflow a similar issue as mine, which was solved by deploying "newer version of openssl libraries"

And?  Did you try using a newer version of OpenSSL?  1.0.2q is not the latest (I'm guessing you are using the libraries from Indy's GitHub repo?).  The last version in the 1.0.2 series was 1.0.2u.  I don't have Android binaries for that version, but I'm sure you can find them if you search around.  For supporting the OpenSSL 1.1.x series, there is this SSLIOHandler instead, but I don't know if it works on Android or not.

2 hours ago, Alex40 said:

1) OpenSSLVersion() does not report anything (returns empty result)

2) WhichFailedToload() returns: Failed to load /data/app/com.myapp.app/lib/arm64/libcrypto.so.

Do you have libssl.so in the same folder?  Are they from the same OpenSSL version?  Are you calling Indy's IdOpenSSLSetLibPath() function at program startup?

[Alex40 5]

 

Quote

And?  Did you try using a newer version of OpenSSL?  1.0.2q is not the latest (I'm guessing you are using the libraries from Indy's GitHub repo?).  The last version in the 1.0.2 series was 1.0.2u.  I don't have Android binaries for that version, but I'm sure you can find them if you search around.  For supporting the OpenSSL 1.1.x series, there is this SSLIOHandler instead, but I don't know if it works on Android or not.

I got my ssl libraries from a member of the forum and I didn't know about the Indy's Github repo with 1.0.2u for latest version. I will try to find the Android binaries for 1.0.2u and let you know if there is any difference ! I hope this fixes my problem.
Meanwhile if you manage to find them, please send me a download link.

Quote

Do you have libssl.so in the same folder?  Are they from the same OpenSSL version?  Are you calling Indy's IdOpenSSLSetLibPath() function at program startup?

1) Yes, I do have libssl in the same folder.

2) Yes, they are from the same OpenSSL version. 

3) Yes, I am calling Indy's IdOpenSSLSetLibPath() function at program startup

If some of these 3 points are not set, I would not be able to run my app with Indys at all.

As I said at the beginning - I have no issues with Debug / Release - Development configuration, as well as Release - Application Store configuration, where .aab file is generated. The issue comes only when I download the app from the Play Store.

 

Thank you for your time, Remy!

Edited January 26, 2021 by Alex40

[Alex40 5]

The problem is not with the SSL libraries actually (this is what I've thought from the first place). It's with the delpoyment of all the .so files with remote path library\lib\arm64-v8a.

 

I managed to run the ssl libraries when setting the remote path to .\assets\internal\ and calling in my code the DocumentPath instead of the LibPath, but this is not a fix for me. I have several more libraries, which are set to be deployed in library\lib\arm64-v8a and now they are not found (for example for the location service - libProxyAndroidService.so).

 

Thanks to bundletool I can install (simulate) app same as downloaded from Play Store and the result was the same before setting the ssl libraries remote path to .\assets\internal\

 

When I open the App Bundle package, I can find all the .so files, which I've set to be deployed, but they are in external base\lib direcrtoty and I think because of that they now are not found inside of the .apk. 

 

 

Do you have any suggestions how this could be handled? Is it a setting or something?

 

Does anybody managed to load .so files throudh App Bundle with 64 bit Android?

 

Edited: I found a similiar issue with another .so library, a fix is provided for the Android Studio, but not for Delphi:
https://stackoverflow.com/questions/63931010/delphi-10-3-android-remote-service-crash-when-binding

Edited January 26, 2021 by Alex40

[Remy Lebeau 1393]

2 hours ago, Alex40 said:

The problem is not with the SSL libraries actually (this is what I've thought from the first place). It's with the delpoyment of all the .so files with remote path library\lib\arm64-v8a.

Sounds like an issue that needs to be reported to Embarcadero.

 

[Alex40 5]

22 hours ago, Remy Lebeau said:

Sounds like an issue that needs to be reported to Embarcadero.

 

I decided to check with FileExists if the .so files are located in the lib path after installation:

 

1) When built with Development configuration(no matter Debug or Release) and installed directly with APK from Delphi, the .so files exist and there are no issues;

2) When built with Aplication Store configuration and installed with apk from the AppBundle file using bundletool, the .so files do not exist.

 

This is tested on Samsung, Xiaomi, Huawei with Android 9 to 11.

 

Very interesting is that on Lenovo with Android 7 (arm64) the files exist in all the cases and there are no issues. I guess all phones with Android version > 7 face the above problem.

 

I am surprised that still nobody has faced this issue for so long time, at least I couldn't find any information about it.

Edited January 27, 2021 by Alex40

[Rollo62 536]

Do you have a simple test app, to be able to verify that it doesn't deploy ?

Did you add the deployment manually in the deploymment manager (I remember there is also an automatic addition somewhere for default libraries, but SSL shouldn't be in there) ?

[Fr0sT.Brutal 900]

Probably Google decided that apps must use system libs instead of their own

[Alex40 5]

14 hours ago, Rollo62 said:

Do you have a simple test app, to be able to verify that it doesn't deploy ?

Did you add the deployment manually in the deploymment manager (I remember there is also an automatic addition somewhere for default libraries, but SSL shouldn't be in there) ?

It does deploy the files, but in deployment we set remote path: library\lib\arm64-v8a, but in the generated .aab file the path with the libraries is not library\lib\arm64-v8a. It changes to lib\arm64-v8a and I think this could cause the issue. All other paths are following the same order, except the library path.

 

I added the deployment manually. I moved the ssl libraries to assets\internal and I load them with Tpath.GetDocumentsPath , so I don't have an issue with them anymore.

 

But there are still two more libraries that I need for my service I use:

1) libMyService.so 

2) libProxyAndroidService.so

 

They strongly want to be in library\lib\arm64-v8a and changing their remote path is causing build errors or crashes when I try to start my service.

Successfully found and loaded the libraries on:

 

1) Lenovo with Android v.7 and arm64 (64 bit version)
2) Alcatel with Android v.8 and arm (32 bit version)

 

Failed to find the libraries:

 

1) Samsung Galaxy Note 9 with Android v.9 and arm64 (64 bit version);

2) Xiaomi Pocophone with Android v.10 and arm64 (64 bit version);

3) Refering to the support feedback from the users - most of the phones from this rank do not find the libraries in the lib folder

I get confused why some phones found the libraries, but most don't.

Edited January 28, 2021 by Alex40

[Rollo62 536]

Quote

is not library\lib\arm64-v8a. It changes to lib\arm64-v8a a

library\lib\arm64-v8a
lib\arm64-v8a a

 

So what you think the issue is, the missing library,  or the added .a ?

I think the library\lib should be right to be pointing to lib only, or do you expect the folder library ?

The added .a should be not OK, maybe there is just a "\" or "/" missing or too many in the options setting,

be aware that also the options settings exist for ALL, DEBUG, RELEASE, x32/x64, which could differ.

I've added a kind of debug mode in my apps, where I can list and check all the available the local filles and folders,

maybe that helps to get clear when comparing where are the differences after installation on the different phones.

 

Does the libraries have same name for x32 and x64 ?

Maybe that causes the bundle or the OS to ignore it ?

But it should work with same name under different folder, I would assume too.

 

[Alex40 5]

4 hours ago, Rollo62 said:

library\lib\arm64-v8a
lib\arm64-v8a a

 

So what you think the issue is, the missing library,  or the added .a ?

 

I have no idea where are you seeing this 'added .a'. I wrote:

"It changes to lib\arm64-v8a and I think this could cause the issue", please read carefully !

And I said that all other paths are generated the same way - assets, res and the rest, except the library\lib - it is only lib. I am just guessing.

 

I have no clue what is going on and why nobody has faced similar problem until now.

Edited January 28, 2021 by Alex40

[Rollo62 536]

2 hours ago, Alex40 said:

I have no idea where are you seeing this 'added .a'.

Ok, my fault, maybe a copy-paste-error here in DP:

I had clearly seen the .a ending when I answered (thats why I copy-and-blue-red it, to make it more visible).
So I thought this was maybe wrongly interpreted as fibrary file.
I still think "lib\.... " should be the right place.

 

[Alex40 5]

15 hours ago, Rollo62 said:

I still think "lib\.... " should be the right place.

I totally agree, for sure there is something wrong with the Embarcadero itself. I am not saying it's 100% a bug, it could be a setting, but no luck so far.

[Alex40 5]

I am glad to tell you that we finally managed to fix the issue with the missing libs for the Android Service. 

 

The Service.template.java file was causing this problem. It is generated when service is built.

 

The file was outdated, below you will find the difference in the files:

 

NEW:

@Override
public void onCreate() {
libraryName = "lib" + baseLibraryName + ".so";
super.onCreate();
ProxyService.onCreate(this, libraryName);

 

OLD:

@Override
public void onCreate() {
libraryName = getApplicationInfo().nativeLibraryDir + "/lib" + baseLibraryName + ".so";
super.onCreate();
ProxyService.onCreate(this, libraryName);

 

To be sure you have the latest version of the template java file, named "SERVICENAME.template.java" - when you upgrade to higher version of Delphi, just delete the file from the Service project folder and build the Service again, so the Delphi Compiler generates the latest one. If you have custom settings there, you will have to include them again in the new file!

 

Regarding the OpenSSL libraries issue - I haven't tried to set their lib path the same way as the service does, but as far as they work in the Document path, I am fine with that.

 

You can see as well the difference between the old and the new file in the screenshot below:
 

Edited February 15, 2021 by Alex40

[at3s 4]

On 2/15/2021 at 3:36 PM, Alex40 said:

I am glad to tell you that we finally managed to fix the issue with the missing libs for the Android Service. 

 

The Service.template.java file was causing this problem. It is generated when service is built.

 

The file was outdated, below you will find the difference in the files:

 

NEW:

@Override
public void onCreate() {
libraryName = "lib" + baseLibraryName + ".so";
super.onCreate();
ProxyService.onCreate(this, libraryName);

 

OLD:

@Override
public void onCreate() {
libraryName = getApplicationInfo().nativeLibraryDir + "/lib" + baseLibraryName + ".so";
super.onCreate();
ProxyService.onCreate(this, libraryName);

 

To be sure you have the latest version of the template java file, named "SERVICENAME.template.java" - when you upgrade to higher version of Delphi, just delete the file from the Service project folder and build the Service again, so the Delphi Compiler generates the latest one. If you have custom settings there, you will have to include them again in the new file!

 

Regarding the OpenSSL libraries issue - I haven't tried to set their lib path the same way as the service does, but as far as they work in the Document path, I am fine with that.

 

You can see as well the difference between the old and the new file in the screenshot below:
 

Probably I have similar issue - application is freezing on splash screen in devices with the 64-bit system.

I'm using libssl.so v 1.0.2r.

The path is defined in an application in this way:

IdOpenSSLSetLibPath(TPath.Combine(TPath.GetDocumentsPath, 'lib/arm64'));

And file deployes in .\assets\internal\lib\arm64 folder.

Where can I find that "SERVICENAME.template.java" file?

It seems, I have not it.

[Alex40 5]

On 2/27/2021 at 8:24 PM, at3s said:

Probably I have similar issue - application is freezing on splash screen in devices with the 64-bit system.

I'm using libssl.so v 1.0.2r.

The path is defined in an application in this way:

IdOpenSSLSetLibPath(TPath.Combine(TPath.GetDocumentsPath, 'lib/arm64'));

And file deployes in .\assets\internal\lib\arm64 folder.

Where can I find that "SERVICENAME.template.java" file?

It seems, I have not it.

The SERVICENAME.template.java that I mentioned above is used only when the Project uses a backround service. You don't need it for the ssl libraries.

To be sure you have an issue with the openSSL, do the following:

 

1) After setting the lib path, call the following code:

 

IdSSLOpenSSLHeaders.Load() 

 

2) Then use a Logcat to see what these two functions return:

 

OpenSSLVersion

 

IdSSLOpenSSLHeaders.WhichFailedToLoad()

 

You can see how I do it in the screenshot bellow:

 

 

Of course you can keep your folders lib\arm64. Ignore my folders 64 and 32. 

 

And one more thing - I am using OpenSSL 1.0.2q and you said you use 1.0.2r. I am not sure if they are fully compatible with 64 bit Android. PM me your email if you want me to send you my files.