Dave Nottage

That's because you don't need to. Possibly - the Java signatures in that file look a bit odd. Is the .jar file available publicly?

Is there some reason why you haven't included here what it suggested? You can access the ContentResolver via: TAndroidHelper.Context.getContentResolver, by including the Androidapi.Helpers unit. Regardless, I expect you'll need to use a library such as smbj to access files via Windows shares, which means either finding a Delphi implementation or creating imports and writing the code yourself that uses smbj (or some other library that does the same thing).

With this: uses Androidapi.JNI.Os; LHasAccess := TJEnvironment.JavaClass.isExternalStorageManager; Note that this applies from Android 11 onwards only, so you should use TOSVersion.Check(11) to determine whether or not to manage that permission

As I mentioned in my first reply, you could use the code from TNotificationCenterAndroid.CreateNativeNotification as an example. Inside that is this: function GetDefaultIconID: Integer; begin Result := TAndroidHelper.GetResourceID('drawable/ic_notification'); if Result = 0 then Result := TAndroidHelper.Context.getApplicationInfo.icon; end;

You'd need to create the notification using the underlying classes, since the notification implementation in Delphi is yet to support "sticky" notifications. You could use the code in the TNotificationCenterAndroid.CreateNativeNotification method in rtl\common\System.Android.Notification.pas as a guide, and use the setOngoing method to make it "sticky". It's not exactly clear from your post what else you need solved.

That usually means you have not added the required .jar file (the one you ran Java2OP on) to the project. In Project Manager: Expand the Android 32-bit target Right-click on Libraries Click Add.. Select the .jar file Click OK Note that the .jar will be compiled in regardless of whether you compile for 32-bit or 64-bit.

Yes, it should be. My Mosco app is a signed and notarized app, and has these entitlements: It starts OK for me on macOS 15.1, but is built with Delphi 12.2. Not sure whether that might be relevant?

It's: TJcontent_FileProvider instead.

A client has well established products that are based around the MDI model, and are using the concept of "desktops" by hiding/showing MDI children so that the state of the forms is maintained. The concept of hiding MDI children is actually not officially supported in Delphi, so to work around this, ShowWindow is called thus: ShowWindow(FormHandle, SW_SHOW); // or ShowWindow(FormHandle, SW_HIDE); ..where FormHandle is the handle of the MDI child being shown/hidden. This worked well, up until Delphi 12, when the message handling for forms was reimplemented, using TChildFormMessageHandler (in Vcl.Forms). The new (undesired) behaviour is that once a child form has ShowWindow called on it, then that form becomes active, the last form that was hidden becomes visible again. This can be reproduced using the attached project by using the following steps: Run the app Click File | Show Desktop 1 Click File | Show Desktop 2 Click File | Show Desktop 1 again Set focus to the visible form - the form that "belongs" to Desktop 2 becomes visible again As described above, this works OK in Delphi 11.3. At this point, reimplementing the app away from MDI is a non-option. I'm aware that whatever measures are needed will be a "hacky" workaround - it started out that way anyway. Now for the kicker: this is a package-based application, so I can't even "hack" the Vcl.Forms source. Using a "detours"-like solution might be an option. Any help with how to resolve this would be greatly appreciated. MDIIssue.zip

No mention of a 12.3, however in a webinar (I think the one for 12.2) they said 13 would not be skipped.

At the moment you can safely ignore the warning. At present, there's no "out of the box" solution for it. See my comment on this SO post. For what it's worth, it appears Flutter developers have (or at least did have) the same issue.

Not sure if you are still using 10.4.2, or if this will compile in 10.4.2, but: function IsDarkMode: Boolean; var LStyle: string; LDefaults: NSUserDefaults; begin LDefaults := TNSUserDefaults.Wrap(TNSUserDefaults.OCClass.standardUserDefaults); LStyle := NSStrToStr(LDefaults.stringForKey(StrToNSStr('AppleInterfaceStyle'))); Result := False; if LStyle.Equals('Dark') then Result := True; end;

Just curious: what do you plan to do with CarPlay? Incidentally, I just updated the import for the framework in Kastri.

That's odd, since I was sure it was not working on iOS when I last touched it. Is this using version v8.15.0 of the Firebase iOS SDK? It might be failing with later versions.

Apparently it's because Indy does not have SSL bindings for encryption on iOS. See this issue. Perhaps @Remy Lebeau can comment.

Why do you need to send push messages from an iOS device? It's a very bad idea to have private key info in an iOS app. In a web server (where messages should be sent from), the executable (and private key) is (or at least should not be) accessible externally. From here: https://github.com/firebase/firebase-ios-sdk/releases/download/CocoaPods-6.28.0/Firebase.zip ..but the code example above which sends messages does not require the iOS SDK, which is used for receiving messages.

If they're actual issues, I'd rather them being reported here. I'm sure it's perfectly alright to ask questions in this forum, though.

A follow-up to this: I have contacted their support team, who requested that I provide a video demonstrating the problem 🙄. I have since replied, asking them if they really are incapable of doing two simple steps (Using Windows: download, and try to open) to replicate it themselves.

Both unzip OK on macOS, so I tried to "re-zip" the 11.2.0 version on Windows, but that causes Explorer to crash 😞 I've asked a question about it in their Slack workspace, since all the other reporting mechanisms don't seem to cover this category.

There's this link at this page, however it might just be a redirect to the latest version (11.3.0) I notice a huge difference in size between 11.2.0 and 11.3.0 - 319MB vs 612MB!!

What is the exact message from Play Store? Seems rather odd. Both of those ship with Android 12 - do they both have Android 12 now?

See this documentation. Authorization is now via an OAuth2 token - there is a link in the documentation to details about methods for obtaining the token.

For anyone else coming across this link, it has moved to: https://chapmanworld.com/calling-linux-commands-from-delphi/

It might help to show the code you're using.

Sounds like you already worked that out? i.e. create the PDF control beforehand.