apachx

To ensure apps run correctly on recent Android releases, Google Play requires that all apps targeting Android 15+ support 16 KB memory pages. I’m using Delphi CE 12.1 with AndroidSDK-2525-23.0.51961.7529 and NDK 23.2.8568313. My app contains only one native .so library and no third-party native libraries. The .aab I build contains under base/lib only a single arm64-v8a folder, and inside it just libMyApp.so. In the Delphi Compiler linking settings I added the flag -z max-page-size=16384 to Options passed to the LD linker. After building, I analyze the .so with llvm-readelf.exe and for every LOAD header I see Align 0x4000 - which indicates 16 KB alignment. When inspecting the .aab in Android Studio, the Alignment column shows no warnings either, which also suggests the library supports 16 KB pages. However, I uploaded the .aab to the Play Console three days ago and I still see the message: "Page size — does not support 16 KB memory pages". My question: How should I implement 16 KB page size support in Delphi 12.1 so that Google Play Console accepts the app and the check passes?

Hi. No. That’s why I created this thread.

Yes, I know this works in newer versions of Delphi. But the point is, if Embarcadero makes the Community Edition available for free, then it should also ensure some degree of backward support - at least in small details that Google periodically requires. A hotfix once every six months, or at least once a year, wouldn’t take many resources, but it would automatically generate significant "marketing" support from users. It’s not a good look to abandon developers who built their products with your tools, gained their own users, but then can't update in time and risk being blocked in the Play Market or elsewhere.

In Delphi 12.1 these settings look like this:

What’s confusing is that if you look at the ELF LOAD sections in the .so, the alignment is correct (0x4000), but when I inspect it with llvm-readelf -n, the .note.gnu.property section is either missing or not formed properly. From what I can tell, Google seems to rely on this ELF note as the official marker for 16 KB support, not just the LOAD alignment. I tried patching the .so with llvm-objcopy to add .note.gnu.property manually, and even hooked a PowerShell script into Delphi’s Post-Build Events, but the event actually fires before Delphi finishes producing libMyApp.so, so the patch never applies. The frustrating part is that Embarcadero clearly knows about Google’s new requirements, yet the Delphi toolchain still doesn’t emit a proper .note.gnu.property and there’s been no hotfix or workaround provided. Right now developers are left trying to patch .so files by hand, re-pack .aab files, or experiment with NDK tools, while time is running out before the Play Console enforces the rule.

Got it, thanks for the helpful information! In that case, I’ll use a more "brute-force" approach => I’ll comment out the <%application-meta-data%> line in AndroidManifest.template.xml and replace it with: <meta-data android:name="com.google.android.play.billingclient.version" android:value="7.0.0" />

I’m doing exactly that. But for some reason, Delphi 12.1 ignores the AndroidManifest.xml I create and takes the data from AndroidManifest.template.xml. If I delete AndroidManifest.template.xml, it gets recreated every time during deployment. I even tried adding this section in it: <meta-data android:name="com.google.android.play.billingclient.version" android:value="7.0.0" /> But immediately after that, Delphi still adds the same line with the old library version to the final AndroidManifest.xml: <meta-data android:name="com.google.android.play.billingclient.version" android:value="7.0.0" /> <meta-data android:name="com.google.android.play.billingclient.version" android:value="6.0.1" />

I’ve just double-checked everything, rebuilt the project, and yet Delphi still writes the following line into the AndroidManifest.xml inside the .aab file: android:name="com.google.android.play.billingclient.version" android:value="6.0.1" /> Is it possible that something in the IDE settings needs to be changed?

I also did this step according to the instructions. When building the project for the Application Store, in the \Android64\Release\MyProject folder there is an AndroidManifest.xml file with the correct line: android:name="com.google.android.play.billingclient.version" android:value="7.0.0" But jadx-gui shows a completely different AndroidManifest.xml under Resources\base\manifest\AndroidManifest.xml. It looks like I must have messed something up somewhere. I’ll start by removing the 32-bit version and keep only the 64-bit one as the target platform.

Interestingly, after making these changes and publishing my app to the Play Market, the Play Console notification about upgrading the Google Play Billing library disappeared, and everything seemed fine for quite a while. But a few days ago, this notification reappeared, and now I’m wondering: how exactly does Google determine that I’m still using the wrong version of the Google Play Billing library? In my project, I disabled the old libraries: billing-6.0.1.jar play-services-base-18.1.0.jar play-services-basement-18.1.0.jar play-services-tasks-18.0.2.jar and replaced them with the new version 7.0.0, according to the instructions. I also made the corresponding changes in the AndroidManifest.xml. I then built the .aab file and opened it with jadx-gui to analyze the package tree for any usage of billing-6.0. I couldn’t find a single reference to the old billing library. A text search for "6.0" returns nothing, while a search for "7.0" correctly shows the new library billing@@7.0.0. So why does Google Play Console still conclude that I’m using billing-6.0.1?

I'm developing a Windows application using Delphi 12.1 CE. In my current appxmanifest.xml, I have the following line: <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17763.0" MaxVersionTested="10.0.19041.0" /> As far as I understand, this targets Windows 10 only (max version 10.0.19041.0 => Windows 10 May 2020 Update). I want to make sure my app is officially recognized as compatible with both Windows 10 and Windows 11 in the Microsoft Store. To target max version Windows 11 23H2, is it enough to simply change the line to: <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17763.0" MaxVersionTested="10.0.22631.0" /> Will this be sufficient for the Microsoft Store to treat my app as compatible with both Windows 10 and Windows 11? Thanks in advance!

Looks like it worked - I can see on partner.microsoft.com that the app is available for both Windows 10 and 11.

Wow, thank you! I'll try it out. Upd: I followed all the steps exactly as you described. The project compiled without any issues, and I’ve already published it on the Play Store. I tested the in-app subscriptions using a test account - everything works perfectly, no issues noticed. Now I'll wait and see if Google approves the changes. Great tutorial - simple and very clear. Thanks again!

Hi. In my app, I'm using Google Play Billing Library version 6.0.0 (billing-6.0.1.dex.jar). But a few days ago, Google Play Console notified me that: Is it possible to migrate to Google Play Billing Library version 7.0.0 or newer in Delphi 12.1 CE? Has anyone already done this? I couldn't find anything useful on Google.

No, I haven't tested this hypothesis in the Microsoft Store yet. The default line in the AppxManifest.template.xml file looks like this: <TargetDeviceFamily Name="Windows.Desktop" MinVersion="%minVersion%" MaxVersionTested="%maxVersionTested%" /> But for some reason, it ends up generating the following in the final manifest: <TargetDeviceFamily Name="Windows.Desktop" MinVersion="10.0.17763.0" MaxVersionTested="10.0.19041.0" /> This seems odd, considering that Embarcadero says Delphi 12 supports Windows 11 provisioning. That's why I wanted to ask here first — in case there are any hidden pitfalls I should be aware of.

It only worked for me after I right-clicked on my .msix file, opened its Properties, went to Digital Signatures → Details, and installed the certificate into two stores: Trusted Root Certification Authorities and Trusted Publishers - not for the current user, but for the local machine. But I still can't test the add-ons functionality locally in my app, because it isn't recognized as purchased from the Microsoft Store: WindowsStore1.AppProducts.Count is always 0 and WindowsStore1.AppLicense.IsActive is false.

You're absolutely right - my bad.

Yes, at first I tried calling InAppPurchase.RestorePurchasedProducts instead of InAppPurchase.QueryProducts, but the event InAppPurchasePurchaseRestored(Sender: TObject; const ProductID: string; const Receipt: string) on Android never fires. Here’s its implementation in FMX.InAppPurchase.Android.pas: procedure TAndroidInAppPurchaseService.RestorePurchasedProducts; begin CheckApplicationLicenseKey; // On Android the restore functionality is irrelevant thanks to the inventory // system automatically identifying which products have been purchased end; As for InAppPurchase.QueryPurchases — this method is not available for direct use in TInAppPurchase.

Hi. I just tried your solution, but it seems it's not working. After successfully completing a subscription, every attempt to call InAppPurchase.QueryProducts fails to return my subscription in the Products list within the event InAppPurchaseProductsRequestResponse(Sender: TObject; const Products: TIAPProductList; const InvalidProductIDs: TStrings). This condition never evaluates to true: for Product in Products do begin if (Product.ProductID = PlayMarketProductID) and (InAppSubscription.IsProductPurchased(PlayMarketProductID)) then SUBSCRIPTION := true; end; If I revert back to the original FMX.InAppPurchase.Android.pas, everything works as before.

Just in case, this limitation of the TInAppPurchase component has already been reported in a ticket on the Embarcadero Quality Portal - https://embt.atlassian.net/servicedesk/customer/portal/1/RSS-3516. Who knows - maybe the developers will eventually do something about it.

This method doesn’t work for Delphi 12.1. But the good news is that subscriptions will still work without the need to edit any files, as suggested in that tutorial. The bad news, however, is that TInAppPurchase does not support the current version of the Google Billing API. It doesn’t understand multiple base plans (e.g., monthly and yearly) under the same subscription, nor does it recognize offers (such as discounts or trial periods) associated with those base plans. The component only detects the first base plan of a subscription marked as "Backwards Compatible" in Google Play. Now I understand why Delphi is rarely used for mobile app development - the delay in supporting newer Android versions and essential third-party APIs is unacceptable for business use.

Hi everyone, I’m implementing subscription functionality in my mobile app using Google Play Billing and TInAppPurchase in Delphi. I’ve encountered an issue that I hope someone here might have already faced and solved. When a user cancels a subscription, and the previously paid period fully expires, I expect that the app would stop recognizing the subscription as active. However, even after calling: InAppPurchase.SetupInAppPurchase; InAppPurchase.QueryProducts; …the subscription still appears active in the app — InAppPurchase.IsProductPurchased(PlayMarketProductID) continues to return true. But if I restart the app, the same method correctly returns false, and the subscription is no longer shown as active. This leads me to believe that either the TInAppPurchase component or the underlying Google Billing client caches the subscription status, and that cache isn't invalidated until app restart. 👉 Is there a way to force-refresh the current subscription state without restarting the app, after the subscription has been cancelled and fully expired? Thanks in advance!

And what? The same article for RAD Studio Athens: https://docwiki.embarcadero.com/RADStudio/Athens/en/Using_the_Google_Play_In-app_Billing_Service This page was last edited on 28 September 2015, at 14:19. Using the iOS In-App Purchase Service: https://docwiki.embarcadero.com/RADStudio/Athens/en/Using_the_iOS_In-App_Purchase_Service Note: Subscription-based types are not currently supported. This page was last edited on 21 January 2022, at 07:52. Is there any new tutorial about subscriptions? Where can I read more about it?

Hello! Could you please tell me if there have been any changes regarding support for subscriptions in mobile applications created with the latest versions of Delphi? I developed a mobile app for Android, published it on the Play Store, and now I want to add a subscription to this app — so users can pay, for example, $7 per month to use my app. That’s it. I am not selling any other digital content within the app. I am using Delphi 12 Version 29.0.52631.8427. Is it possible to implement such a subscription in my app? Because here: https://docwiki.embarcadero.com/RADStudio/Alexandria/en/Using_the_Google_Play_In-app_Billing_Service, it says: Note: Subscriptions are not currently supported.

Hello. I encountered a similar issue, although the error code is slightly different. My mobile application works well on most devices, but today I installed it on a Motorola G54 smartphone, and upon launching, I saw a strange error: Cannot create EGL PBuffer Surface: error code 12291. It sometimes occurs on the splash screen, and sometimes when a MultiView menu appears. I was only able to get rid of the error after I stopped using third-party styles (in my case, it was the Android Sterling Style). This solution worked for me since I couldn't find much information about this error online.