Dave Nottage

You should consider compiling the text into the app and loading it as a resource. See here: https://stackoverflow.com/a/8943364/3164070

I'm sure there is, since there's been a number of changes in the last 3 years. Check the changelog for v5, for example: https://github.com/facebook/facebook-ios-sdk/blob/master/CHANGELOG.md

That's just the timer. Battery life will be affected by the settings used with the actual location services, as determined by MonitoringDistance and MonitoringInterval. There's some information here about the best strategies to use: https://developer.android.com/guide/topics/location/strategies

The ActiveMobileDevice tag in the .dproj.local file has info about connected devices. Whether it retains "old" devices I don't know.

You don't have Read Call Log and Read Phone Numbers permissions set in the Project Options for Android 64-bit.

If you're still having trouble, please look at line 175 here: https://github.com/DelphiWorlds/KastriFree/blob/master/API/DW.iOSapi.Firebase.pas Basically forces the linker to link to libclang_rt.ios.a, which has the "missing" symbol

That is awesome! Great news

Glad to hear it's helping you! 🙂

I've just checked in changes to this demo that include posting the location updates to a SQLite database. Service starts OK in it, at least for me.

I doubt it, since my device is Android 10. I'll have a play around tomorrow to see what I can deduce.

Nice, thanks!

Mine works OK with that unit in it.

OK, for some reason I was under the impression that it was being raised when the socket was closed without an attempted read/write. I'll have to revisit that, thanks 🙂

It's the most annoying exception, ever. It's a permanent "ignore" in my exception tracking code. It'd be great if it was just removed, permanently.

Compiles OK here.

I'm able to use FireDAC with SQLite OK in the demo you refer to. Can you provide a test project for the TDSRestConnection issue?

There's an image here with EXIF data: http://orchids.enwphotos.com/2013-1/310.html Which includes the camera make etc. I use a Chrome plugin to view the data: https://chrome.google.com/webstore/detail/exif-viewer/mmbhfeiddhndihdjeganjggkmjapkffm I doubt it, since the camera make and model is in text form, not an index to different models Are you referring to Delphi code? Also, description and title are not known tags - perhaps you're referring to ImageDescription? There's a list here: https://www.exiv2.org/tags.html. Note that not all images will have anything in this tag. There's an answer on SO that suggests a simpler method of extracting EXIF at least in relation to JPEGs: https://stackoverflow.com/a/18624442/3164070 There's also a couple of alternatives to CCR-EXIF, here: https://torry.net/pages.php?id=104

I suspect that attaching an image file here strips the metadata, since the one you attached appears to have none, or at least the EXIF data is gone.

Whoops! Yeah, I actually discovered that after my comment on the report. I've now updated it. Please refer to my comments on the report: https://quality.embarcadero.com/browse/RSP-18329

Incidentally, I suspect that leaving it "acquired" can consume a lot of battery (due to what happened to my device), so it might pay to check when the screen locks and do a release.

As far as the MulticastLock goes, you should call acquire when your app needs to listen (i.e. when your TIdUPDServer is active), and release when it does not. That said, I've given up on Indy for multicast because there have been too many hoops to jump through, including for Android.

There does not appear to be anything in the log that gives any clues as to why it hangs. This why it's important to also use the debugger and/or refine the code into a reproducible test case.

As far as the SDK settings go, I believe it derives the JDKPath from one or either of the JDK settings: You can check this in the registry:

Nothing so unusual: it takes less than a second.

Mine is currently 1920x1074, but changing it does not make any difference for me; the behaviour is still the same.