Dave Nottage

I thought I would have received an error indicating that it could not be executed. I also used TFile.GetAttributes to check whether it could be (it has all the execute attributes), and running ls -l on the containing folder (using the demo itself) suggests that it is executable:

There's now an example of how to run a process on Android, here: https://github.com/DelphiWorlds/HowTo/tree/main/Demos/AndroidRunProcess Sadly, I have been unable to make it work with the Stockfish application that is available for download here: https://stockfishchess.org/download/ The process seems to start, however it also seems to lock up my application. There does not seem to be any clues in the device logcat messages as to what the problem is. The demo still includes the files, and the code that attempts to run it, however the code has been commented out in favour of some more basic executables that are known to work. I have put my efforts on hold (though I may use the run process code myself for something else), and have thrown it open to anyone else who might be able to make it work.

In future, please report issues regarding Mosco here: https://github.com/DelphiWorlds/Mosco/issues Also, please provide full error messages, and not images that have parts of the messages cut off. From the little information that is available, it may be you not have followed the required steps, i.e. select App Store build type and do a Deploy (which will fail, but is a necessary step), then use the Build IPA menu item.

This does not say that the app absolutely has to have a foreground service. The notification can be created without one: https://stackoverflow.com/questions/55324188/how-to-build-a-notification-in-android-and-implement-click-listener

You still have not explained what are you aiming to do specifically. It may be that whatever it is, can be done some other way. Yes - they're part of a commercial product, i.e. people are paid to write them.

If you don't know how to use the imported classes, I'm curious as to what exactly you're aiming to do.

Not "out of the box". Here's a link that includes the Java equivalent: https://stackoverflow.com/a/5642593/3164070 ..and an import for the Process and Runtime classes: https://github.com/DelphiWorlds/Kastri/blob/master/API/DW.Androidapi.JNI.Lang.pas That should at least give you a start

That's information about foreground services. How does "a persistent menu on the status bar for next/play/pause musics" relate to it?

I thought that's something that what was causing problems before? Weird. Anyway, good to know, and thanks for the update

Can you provide links to the research that shows that is what is required?

That's very cool!

I suspect Ken is referring to icons and launch images. I'd be interested in seeing it

Yes: https://github.com/DelphiWorlds/Kastri/tree/master/Demos/AssetDelivery

You have FMX.Types in the uses clause of Unit2 in your service. Not sure why, since it does not even need to be there. Regardless, that is why your service is failing. Please see this report: https://quality.embarcadero.com/browse/RSP-17857

Links to Installers for Codex 1.5.1 and Mosco 1.2.1. Includes workaround for App Store builds with Xcode 13. Requires at least Mosco to be installed, however the Codex tool adds a convenient way of applying the workaround. Workaround steps: Build/Deploy your app using App Store config (which will "fail" with Xcode 13) If using the workaround in Delphi itself, in Project Manager, right click the root node of the project and click "Build IPA" If using the workaround in Mosco, click the Mosco icon in the system bar to bring up the menu, click Fixes > Build App Store IPA. Select the app from the ~/PAServer/scratch-dir/[username]-[profile]/ folder and click Build https://github.com/DelphiWorlds/Codex/blob/master/Bin/CodexSetup_1.5.1.exe https://github.com/DelphiWorlds/Mosco/blob/master/Bin/Mosco.1.2.1.pkg Use o Google Translate se quiser as instruções em português: https://translate.google.com

It's because Delphi 10.4.2 is using Jarsigner instead of APKSigner, which is required for APKs with a target SDK of 30 or higher. There are ways around it, however you are just delaying the inevitable. The bottom line is: If you want to stay current with Android development (or iOS, especially if deploying to the app stores), stay current with Delphi.

There's a couple of problems with your deployment to Google Play: One of them suggests you're using a older project in Delphi 11, and have not performed "Revert System Files to Default" for at least Android 64-bit (my device is 64-bit so it only installs an .apk for 64-bit), in the Libraries node for the target platform, in Project Manager The other suggests the deployment information is incorrect for at least 64-bit. Once you have deployed, go into Deployment Manager, and select Android 64-bit target. Make sure there aren't any greyed out items that shouldn't be. You may have to use the Revert button (looks like an Undo icon) to make sure the entries are correct, then rebuild and redeploy.

Sorry, I thought you meant it was public. You'd need to invite me to the test group 🙂

Can you provide a link to the app on Google Play, or at least the name of it?

uses iOSapi.CoreLocation; if TCLLocationManager.Create.locationServicesEnabled then // Location services are enabled

uses iOSapi.CoreLocation; if TCLLocationManager.Create.locationServicesEnabled then // Location services are enabled

Apparently it's an issue with debugging iOS apps when using Monterey. Unfortunately it seems the current workaround is to use an earlier version of macOS 😞

Please refer to this comment, and the other comments in the same post:

I wasn't able to ascertain what the cause is - I can only suggest filing a report on QP for it.