-
Content Count
23 -
Joined
-
Last visited
Community Reputation
1 NeutralTechnical Information
-
Delphi-Version
Delphi Community Edition
Recent Profile Visitors
The recent visitors block is disabled and is not being shown to other users.
-
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?
-
Targeting both Windows 10 and Windows 11 in appxManifest.xml
apachx replied to apachx's topic in Delphi IDE and APIs
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.
-
Targeting both Windows 10 and Windows 11 in appxManifest.xml
apachx replied to apachx's topic in Delphi IDE and APIs
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. -
Targeting both Windows 10 and Windows 11 in appxManifest.xml
apachx posted a topic in Delphi IDE and APIs
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! -
Advice on debugging Windows Store app while minimising submissions
apachx replied to Eric58's topic in General Help
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. -
In App Purchase (consumable and subscription)
apachx replied to Joe Sansalone's topic in Cross-platform
You're absolutely right - my bad. -
In App Purchase (consumable and subscription)
apachx replied to Joe Sansalone's topic in Cross-platform
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. -
In App Purchase (consumable and subscription)
apachx replied to Joe Sansalone's topic in Cross-platform
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. -
In App Purchase (consumable and subscription)
apachx replied to Joe Sansalone's topic in Cross-platform
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.