Pierce Ng

Your app is connecting to MongoDB as a client. The common authentication method is username/password. Your app only needs its own TLS certificate and key if the MongoDB server is configured to mandate client certificate authentication, as described here: https://www.mongodb.com/docs/manual/reference/configuration-options/#mongodb-setting-net.tls.allowConnectionsWithoutCertificate. (I listed three relevant URLs, but the forum software decided that three URLs => this post is spam, so now just one. Duh.) Ask your MongoDB admin whether the database mandates client certificate authentication. If the answer is no, using username/password should work. Azure Cosmos DB MongoDB, by default, works with username/password over TLS. If it's FireDAC that expects client certificate and key to be specified for username/password authentication, ask your FireDAC support. Actually just try not setting those two parameters and see if your app works. But note this disclaimer from the FireDAC link:

You'd use a MongoDB client driver for Delphi. Here's a blog post I wrote talking to Azure Cosmos DB MongoDB using mORMot, which has a native MongoDB wire protocol implementation in Pascal. My code uses Free Pascal, but mORMot works with Delphi too. https://samadhiweb.com/blog/2023.03.04.mormot.azure.html

I've considered such an approach though I haven't tried doing it. TL, DR: Working out how to generate and use Delphi source code from OpenAPI specifications of these cloud SDKs will give more bang for the buck and be kinder to one's sanity. Below is AWS Javascript SDK S3 example. Prerequisites include Node.js. 1st key point: The example logs to console. To do useful work, you'll have to figure out data interchange between Delphi and Javascript within your program. 2nd (but really the) key point: Because Node.js is a prerequisite for the AWS SDK, you're not just embedding Duktape in your Delphi program, you're looking at embedding Node.js, with all the work that entails, given that Duktape isn't the default Javascript engine for Node.js and may not actually be good enough for current versions of Node.js. import { S3Client, CopyObjectCommand } from "@aws-sdk/client-s3"; const client = new S3Client({}); export const main = async () => { const command = new CopyObjectCommand({ CopySource: "SOURCE_BUCKET/SOURCE_OBJECT_KEY", Bucket: "DESTINATION_BUCKET", Key: "NEW_OBJECT_KEY", }); try { const response = await client.send(command); console.log(response); } catch (err) { console.error(err); } };

You're using 'arm-linux-androideabi-ld.exe' (for 32bit ARM) to process '...\Android64\Release\System.o' which is for 64bit ARM. /mnt/c/Program Files (x86)/Embarcadero/Studio/22.0/lib/android64/release% file System.o System.o: ELF 64-bit LSB relocatable, ARM aarch64, version 1 (SYSV), with debug_info, not stripped /mnt/c/Program Files (x86)/Embarcadero/Studio/22.0/lib/android/release% file System.o System.o: ELF 32-bit LSB relocatable, ARM, EABI5 version 1 (GNU/Linux), with debug_info, not stripped Toolchain executables for 64bit ARM are in '<ndk>\toolchains\aarch64-linux-android-4.9\prebuilt\windows-x86_64\bin'.

TIL: As per Run ARM apps on the Android emulator, "The new Android 11 system images are capable of translating ARM instructions to x86 without impacting the whole system." As per SO, "ARM64 emulation on a x86_64 host currently is only possible up to API level 27 Oreo". So I set up an API level 27 system image for the emulator, and the Delphi-built APK runs on it. Well, "runs" is not quite it, more like "crawls". Doing ARM emulation on x86_64 is just too slow. My laptop dual-boots Linux and Windows. When Linux, my setup builds x86_64 .so files for the emulator, and arm64-v8a .so files for my phone. The laptop is low-end, and such a setup at least makes it usable for tinkering with building Android apps. I also tried setting up another SDK in Delphi to build for x86_64, but that fails because the object files in C:\Program Files (x86)\Embarcadero\Studio\22.0\lib\Android64, which are linked into the generated APK, are arm64, not x86_64.

I just installed Delphi 11.3 CE. Encountered this too. The app runs on my phone but not on the emulator, reporting same error "Your Android device does not support blah blah." The APK file is a zip archive. Here's the Delphi-generated APK: % unzip -v Project1.apk Archive: Project1.apk Length Method Size Cmpr Date Time CRC-32 Name -------- ------ ------- ---- ---------- ----- -------- ---- <more lines> 31936608 Defl:X 6835125 79% 1980-01-01 08:00 11348172 lib/arm64-v8a/libProject1.so 21628 Defl:X 9693 55% 1980-01-01 08:00 ffb92c06 lib/armeabi-v7a/libProject1.so 25720 Defl:X 10952 57% 1980-01-01 08:00 ae7d68da lib/armeabi/libProject1.so 71860 Defl:X 7968 89% 1980-01-01 08:00 4b4fa900 lib/mips/libProject1.so <more lines> -------- ------- --- ------- 39609799 9922649 75% 26 files Here's an APK I built on Linux using an Android Studio project setup, with Gradle, Cmake, etc. The .so file is built using Free Pascal btw. This app runs on my arm64-v8a phone and the x86_64 emulator on my Linux. I just "adb install" it to the Windows emulator; works there too. % unzip -v app-debug.apk Archive: app-debug.apk Length Method Size Cmpr Date Time CRC-32 Name -------- ------ ------- ---- ---------- ----- -------- ---- <more lines> 90360 Stored 90360 0% 1981-01-01 01:01 febe2452 lib/arm64-v8a/libdwprunner.so 80728 Stored 80728 0% 1981-01-01 01:01 f217b3ea lib/armeabi-v7a/libdwprunner.so 81228 Stored 81228 0% 1981-01-01 01:01 bbe69e19 lib/x86/libdwprunner.so 74304 Stored 74304 0% 1981-01-01 01:01 6537ec19 lib/x86_64/libdwprunner.so <more lines> -------- ------- --- ------- 20094501 13777010 31% 810 files Notice my Delphi APK has arm64-v8a, armeabi-v7a, armeabi, and mips (are there still MIPS phones around?) but no x86_64. Can you run "unzip -v" on your APK and see what you get.