Dave Nottage

Yes, you need to use static linking: https://docwiki.embarcadero.com/RADStudio/Athens/en/Connect_to_SQLite_database_(FireDAC)#Driver_Linkage

I mean not being able to have the debugger attach to the process on the device at all, regardless of whether or not there are breakpoints set. The install process should still succeed. If this an error you receive when attempting to install the app on the device using the IDE, it sounds like you have a development (as opposed to App Store) certificate/profile issue.

Actually, the messages I was referring to were warnings from before the privacy requirements came into force, as evidenced by this post on the German Delphi Praxis. Transporter might not be issuing warnings/errors any more; it could be that they're rejected at the review stage. One way to find out is to submit something 🙂

Yes. In Kastri, I have a "base" privacy manifest that covers this, in this folder, though the reason for mach_absolute_time used is 3D61.1. 35F9.1 is probably more relevant, and I'm not sure why the other one was chosen. Not "out of the box", as yet, as far as I know. See above 🙂 If you omit a required reason, Transporter will reject your app when you do an upload. If anyone has used the manifest from Kastri (I have not as yet), they haven't made me aware of any rejections at the review stage 🙂

TOSVersion.Architecture gives you the architecture of the processor that the app is executing on. Please ignore the fact that the documentation is outdated. Possible values are: arIntelX86, arIntelX64, arARM32, or arARM64.

This refers to: https://developer.android.com/training/data-storage/shared/photopicker Which Delphi already supports, at least in 12.2, and at least through the media library code.

10.2.3 worked (when I was using it) in Windows 11. No advice other than that 🙂

errno=13 is permission denied, so either there's insufficient rights to where the file is being output to, the file is already in use, or some external factor (e.g. Antivirus) is preventing access.

The warning (i.e. not an error)... ..has nothing to do with Spring4D. Rollo's error (i.e. not the warning part) was related to Spring4D. Your error: ld: can't open output file for writing: .\FmxMsgBox, errno=13 for architecture arm64 ..is for something else. Whatever FmxMsgBox is a part of.

You have ForegroundService.jar in both the 32-bit and 64-bit targets - when you compile for 64-bit it's attempting to include both into the one app. (Note that for the "system" jars, it just uses those for the target platform). If you're going to compile for either, remove the one from the 64-bit target.

If your app itself is downloading it, it won't need to go in a shared folder (which is what /storage/emulated/0/Documents is). The app could download it to a subfolder of the internal documents folder, e.g. a folder like this: LLibFolder := TPath.Combine(TPath.GetDocumentsPath, 'Lib'); ForceDirectories(LLibFolder); LLibFileName := TPath.Combine(LLibFolder, 'libTestLibrary.so'); Your download routine could then download the file to the filename specified by LLibFileName, and call LoadLibrary using the same path. Android and iOS are two very different operating systems.

I expect there will be a permissions error in the system logs (which you can view using a log viewer), unless you are using an earlier version of Android and have requested the relevant permissions. On Android 11 or higher, I doubt you'll make LoadLibrary work at all using that path. Is there some reason you are not deploying libTestLibrary.so with the application?

If you're using Delphi 12.2, you won't need to add it to the 64-bit target if you have already added it to the 32-bit target - it will still be compiled in. It appears you have somehow added the .jar that contains the service, twice. Can you detail what you have in the libraries nodes for both Android 32-bit and Android 64-bit in Project Manager? Just the entries under the last of the "system" jars, which would be: work-runtime-2.7.0.dex.jar, if you have Delphi 12.2. Selecting a jar should show the full path to it, in the status bar of Project Manager.

Most likely. The only bearable way I have found of using an Android emulator is to have a Mac with a silicon chip (e.g. M1, M2 etc), and run Arm64 emulators on it. Delphi can communicate with them using the relevant adb commands, along with a secure shell client such as PuTTY, all of which I describe in this video.

Those executables have been removed from the SDK - now you need to use either the command line tool, or install Android Studio and use the Virtual Device Manager. Note that running emulators on Windows can be horrendously slow. You're way better off using a real device.

The OP asked about LoadLibrary, so I referred to LoadLibrary. The documentation does not list it, but it's there.

For Posix systems (Android, iOS, macOS, Linux) use LoadLibrary from System.SysUtils - it wraps dlopen, which Remy mentioned.

You already asked on StackOverflow, where I commented on it. i.e. "WearOS is just a subset of Android (but also includes its own functionality). You can write apps for it with Delphi, but need to bear in mind the differences" (Comment has a correction because I erroneously referred to WatchOS) One of the major differences being the screen size is a lot smaller. You could do it with that. I've created WearOS apps with Delphi, including 12.2. I'd need to seek permission to make the code public.

Please refer to this documentation.

It appears to be up at the moment - can you try again?

What does GetFilePathFromUri return? I expect it's nothing as well. Check the Android section of the readme for information on how to access the file

None of them have a: "Don't touch my assignment alignments" option? 🙂

That's not even an error - it's a command issued by PAServer as part of the process to discover what certificates/profiles are available on your Mac. What is the actual issue you are having? It would be helpful if you provided: what version of Delphi you have and what version of Xcode is on the Mac. Given the cut-off part of the messages in the screenshot, it appears you are using a version of Delphi earlier than 12.2. Note that earlier versions of Delphi will not work with Xcode 16 (or later), since there was a change to the location of the provisioning profiles in Xcode 16. If you are using Delphi 12.1 or earlier, and Xcode 16 (or later), you'd need to either upgrade to Delphi 12.2, or revert to the last version of Xcode 15 (which is 15.4)

You have not answered this part: Meaning which version was used to compile the app where the problem is happening. Regardless, are you able to reproduce the issue (RSP-23962) using the same steps as in the report? If so, please indicate what device(s) this is happening on.

My bad.. I had forgotten that I did some modifications to Grijjy.OAuth2.pas to allow signing with ES256 as well as RS256. For now, I've attached the modified unit here. Please place it in the same folder as the project. Grijjy.OAuth2.pas