Jump to content

Alex40

Members
  • Content Count

    14
  • Joined

  • Last visited

Community Reputation

1 Neutral

About Alex40

  • Birthday 10/19/1991

Technical Information

  • Delphi-Version
    Delphi 10.4 Sydney

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. 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.
  2. 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:
  3. 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.
  4. 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.
  5. 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.
  6. 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.
  7. 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
  8. 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. 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!
  9. 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 1) OpenSSLVersion() does not report anything (returns empty result) 2) WhichFailedToload() returns: Failed to load /data/app/com.myapp.app/lib/arm64/libcrypto.so.
  10. 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.
  11. 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.
  12. 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 !
  13. Alex40

    iOS handle incoming url

    This worked great on my application with Rad Studio Sydney 10.4.1, iOS 14.3 and Xcode 12.3. I had some issues of firing the OpenURL event, but now everything works as it should be. Thank you very much !
  14. Alex40

    Content not filling screen on iPhone 6

    I have the exact same problem and deleting the cache and app, restarting the iphone did'nt help. Any advice?
×