Posted by Oscar Rodriguez, Developer Advocate
When designing and developing an app or game, at some point you may ask yourself if you want to monetize it.
If you choose to do so by selling products via Google Play, you will most likely have a store screen that shows available items for sale, and use the Google Play Billing Library to display dialogs that allow your users to complete their purchase.
While there is a more detailed explanation in the documentation and in the Billing Library TrivialDrive samples, the general flow is as follows:
launchBillingFlow()
onPurchasesUpdated()
consumeAsync()
acknowledgePurchase()
If your app is still using the Google Play Billing AIDL API, it is also possible to perform the same task. Keep in mind that the AIDL API is now deprecated, so we strongly recommend you migrate to the Google Play Billing Library as soon as possible.
If you are using the AIDL API, the flow is very similar:
getBuyIntent()
getBuyIntentExtraParams()
startIntentSenderForResult()
Intent
onActivityResult()
getPurchases()
consumePurchase()
Nevertheless, just implementing the above mentioned flow is not enough to correctly handle all types of purchases. There are two main cases in which purchases will not be correctly handled by this flow.
The first case happens when the purchase flow is interrupted before it finishes. The app may have crashed, the user may have killed the app, or the user’s Internet connection may have been lost. In any case, it is possible for the app not to have delivered the item to the user even though Google Play has already processed the payment. In this case, the item is in limbo, because Google Play will not allow an item to be re-purchased until it is consumed, but the app or game won’t consume the item outside of the flow mentioned above.
The second case happens during alternative purchase flows, such as in-app promotions, the recently announced out-of-app subscription surfaces, promo codes for subscriptions, or other promotions in collaboration with Google. In these cases, a user gets an item directly on the Play Store app, while the target app or game may be paused, not running, or even not installed.
For these cases, the Google Play Billing Library and the Google Play Billing AIDL API offer a mechanism to detect purchases that are not acknowledged or consumed.
When using the Google Play Billing API, do the following:
onResume()
queryPurchases()
For the Google Play Billing AIDL API, do the following:
In either case, when you detect and process an unconsumed item in this manner, users will expect the app or game to communicate about it. We suggest that you display a dialog, message box, or notification that tells the user that they have successfully received their item.
Keep in mind that your app’s onResume() callback will be called when its process is started, as well as when it is brought to the foreground, regardless of which screen the app or game was in before it was paused. For example, a game with a home screen, a store screen, and a game screen might get its onResume() called from any of those screens. For an optimal user experience, we suggest you make it so your app or game handles unacknowledged or unconsumed items regardless of the screen you display when onResume() gets called. Thorough testing of this process in each screen is crucial to deliver a great user experience.
Finally, there is one more case your app must handle: when a user acquires an item from the Play Store app, and both the Play Store app and your app are visible at the same time with multi-window mode.
To support this scenario with the Google Play Billing Library, do the following:
PurchasesUpdatedListener
com.android.vending.billing.
PURCHASES_UPDATED
onPause()
Just as before, you should display a dialog, message box, or notification that tells the user that they have successfully received their item.
If you follow these steps, your app or game will be better prepared to robustly handle purchase flow interruptions and alternative purchase flows.
Posted by Sam Lin, Product Manager, Android
With Project Marble, the Android Studio team focused our efforts on making the fundamental features and flows of the Integrated Development Environment (IDE) rock-solid. Performance is an underlying tenant to delivering a high quality IDE. To this end, we are sharpening our product focus and we will only support 64-bit operating systems going forward. Using Android Studio with an 64-bit operating systems enables efficient access to memory for both the IDE and the Android Emulator, and overall leads to a better development experience. While this change will not affect most Android Studio users, this change does have an impact if you use 32-bit versions of Microsoft® Windows®. To aid in this transition for those developers using 32-bit versions of Microsoft Windows, we want to give you details on the upcoming depreciation timeline plus steps to take to be ready for this upcoming change.
To minimize the impact of this change towards exclusively supporting 64-bit operating systems, we will first deprecate the 32-bit version. During the depreciation phase, both Android Studio and the Android Emulator will continue to work but the products will not receive new feature updates. During this transition period you can still download the product from the Android Studio web site. After one year, we will officially end product support and will remove the 32-bit product version download links. Note, if you have the 32-bit version of Android Studio previously installed during this period then the product should continue to work, but we will not provide a link for you to re-download the product. The exact dates for the depreciation and end-of-support period are in the table below:
There are a few advantages to using a 64-bit version of Android Studio, which include:
To recap, before ending support for the 32-bit version of Android Studio, we want to inform you in advance, provide guidance, and allow for a one-year lead time to help you migrate to a 64-bit operating system. You can still use 32-bit versions of Android Studio, but be mindful that these version will not receive future updates. Therefore, if you want to migrate we suggest you start planning early so that you can continue to get the latest product updates and take advantage of the performance improvements of a 64-bit development environment.
Posted by Dave Burke, VP of Engineering
Last month at Google I/O we talked about what’s new for Android developers, from new features in Android Q to the latest in Kotlin and Jetpack.
With Android Q, we highlighted three themes: innovation, security and privacy, and digital wellbeing. We want to help you take advantage of the latest new technology -- 5G, foldables, edge-to-edge screens, on-device machine learning, and more -- while making sure users' security, privacy, and wellbeing are always a top priority.
We also talked about how we’re going increasingly Kotlin-first, and continuing to expand Jetpack with new libraries like CameraX, Jetpack Security and Jetpack Compose -- a modern reactive-style UI toolkit for Android that takes advantage of Kotlin. If you missed the livestream for the keynotes or tech sessions, make sure to check out the full playlist of Android and Play sessions.
Today we’re releasing Beta 4 with the final Android Q APIs and official SDK -- the time is now to get your apps ready for the final release later in the summer!
You can get Beta 4 today on Pixel devices by enrolling here. If you're already enrolled and received the Beta 3 on your Pixel device, you'll automatically get the update to Beta 4. Partners participating in the Android Q Beta program will also be updating their devices to Beta 4 over the coming weeks.
To get started with Android Q Beta, visit developer.android.com/preview.
The Beta 4 update includes the latest Android Q system images for Pixel and Android Emulator, along with the final Android Q developer APIs (API level 29), the official API 29 SDK, and updated build tools for Android Studio. Together, these give you everything you need to test your apps for compatibility with Android Q and build with Android Q features and APIs.
To get started, download the official API 29 SDK and tools into the stable release of Android Studio 3.4, or for the latest Android Q support update to Android Studio 3.5 Beta. Then follow these instructions to configure your environment, and see the release notes for known issues.
With the developer APIs finalized and release candidate builds coming soon, it’s critical for all Android developers to test their current apps for compatibility with Android Q. We recommend getting started as soon as possible.
Just install your current app from Google Play onto an Android Q Beta device or emulator, then test. As you work through the flows, your app should run and look great and handle all of the Android Q behavior changes properly. Watch for impacts from privacy changes, gestural navigation, changes to dynamic linker paths for Bionic libraries, and others.
Make sure that you test with the Android Q privacy features, such as the new location permissions, restrictions on background activity starts, changes to data and identifiers, and other key privacy features. See the privacy checklist to get started, and review the behavior changes doc for more areas to test.
You can use the updated Android Emulator to test your apps for compatibility.
If you plan to update your platform targeting to API 29, also make sure to test with scoped storage, location permission for wireless scans, and permission for fullscreen intents. You can read about other changes that could affect apps here.
It's also important to test for uses of restricted non-SDK interfaces and move to public SDK or NDK equivalents instead. Watch for logcat warnings that highlight these accesses and use the StrictMode method detectNonSdkApiUsage() to catch them programmatically.
Last, make sure to fully test the libraries and SDKs in your app to make sure they work as expected on Android Q and follow best practices for privacy, performance, UX, data handling, and permissions. If you find an issue, try updating to the latest version of the SDK, or reach out to the SDK developer for help. You can also report SDK compatibility issues here.
When you’ve finished your testing and made any updates, we recommend publishing your compatible app right away. This lets Android Beta users test the app now, and helps you deliver a smooth transition to users as they update to Android Q.
We realize that supporting these changes is an investment for you too, and we're working to minimize the impact on your apps and be responsive to your input as we move toward the final release in the coming months.
When you're ready, dive into Android Q and learn about the new features and APIs that you can use in your apps. Android Q features can help you engage users, give them more control and security, and even improve your app's performance.
Android Q provides system-suggested replies and actions in notifications.
For example, you can deliver seamless, edge-to-edge experiences on today’s innovative devices by optimizing for foldables and supporting gestural navigation in your app. To engage more users, try supporting Dark Theme, suggested replies and actions in notifications, sharing shortcuts, and settings panels.
Gestural navigation lets you offer an edge-to-edge experience in your apps.
If your app manages IoT devices over Wi-Fi, try the new network connection APIs for functions like configuring, downloading, or printing. If your app manages Wi-Fi internet connections, try the network suggestion APIs as an easier way to surface preferred Wi-Fi networks, without needing to request location permission.
If you use the camera, learn about dynamic depth format. For media, you can use AV1 for video streaming and HDR10+ for high dynamic range video. For speech and music streaming, you can use Opus encoding, and for musicians, a native MIDI API is available.
Dynamic Depth lets you offer specialized blurs and bokeh options in your app.
To support captioning or gameplay recording, enable audio playback capture -- it’s a great way to reach more users and get your app noticed. If your app uses power intensively, try using the new thermal API to optimize app performance based on device temperature.
BiometricPrompt is now the preferred way to support fingerprint auth on modern devices, so all developers using fingerprint or other biometric auth should move to using this API as soon as possible. To make the transition easy, use the backwards-compatible BiometricPrompt API that we’re providing in the AndroidX library. Android Q supports both standard and passive (no confirmation, for face and other passive modes) auth flows.
These are just a few of the many new features and APIs in Android Q -- to see them all, visit the Android Q Beta site for developers.
Today with Android Q Beta 4 we’re also opening up publishing on Google Play to apps that are compiled against, or optionally targeting, API 29. This means you can now push your updates to users now through Google Play to test your app’s compatibility, including on devices running Android Q Beta 4.
It’s easy! Just enroll any supported Pixel device here to get the update over-the-air. If you're already enrolled, you'll receive the update soon and no action is needed on your part. Downloadable system images are also available here. Partners that are participating in the Android Q Beta program will be updating their devices over the coming weeks. See android.com/beta for details.
For even broader testing on supported devices, you can also get Android GSI images, and if you don’t have a device you can test on the Android Emulator.
As always, your input is critical, so please continue to let us know what you think. You can use our hotlists for filing platform issues (including privacy and behavior changes), app compatibility issues, and third-party SDK issues. You've shared great feedback with us so far and we're working to integrate as much of it as possible in the next Beta release.
We're looking forward to seeing your apps on Android Q!
Posted by Vineet Tanwar, Business Development Manager, Google Play
In April we opened applications for the 2019 class of Indie Games Accelerator, a program to help top mobile game startups from emerging markets achieve their full potential on Google Play. We’re truly awed by the response we have received with over 1,700 applications from developers across 37 countries*. We continue to be impressed by the innovation and creativity of game developers everywhere.
Now, it's time to introduce you to the developers selected for the class of 2019. Here they are:
Congratulations to the selected participants and we look forward to meeting you in Singapore!
Find out more about the program or express your interest in joining the next class of the Indie Games Accelerator.
* The competition is open to developers from the following countries: Bangladesh, Brunei, Cambodia, India, Indonesia, Laos, Malaysia, Myanmar, Nepal, Pakistan, Philippines, Singapore, Sri Lanka, Thailand, Vietnam, Egypt, Jordan, Kenya, Lebanon, Nigeria, South Africa, Tunisia, Turkey, Argentina, Bolivia, Brazil, Chile, Colombia, Costa Rica, Ecuador, Guatemala, Mexico, Panama, Paraguay, Peru, Uruguay and Venezuela
How useful did you find this blog post?
★ ★ ★ ★ ★
Posted by Kosuke Suzuki, Product Manager, Google Play
Every month, more than 2 billion users from over 190 countries visit the Google Play Store to browse and discover new apps and games. As part of making Google Play a great discovery experience, we continue to increase our focus on quality. Over the coming weeks, we’ll be updating our featuring and ranking logic to further prioritize high quality apps and games with strong technical performance and engaging content.
If you’re looking for ways to improve your app quality, below are three key areas to focus on. Along with these suggestions, we've highlighted several tools available in the Google Play Console to help you better understand user behavior, monitor technical performance, and deliver the best in-app experience for users. Remember, app quality will impact where and how prominently you're eligible to surface in the store, so always look to create the most compelling and delightful experience possible.
Have you thought about your UI and if your app has intuitive navigation, controls, and menu access? Do you have a good first-time-user experience, overall polished design, and enough content to keep users engaged for the long term?
Quality guidelines: meet user expectations and maximize your exposure opportunities by testing against the quality guidelines for different platforms.
Testing tracks: release early versions of your app to gather early user feedback and make improvements before full release.
Engaging content: build loyalty and sustainable app engagement by satisfying your users needs
Ad placement: for apps with ads integrated, ensure a good user experience by choosing the right ad format and placement throughout your app.
Have you considered whether your app has good overall technical performance, and if it is power-thrifty, responsive, efficient, and well-behaved? 42% of users who leave a 1-star review mention stability or bugs.
Android vitals: review the Android vitals dashboard to see how your app is performing on core vitals metrics including crash rate, ANR rate, excessive wakeups, and stuck partial wake locks in the background. Look at developer selected peer benchmarks to see how you measure up to others in your category. Exhibiting bad behavior in Android vitals will negatively affect the user experience in your app and could limit your exposure opportunities on Google Play.
Pre-launch reports: identify where your app has problems to ensure you’re presenting the highest possible quality to users upon launch. The pre-launch reports use automated tests on real devices that can identify layout issues, provide crash diagnostics, locate security vulnerabilities, and more.
Last but not least, a quality app also means having an effective and accurate listing page. Does your store listing page make a great first impression? Does it clearly and accurately communicate the value and intended use cases of your app?
Best practices: use strong creative assets, including your app title, icon, screenshots and video, along with a clear and informative app description, that provide an accurate representation of your app. To improve discovery opportunities, we suggest all pages have a video (set to public or unlisted and non-monetized) to inform users about your app, and for game developers to provide three or more 16:9 aspect ratio screenshots.
New icon specification: create a more polished experience on the store by updating your icon before June 24th.
Ratings and reviews: monitor your user ratings and reviews and respond to negative reviews where possible. When receiving a reply from developers, users increase their rating by +0.7 stars on average. Paying attention to ratings and reviews will be increasingly important as we rollout the new rating score in August 2019. This will place more weight on your most recent ratings in the Google Play Store.
Store listing experiments: A/B test different versions of your listing page amongst actual Google Play users. Make sure to test each component independently and run tests for at least a week in order to gather significant results.
Custom store listings: tailor your marketing messages to specific user groups based on their country, install state or even pre-registration. This is a great way to highlight key features and updates best suited for existing or lapsed users.
Localization: take advantage of Google Play’s worldwide reach to identify key markets, translate your app store listing, and even run store listing experiments to optimize for each country.
Get the most out of the Google Play Console and learn about improving app quality on the Academy for App Success, a free e-learning resource.
Posted by Doug Stevenson, Developer Advocate
Later this year, the Google Play services and Firebase SDKs will migrate from the Android Support libraries to androidx-packaged library artifacts. We are targeting this change for June/July of 2019. This will not only make our SDKs better, but make it easier for you to use the latest Jetpack features in your app.
androidx-packaged
If your app depends on any com.google.android.gms or com.google.firebase libraries, you should prepare for this migration. To quickly test your build with androidx-packaged library artifacts, add the following two lines to your gradle.properties file:
com.google.android.gms
com.google.firebase
androidx
gradle.properties
android.useAndroidX=true android.enableJetifier=true
If your build still works, then you're done! You will be ready to use the new Google Play services and Firebase SDKs when they arrive. If you experience any new build issues or want more information on this migration, visit the official Jetpack migration guide. We will communicate when the androidx migration is complete in the near future, stay tuned!
