alejandro.sawers

A common issue when compiling the same Android project between Delphi versions is that system libraries change, but the project doesn't update them automatically (by design apparently) so try that first. Also check if your project has custom versions of Delphi units and delete/update them as these can be a source of incompatibility issues.

There are multiple issues here, but let's start with this one: From Android 11 onwards the storage permissions model has changed. Please see the official documentation about WRITE_EXTERNAL_STORAGE and, depending on your app's specific needs, you should not have problem on finding and implementing an alternate solution for modern Android versions.

You can safely ignore the warning as long as the command completes successfully. That's expected as the command fixes issues with the SDK, not with the NDK. Given that you copied SDK/NDK files from another machine and also updated from 11.2 to 11.3 (and your NDK seems to be missing now) your best bet would be reinstall Delphi from scratch and only then apply the command-line (if needed at all of course). It is not. The link contains a workaround just in case you decide to update to Delphi 12 and use the offline ISO installer to do so. It also contains notes for several platforms so look carefully.

I remember the Android SDK installation failing here and there, sometimes for unknown reasons. Luckily I have and old VM with Delphi 11.1 installed and it seems that the Android SDK also failed here (red underline is mine): If this is how your installation looks then doing a command-line install of the missing tools should solve the issue. On the SDK folder you should have a "cmdline-tools" folder, go inside to "latest\bin" and locate "sdkmanager.bat". Open a command line window in the folder that contains "sdkmanager.bat" and run a command like this one (note the versions of "build-tools" and "platforms" on red that your IDE demands and adjust the command accordingly): sdkmanager.bat --install "build-tools;30.0.3" "platform-tools" "platforms;android-30" After the command completes refresh the SDK Manager page. Unless you use the ISO installer, which causes a very similar issue but easier to fix.

Seems like the NDK is being bumped to r27, which aligns to the official recommendations to support 16 KB page size Android devices in the near future. But it could also be just a coincidence.

I think I will skip 12.2 Patch 1 because RSS-1840 was the only issue resolved with significant impact for me but there is a good enough workaround for 12.2 already, so reinstalling everything (that I have compiled with 12.2) is not worth the hassle right now. Waiting for 12.3 instead.

Just as a follow-up the workaround posted by @Borni has the side-effect of sending the caret to the end of the line when deleting a character using the soft keyboard, so I ended up changing this: To this: FTextView.setSelection(SelStart); Additionally there is another exception thrown when moving the caret with selected text to a line with less characters than the current selection (this happens on Samsung and non-Samsung devices alike). To mitigate that I had to add a couple of lines just before the if SelEnd - SelStart > 0 then check (line 1953) in the same procedure: // Normalize selection indexes SelStart:=Min(SelStart, JCharSequenceToStr(FTextView.getText).length); SelEnd:=Min(SelEnd, JCharSequenceToStr(FTextView.getText).length);

As @Dave Nottage says this is a change introduced on macOS 15, most specifically a "fix" for XCode 16. Alternatively to Dave's solution, if there is no Apple ID linked to Xcode and you can't/don't want to link it you could also copy all the profiles from the old location to the new one: cp -R ~/Library/MobileDevice/Provisioning\ Profiles ~/Library/Developer/Xcode/UserData This was tested on a Mac with no profiles installed on the new folder whatsoever. This command shows on the PAServer terminal with verbose mode enabled, but its output is consumed internally by PAServer and not printed. You can always run the same command on another Terminal to explore the output.

Even though Delphi 12.x officially only supports Android 10+ devices as targets its actually possible to compile for lower Android versions with some tweaks on the NDK and the app Manifest. So far, so good it works as expected, but seems like there is an incompatibility when trying to add Firebase Messaging support and running it on an Android 5 device (i.e. API level 21, the lowest supported so far) : java.lang.NoSuchMethodError: No virtual method detectResourceMismatches()Landroid/os/StrictMode$ThreadPolicy$Builder; ... at com.google.firebase.FirebaseApp.initializeApp(FirebaseApp.java:264) at com.embarcadero.firebase.provider.FirebaseInitProvider.onCreate(FirebaseInitProvider.java:67) Effectively detectResourceMismatches() was introduced later, on API level 23, so this explains the crash at app startup on Firebase initialization. Now what puzzles me is while Firebase docs claim to offer support to Android versions as low as API level 19 (4.4), Firebase on Delphi calls an API level 23 method on initialization. By the way the same docs also say that "some products might have stricter requirements", so to be sure I checked the Release Notes to see if Messaging requires a higher API level to run, but apparently API level 19 is OK for the Firebase libraries included with Delphi 12.2: For now I'm disabling automatic Firebase initialization for Android 5 devices to avoid the startup crash (using the tools:node method didn't work, removing the <%provider%> tag from the Manifest template did). Hope a workaround (maybe downgrading some Firebase dependencies) is found before having to drop the Lollipop 🍭.

Put my hands on a Samsung A12 and can confirm the issue when pressing the return key: Testing on a Redmi Note 11 doesn't cause the exception, but by @havrlisan's comment it does happen when tapping on the memo to move the caret from a non-empty line to an empty one. This change seems to solve the issue on both Samsung and non-Samsung devices.

A quick test on a Delphi 12.2 blank FMX app with only a TMemo, compiled for Android 64, running on an Android 13 device doesn't show such error. Maybe test with a blank project to discard issues with your Delphi/Android SDK installation.

If you are using the offline ISO installer then you might need to reinstall the Android SDK alone.

Seems like the issue with Android SDK when using ISO installer is still present on the latest ISO. The same workaround as for the 12.1 ISO still works.

I think the best you could have done is to post in advance what you have tried to do and how far you reached on your implementation, along with technical details as what Delphi version you use, if you test on device or simulator, etc. Anyway the best you could do to find the culprit on your own is to test with the Kastri supplied demo and/or a blank project, then: - If that works check what is different between the working project and your old project. - If that doesn't work then the issue could be elsewhere (Firebase project config, APN certificates, FCM backend giving errors, etc.)

While this could frustrate some users, the truth is that approximate location access is not suited for most geolocation applications/features. Now if the user has given a incorrect location level access to the app (probably by mistake) it should inform the user so the permission level is corrected before accessing the features. Now for Delphi FMX apps this is trivial in Android as there are two separate permissions for approximate and precise location access and a simple query helps to determine the access level granted. The culprit is iOS, as since iOS 14 the accuracy authorization level is separated from the location authorization status itself, and apparently there is no way to access such value from user code (accuracyAuthorization is a CLLocationManager instance property but such instance is buried on the implementation section of System.iOS.Sensors.pas). So before patching this file and fighting the compiler about dependent units "compiled with another version of...", all without knowing if this would work at the end, I would like to know if somebody found another way to achieve this.

Thanks Dave, this works like a charm and without patching anything. Hope Embarcadero adds an attribute/function to TLocationSensor (much like Authorized) to consolidate this.

When targeting Android 15 (API level 35) the system now enforces edge-to-edge UI. As described in the documentation apps not designed to be edge-to-edge could expect issues with app content being hidden by the status bar, nav bar, etc. FMX Android apps seem to be impacted. Here is a test on a blank Delphi 12.0 Android app: when targeting Android 14 (first image) the UI is ok, but when targeting Android 15 (second image) the sample button gets behind the status bar and is not clickable. Effectively a breaking change. The official docs give instructions on how to make an app edge-to-edge compliant, however I'm not sure how these instructions could be applied to FMX apps (I'm not really well versed on native Android development) or if a workaround exists by patching .pas source files. I hope the latter is possible.

Given your latest findings on this other thread looks like your problem is not related to Android 15 after all. That and also the fact that Samsung is the one who takes the most time to release Android upgrades (or at least it was that way a few years ago).

On the new portal, more info here. The launch was far form ideal. At the beginning it was not possible to view other people's reports, but I think they have improved the site since then because existing reports by others are now visible. Well, on the old portal I submitted a total of 6 bugs of which 5 were resolved and one was related to a third-party component. Maybe I've been just lucky, because many people have their tickets open for years or closed as fixed when in reality the issue persists (as the submitter claims it). Report this anyway, and attaching a minimal project where the problem can be consistently reproduced will help them to quickly find a fix (to be delivered on the next release, if you're lucky).

Does your phone have other apps installed that were made with earlier Delphi versions? Maybe you could try to uninstall all of them and see what happens.

iPhone X with iOS 16.7.8 here, light themed Delphi 12.1 (with patch 1), Xcode 15.4, Skia enabled, target iPhoneOS 17.5. Blank FMX apps runs ok A possibility is that a specific component in your app fails under this specific configuration. It would be great if you can work closely with your customer to pinpoint the issue, by getting specific details of the device (iOS version, theme, settings) or to offer test build variations through TestFlight.

Not right now, but I know sometimes Embarcadero can miss things like these and put us in a hurry eventually. I tried this with the same FMX app (I had to put a Client aligned TLayout for Padding to work and then the TButton inside it) and voila: Thanks Dave. This should work until an official fix is given.

Well, guess the best I can do for now is raise a ticket on the support portal and wait for the best.

From the official docs: Given that FMX Android apps are served as native code I suspect this change could mean something that Embarcadero should check carefully. Luckily the same page offers links on how to test an app on a 16 KB environment (emulator), so I did with a blank FMX app and... libc Fatal signal 11 (SIGSEGV), code 2 (SEGV_ACCERR), fault addr 0x7d7f34f39000 in tid 5935 Yes, the app crashes at startup, but it works on a non-16 KB emulator. Maybe is too early to tackle this problem yet (no 16 KB devices on the wild afaik), but given that this change could be complex (update NDK?) and take a while (Delphi 13?) I hope there is something devs can do to fix this on our own with what we have at hand (i.e. Delphi 12.x). As a side note I tested this on an Android emulator running on a Mac with M2 chip as ARM emulation is no longer possible on Windows.

Well, no existing reports found so I created a ticket. Lets see what happens now.