In-app purchases. As much as some may hate them, they’re definitely here to stay. They’re not without their advantages, though. An in-app purchase allows a developer to provide free and paid versions of their app without actually having to maintain two separate applications. If you publish your app on the Play Store, Google generally requires that your in-app purchases go through them (because of the 30% cut they get).
Thankfully, Google does make it pretty easy to set up in-app purchases with all the fun stuff like license verification. Developers can simply implement the Google Play Billing Library, and they’re pretty much set. In an effort to make handling in-app purchases even easier, Google has announced version 3 of the Play Billing Library with some new features and improvements as well as an important policy change.
Google Play Billing Library v3 – What’s changing
Version 3 of Google’s Play Billing Library allows users to pay in cash. This may sound pretty weird, but it’s probably not what you’re thinking. There are still a lot of places in the world where credit cards and bank accounts just aren’t that common. This feature is meant to work around this issue.
Instead of clicking a “buy” button in an app and paying with your credit card, you can choose to pay with cash. Once you confirm the purchase, Google shows you a code. Take that code to the nearest participating convenience store, give them the right amount of cash, and then your purchase will be unlocked.
Currently, this feature is only live in Indonesia and Malaysia, but a wider rollout is planned. Developers will also soon be able to add this payment method to their apps.
Easier Promo Code Redemption
Developers can choose to provide promo codes for their apps. If it’s a paid app, the promo code can allow the user to get the app for free. If the app has in-app purchases or subscriptions, the promo code can provide a free item or a free subscription trial. While it’s always been possible to redeem app promo codes directly in the Play Store, to redeem a subscription trial, you previously had to download the app.
Now, though, Google Play Billing Library version 3 has added the ability to redeem in-app promotions directly from the Play Store itself; the users don’t even need to download the app they apply to.
If an app or game has a bunch of different things you can purchase in it, the developer needs some way to keep track of who purchased what. Before now, a developer would have to build a custom solution using a now-deprecated AIDL framework. With Google Play Billing Library version 3, however, there’s now native support for purchase attribution, allowing developers to easily keep track of what’s being bought.
Library Version Requirements
If you’re reading this article, you probably know about Google Play’s minimum SDK version requirements for publishing on the store. Currently, apps have to target at least API 28 (Android Pie) to be published on Google Play, and this requirement increases each year.
There’s now a similar requirement for developers implementing the Google Play Billing Library. To publish an app using this library on the Play Store, it needs to be using a relatively recent version. Right now, all versions of the Play Billing Library are allowed, but starting August 2, 2021, all newly published apps will have to use at least version 3. Existing apps will have until November 1, 2021, before they have to upgrade.
Since using the newer versions of the Play Billing Library is now a requirement, Google has published a migration guide to help developers get up-to-date. This guide shows how to implement the newest version of the library, and what developers need to change to use it.
And that’s it for now about the new Google Play Billing Library. If you implement in-app-purchases and your app is on the Google Play Store, you should probably consider updating your billing library implementation if you haven’t already.
Mandatory Android App Bundles for Newly Published Apps in 2021
Section by Mishaal Rahman
At Google I/O 2018, Google introduced an alternative app distribution format called the Android App Bundle with the file extension .aab. The goal of the Android App Bundle is to reduce the file size of the final Android Application Package (.apk) delivered to the user, reducing the installation size and download time for users. The .aab file contains APK files for the base application and all supported architectures (ARM, ARM64, and x86), languages, and layout variants. This format requires giving a copy of your app’s signing key to Google so the Google Play Developer Console can generate a bundle with signed versions of each APK in the bundle; the correct APK for a particular device’s architecture, language, and layout are delivered via Google Play Dynamic Delivery.
Developers can deploy Android App Bundles in Android Studio, Unity, or Flutter, and although large app bundles with installed APK sizes of up to 500MB are supported, OBB files are not supported. As an alternative, Google recently extended Android App Bundles with the introduction of Play Asset Delivery for game developers to dynamically deliver large game assets. With all of these improvements as a backdrop, Google now plans to make Android App Bundles a requirement for newly published applications on the Google Play Store.
In the “What’s new in Google Play” video published last week on the Android Developers YouTube channel (via AndroidPolice), Googler Milena Nikolic announced that app bundle support will be required for new apps on Google Play. No specific date was given for this new requirement, though we know it will happen sometime in 2021.
Most developers and end-users won’t notice any changes brought about by this new requirement, but that doesn’t mean that nobody will notice. Developers will have to give a copy of their signing key to Google for them to sign applications, which some developers may have qualms with. The further proliferation of AABs will make redistribution on different platforms more difficult, reducing downloads and thus potential ad revenue. (For developers, they can use Google’s open-source bundletool to build their own AABs, extract them, and then upload them to other platforms.) AABs are also harder for users to manually sideload as they aren’t natively supported by Android’s package installer and must be unpacked.
We will hopefully learn more about this new requirement as we approach 2021.
Want more posts like this delivered to your inbox? Enter your email to be subscribed to our newsletter.