Dave Nottage

Même chose 😄

If it's just data synchronization, is not user initiated, and you want it in Delphi code, you may be stuck.

This kind of background task scenario calls for using a Worker descendant, which is yet to be supported in Delphi. Location monitoring in the background is achievable with Delphi, however capturing location events cannot be at defined time intervals - they occur (oddly enough) when the device location changes. You could however check what the time is when a location update occurs, and if it is close enough to your defined time, take action then. If no location update is available at a defined time it could be assumed that the device is stationary. I had been struggling for some time to implement location updates in the background in a reliable way, however with this latest demo in my Playground repository, it has become the most reliable yet. The next step is to be able to have it start at boot time, which unfortunately in newer versions of Android requires user interaction.

The debugger for Android has been unusable* for me for some time now. I have learned to live with using log statements and a logcat viewer, such as Device Lens. *I guess that aligns with not being able to debug on iOS, too.

Personally, I create .pkg files - using the create installer function of Mosco.

Using a value of slDynamic for FDPhysSQLiteDriverLink1 EngineLinkage works for me

Sorry, I had that backwards - static linking causes the issue, or at least it did in the early days. When I have time, I'll check which way around it is, and/or whether or not it will work at all.

No. Why would you want to?

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.