By Andrew Ahn, Product Manager, Google Play App Safety
At Google Play, we want to foster an ecosystem of safe, engaging, useful, and entertaining apps used and loved by billions of Android users worldwide. That’s why we regularly update and revise our Google Play Developer Policies and Developer Distribution Agreement, detailing the boundaries of app content and functionalities allowed on the platform, as well as providing latest guidance on how developers can promote and monetize apps.
In recent efforts in analyzing apps for policy compliance on Google Play we identified some common mistakes and violations that developers make, and we’re sharing these with the developer community with tips and guides on how to avoid them, mitigating the risks of apps and developer accounts being suspended for violating our policies.
One of the most common mistakes we see are apps that have buttons and menus that link out to the Play Store -- either to apps by the same developer, or other apps that may be affiliated with the developer, but not being clear that these are ads or promotional links. Without this clarity, apps may get enforced for having deceptive / disguised ads. One of the ways to avoid such mistakes is by explicitly calling these out by labeling the buttons and links as ‘More Apps’, ‘More Games’, ‘Explore’, ‘Check out our other apps’, etc.
Example of app content that link out to app listing on Play
Another mistake we frequently observe is where developers ‘stuff’ keywords in the app description in hope for better discoverability and ranking against certain keywords and phrases. Text blocks or lists that contain repetitive or unrelated keywords or references violate our Store Listing and Promotion policy. Writing a clear app description intended and optimized for user’s readability and understanding is one of the best ways to avoid this violation.
Watch this video to learn how to avoid spammy store listings and efforts to artificially boost app visibility.
There are apps that have been published by the developers a long time ago, and are no longer being maintained. Abandoned and unmaintained apps often create user experience issues -- broken app functionality, for example. Not only are such apps at risk of getting a low star rating and negative user reviews, they will also be flagged as violating the minimum functionality policy. To mitigate the negative impact to the developer reputation and app enforcement, consider unpublishing such apps from the Play Store. Note the updated unpublish action won’t affect existing users who already installed the app, and developers can always choose to re-publish them after addressing the broken experiences.
Example of an abandoned app that provides a broken app experience
Take the ‘Minimum and Broken Functionality Spam’ course on Play Academy
Lastly, we observe a large volume of app submissions that are just webviews of existing websites. Most of these apps are submitted with a primary purpose of driving traffic rather than providing engaging app experiences to Android users. Such apps are considered webview spam, and are removed from Play. Instead, consider thinking through what users can do or do better with the app than in a web experience and implement relevant features and functionalities that enrich the user experience.
Example of a webview without any app functionality
Take the ‘Webview Spam’ course on Play Academy
While the above are one of the most frequent mistakes, make sure to stay up to date with the latest policies by visiting the Play Developer Policy Center. Check out Google Play Academy’s Policy training, including our new Spam courses, and watch our Play PolicyBytes videos to learn more about recent policy updates.
Posted by Eric Bahna, Product Manager
In August, we announced plans to expand Android Auto’s app ecosystem to enable new navigation, parking, and electric vehicle charging apps. We’ve been hard at work collaborating with our early access partners to test and refine the Android for Cars App Library. Today, we’re releasing the library into an open beta, for any developer to use. This means you’ll now be able to design, develop, and test your navigation, parking or charging app on Android Auto. We’re looking forward to enabling Google Play Store publishing for your beta apps in the coming months.
Three of our early access partners: ChargePoint, SpotHero, and Sygic
The design phase is the time to familiarize yourself with our design guidelines and app quality guidelines. Driver safety is core to our mission and we want to help you optimize your app for the car.
When it comes time to build your app, our new library will hopefully make development easy. Get started with the developer guide and please give us feedback via our public issue tracker.
In the testing phase, see your app come alive on the Desktop Head Unit (DHU), our emulator that lets you simulate a car infotainment display. The DHU now supports multiple screen sizes, displaying information in the instrument cluster, and simulating vehicles with touchpad input.
The DHU simulating an instrument cluster, a widescreen head unit, and a touchpad
You can get started with the Android for Cars App Library here. We’re excited to see what you build next!
Steve Suppe, Product Manager, Google Play
Publishing your app or game is one of the most important moments in your app’s lifecycle. You want everything to go smoothly, from making sure the production release is stable, to getting test releases out quickly, to getting your marketing message just right.
That’s why visibility is key. Knowing when your app is in review, when it’s been approved, and when it can go live on Google Play helps you set your own schedule.
Now, with two new features in the new Google Play Console, you can do just that. The Publishing overview page helps you better understand your publishing process and Managed publishing gives you better control of when your app updates go live on Google Play. When the new Play Console rolls out to everyone starting November 2, these features will be the recommended way to control your release timing, so let’s take a closer look.
The new Publishing overview page displays all your recent changes to your releases, store listings, and more, including those that are currently being reviewed or processed by Google Play. For those of you with larger teams, this means you can now coordinate all your changes in one place and publish everything at the same time.
Unlike the developer activity log, the Publishing overview only shows changes that will be visible on Google Play, or what you’ve told us about how we should consider and review your app.
The “Changes in review” section lets you quickly see changes that have not been published yet.
These changes are organized by the type of change or release track so it’s easy to understand at a glance.
Many of you may be familiar with Timed publishing in the old Play Console. In the new Play Console, we’ve replaced Timed publishing with Managed publishing, to give you a clearer and more predictable publishing experience.
When you enable Managed publishing, approved changes will only go live when you decide instead of automatically after review and processing. This allows you to submit changes long before your intended release date, giving yourself time to review or make changes without sacrificing control over your publishing date.
See which changes have been reviewed and approved
When Managed publishing is on, the Publishing overview page contains two sections: one that shows which changes have been approved and are ready to publish, and another that shows changes that are still in review.
We’ve also made some improvements that many of you have been asking for:
See if Managed publishing is turned in the left-hand navigation menu
Soon, you’ll be able to see the Managed publishing icon in the left-hand nav next to Publishing overview. This way, you can tell Managed publishing is on from anywhere in the Play Console.
To learn more about publishing with the new Play Console, including scenarios when these features would be most useful, check out this course from Play Academy. And if you haven’t already, update to the new Play Console at play.google.com/console and give Managed publishing a try.
How useful did you find this blog post?
★ ★ ★ ★ ★
Posted by Scott Swarthout, Product Manager
Today, we’re excited to release the stable version of Android Studio 4.1, with a set of features addressing common editing, debugging, and optimization use cases. A major theme for this release was helping you be more productive while using Android Jetpack libraries, Android’s suite of libraries to help developers follow best practices and write code faster. Based on your feedback we made a number of improvements to the code editing experience with IDE integrations for popular Android libraries.
Some highlights of Android Studio 4.1 include a new Database Inspector for querying your app’s database, support for navigating projects that use Dagger or Hilt for dependency injection, and better support for on-device machine learning with support for TensorFlow Lite models in Android projects. We’ve also made updates to Apply Changes to make deployment faster. Based on your feedback, we’ve made several changes to help game developers with a new native memory profiler and standalone profiling tools.
Product quality continues to be a major focus for the team, and we’ve been hard at work tracking down bugs and performance issues. We’ve heard from many developers that they liked the focus on better performance and reliability, so we’re happy to report that during this release cycle we’ve fixed 2,370 bugs and closed 275 public issues. We stay committed to maintaining high quality since we know that is key to your developer productivity.
Thank you to those who gave your early feedback in preview releases. Your feedback helped us iterate and improve features in Android Studio 4.1. If you are ready for the next stable release, and want to use a new set of productivity features, Android Studio 4.1 is ready to download for you to get started.
Below is a full list of new features in Android Studio 4.1, organized by key developer flows.
Android Studio templates in the create New Project dialog now use Material Design Components (MDC) and conform to updated guidance for themes and styles by default. These changes will make it easier to use recommended material styling patterns and support modern UI features like dark themes.
Material Design Components updates in Project Templates
Updates include:
com.google.android.material:material
Theme.MaterialComponents.*
colors.xml
purple_500
colorPrimary
themes.xml
styles.xml
Theme.<ApplicationName>
DayNight
?attr/colorPrimary
We wanted to make it easier to inspect, query, and modify your app's databases using the new Database Inspector. To get started, deploy your app to a device running API level 26 or higher and select View > Tool Windows > Database Inspector from the menu bar. Whether your app uses the Jetpack Room library or the Android platform version of SQLite directly, you can now easily inspect databases and tables in your running app or run custom queries.
Because Android Studio maintains a live connection while you’re inspecting your app, you can also modify values using the Database Inspector and see those changes in your running app. If you use the Room persistence library, Android Studio also places run buttons next to each query in the code editor to help you quickly run queries you define in your @Query annotations. Learn more
Inspect, query, and modify your app’s databases with the Database Inspector
You can now run the Android Emulator directly in Android Studio. Use this feature to conserve screen real estate, to navigate quickly between the emulator and the editor window using hotkeys, and to organize your IDE and emulator workflow in a single application window. You can manage snapshots and common emulator actions like rotating and taking screenshots from within Studio, but access to the full set of options still requires running the stable emulator. You can opt-in to use this feature by going to File → Settings → Tools → Emulator → Launch in Tool Window.
Run the Android Emulator inside of Android Studio
Dagger is a popular library for dependency injection on Android. Android Studio makes it easier to navigate between your Dagger-related code by providing new gutter actions and extending support in the Find Usages window. For example, clicking on the gutter action next to a method that consumes a given type navigates you to the provider of that type. Conversely, clicking on the gutter action navigates you to where a type is used as a dependency. Android Studio also supports navigation actions for dependencies defined with the Jetpack Hilt library. Learn more.
Navigate between Dagger-related code with gutter actions
Android developers are using machine learning to create innovative and helpful experiences. TensorFlow Lite is a popular library for writing mobile machine learning models, and we wanted to make it easier to import these models into Android apps. Similar to view binding, Android Studio generates easy-to-use classes so you can run your model with less code and better type safety. The current implementation of ML Model Binding supports image classification and style transfer models, provided they are enhanced with metadata.
To see the details for an imported model and get instructions on how to use it in your app, double-click the .tflite model file in your project to open the model viewer page. Learn more.
.tflite
View TensorFlow Lite model metadata in Android Studio 4.1
Android Studio
In addition to recently adding 5G cellular testing support, we’ve added support for foldables in the Android emulator. With Android emulator 30.0.26 and above, you can configure foldable devices with a variety of fold designs and configurations. When a foldable device is configured, the emulator will publish hinge angle sensor updates and posture changes, so you can test how your app responds to these form factors. See the Developing for Android 11 with the Android Emulator blogpost to read more.
Faster builds help developers make changes to their app more easily and quickly. To help you be more productive as you iterate on your app, we've made multiple enhancements to Apply Changes for devices running Android 11 or higher.
We've invested heavily in optimizing your iteration speed by developing a method to deploy and persist changes on a device without installing the application. After an initial deploy, subsequent deploys to Android 11 devices using either Apply Code Changes or Apply Changes and Restart Activity are now significantly faster. We’ve also added support for additional code changes in Apply Changes. Now if you add a method, you can deploy those changes to a running app by clicking either Apply Code Changes or Apply Changes and Restart Activity.
Android Gradle Plugin 4.0 added the ability to import Prefab packages in AAR dependencies. We wanted to extend the capability of this feature to support sharing native libraries as well. AGP version 4.1 enables exporting libraries from your external native build in an AAR for an Android Library project. To export your native libraries, add the following to the android block of your library project's build.gradle file:
build.gradle
buildFeatures { prefabPublishing true } prefab { mylibrary { headers "src/main/cpp/mylibrary/include" } myotherlibrary { headers "src/main/cpp/myotherlibrary/include" } }
When a crash or ANR occurs in native code, the system produces a stack trace, which is a snapshot of the sequence of nested functions called in your program up to the moment it crashed. These snapshots can help you to identify and fix any problems in the source, but they must first be symbolicated to translate the machine addresses back into human-readable function names.
If your app or game is developed using native code, like C++, you can now upload debug symbols files to the Play Console for each version of your app. The Play Console uses these debug symbols files to symbolicate your app's stack traces, making it easier to analyze crashes and ANRs. To include debug symbols in your app bundle, add the following line to your project’s build.gradle file:
android.buildTypes.release.ndk.debugSymbolLevel = 'SYMBOL_TABLE'
In Android Studio 4.1 we’ve overhauled System Trace, an optimization tool that gives you a real-time look at how your app is using system resources. We made it easier to select a trace with box selection mode, added a new analysis tab, and added more frame rendering data to help you investigate rendering issues in your app’s UI. Learn more.
Box selection: In the Threads section, you can now drag your mouse to perform a box selection of a rectangular area, which you can zoom into by clicking the Zoom to Selection button on the top right (or use the M keyboard shortcut). When you drag and drop similar threads next to each other, you can select across multiple threads to inspect all of them at once.
Use box selection to more easily select traces.
Summary tab: The new Summary tab in the Analysis panel displays:
View aggregated statistics in the Summary tab
Display data: In the Display section, new timelines for SurfaceFlinger and VSYNC help you investigate rendering issues in your app's UI.
It's now possible to access the Android Studio Profilers in a separate window from the primary Android Studio window. This is useful when optimizing Android games built with other tools like Unity or Visual Studio.
To run the standalone profilers, do the following:
Windows/Linux: <studio-installation-folder>\bin
<studio-installation-folder>\bin
macOS: <studio-installation-folder>/Contents/bin
<studio-installation-folder>/Contents/bin
profiler.exe
profiler.sh
The standalone profiler will allow you to connect to the Android emulator or any connected devices.
Optimize your app with the Standalone Android Studio Profilers
Tracking native memory usage is important for game developers and other developers using C++ to understand how to optimize their app’s memory consumption. The Android Studio Memory Profiler now includes a Native Memory Profiler for apps deployed to physical devices running Android 10 or later. The Native Memory Profiler tracks allocations/deallocations of objects in native code for a specific time period and provides information about total allocations and remaining system heap size.
To initiate a recording, click Record native allocations at the top of the Memory Profiler window:
View native memory allocations with the Native Memory Profiler
To recap, Android Studio 4.1 includes these new enhancements & features:
Design
Develop
Build & Test
Optimize
These materials are not sponsored by or affiliated with Unity Technologies or its affiliates. “Unity” is a trademark or registered trademark of Unity Technologies or its affiliates in the U.S. and elsewhere.
Posted by Kylie McRoberts, Program Manager and Alec Guertin, Security Engineer
Google’s Android Security & Privacy team has launched the Android Partner Vulnerability Initiative (APVI) to manage security issues specific to Android OEMs. The APVI is designed to drive remediation and provide transparency to users about issues we have discovered at Google that affect device models shipped by Android partners.
Android incorporates industry-leading security features and every day we work with developers and device implementers to keep the Android platform and ecosystem safe. As part of that effort, we have a range of existing programs to enable security researchers to report security issues they have found. For example, you can report vulnerabilities in Android code via the Android Security Rewards Program (ASR), and vulnerabilities in popular third-party Android apps through the Google Play Security Rewards Program. Google releases ASR reports in Android Open Source Project (AOSP) based code through the Android Security Bulletins (ASB). These reports are issues that could impact all Android based devices. All Android partners must adopt ASB changes in order to declare the current month’s Android security patch level (SPL). But until recently, we didn’t have a clear way to process Google-discovered security issues outside of AOSP code that are unique to a much smaller set of specific Android OEMs. The APVI aims to close this gap, adding another layer of security for this targeted set of Android OEMs.
The APVI covers Google-discovered issues that could potentially affect the security posture of an Android device or its user and is aligned to ISO/IEC 29147:2018 Information technology -- Security techniques -- Vulnerability disclosure recommendations. The initiative covers a wide range of issues impacting device code that is not serviced or maintained by Google (these are handled by the Android Security Bulletins).
The APVI has already processed a number of security issues, improving user protection against permissions bypasses, execution of code in the kernel, credential leaks and generation of unencrypted backups. Below are a few examples of what we’ve found, the impact and OEM remediation efforts.
In some versions of a third-party pre-installed over-the-air (OTA) update solution, a custom system service in the Android framework exposed privileged APIs directly to the OTA app. The service ran as the system user and did not require any permissions to access, instead checking for knowledge of a hardcoded password. The operations available varied across versions, but always allowed access to sensitive APIs, such as silently installing/uninstalling APKs, enabling/disabling apps and granting app permissions. This service appeared in the code base for many device builds across many OEMs, however it wasn’t always registered or exposed to apps. We’ve worked with impacted OEMs to make them aware of this security issue and provided guidance on how to remove or disable the affected code.
A popular web browser pre-installed on many devices included a built-in password manager for sites visited by the user. The interface for this feature was exposed to WebView through JavaScript loaded in the context of each web page. A malicious site could have accessed the full contents of the user’s credential store. The credentials are encrypted at rest, but used a weak algorithm (DES) and a known, hardcoded key. This issue was reported to the developer and updates for the app were issued to users.
The checkUidPermission method in the PackageManagerService class was modified in the framework code for some devices to allow special permissions access to some apps. In one version, the method granted apps with the shared user ID com.google.uid.shared any permission they requested and apps signed with the same key as the com.google.android.gsf package any permission in their manifest. Another version of the modification allowed apps matching a list of package names and signatures to pass runtime permission checks even if the permission was not in their manifest. These issues have been fixed by the OEMs.
checkUidPermission
PackageManagerService
com.google.uid.shared
com.google.android.gsf
Keep an eye out at https://bugs.chromium.org/p/apvi/ for future disclosures of Google-discovered security issues under this program, or find more information there on issues that have already been disclosed.
Acknowledgements: Scott Roberts, Shailesh Saini and Łukasz Siewierski, Android Security and Privacy Team
Posted by Sameer Samat, Vice President, Product Management
Developers are our partners and by pairing their creativity and innovation with our platforms and tools, together we create delightful experiences for billions of people around the world. Listening carefully to their feedback is an important part of how we continue to make Android better with each release and improve how mobile app stores work. In an April 2019 blog post we shared some updates we made to Android APIs and Play Policies based on developer feedback. And today, we wanted to share some additional insights we’ve gained from developer feedback and how we’re taking that input to improve Google Play and Android. Some of the key themes we’ve heard include:
We’d like to share our perspective on each of these points.
We believe that developers should have a choice in how they distribute their apps and that stores should compete for the consumer’s and the developer’s business. Choice has always been a core tenet of Android, and it’s why consumers have always had control over which apps they use, be it their keyboard, messaging app, phone dialer, or app store.
Android has always allowed people to get apps from multiple app stores. In fact, most Android devices ship with at least two app stores preinstalled, and consumers are able to install additional app stores. Each store is able to decide its own business model and consumer features. This openness means that even if a developer and Google do not agree on business terms the developer can still distribute on the Android platform. This is why Fortnite, for example, is available directly from Epic's store or from other app stores including Samsung's Galaxy App store.
That said, some developers have given us feedback on how we can make the user experience for installing another app store on their device even better. In response to that feedback, we will be making changes in Android 12 (next year’s Android release) to make it even easier for people to use other app stores on their devices while being careful not to compromise the safety measures Android has in place. We are designing all this now and look forward to sharing more in the future!
As we mentioned, each Android app store is able to decide its own business model and consumer features. For Google Play, users expect a safe, secure and seamless experience, and developers come to Play for powerful tools and services that help them build and grow their businesses. Our developer policies are designed to help us deliver on these expectations and Google Play's billing system is a cornerstone of our ongoing commitment. Consumers get the benefit of a trusted system that allows them to safely, securely, and seamlessly buy from developers worldwide. Google protects consumers’ payment info with multiple layers of security, using one of the world’s most advanced security infrastructures. For developers, Google Play’s billing system provides an easy way for billions of Android users to transact with them using their local, preferred method of payment.
We’ve always required developers who distribute their apps on Play to use Google Play’s billing system if they offer in-app purchases of digital goods, and pay a service fee from a percentage of the purchase. To be clear, this policy is only applicable to less than 3% of developers with apps on Google Play. We only collect a service fee if the developer charges users to download their app or they sell in-app digital items, and we think that is fair. Not only does this approach allow us to continuously reinvest in the platform, this business model aligns our success directly with the success of developers.
But we have heard feedback that our policy language could be more clear regarding which types of transactions require the use of Google Play’s billing system, and that the current language was causing confusion. We want to be sure our policies are clear and up to date so they can be applied consistently and fairly to all developers, and so we have clarified the language in our Payments Policy to be more explicit that all developers selling digital goods in their apps are required to use Google Play’s billing system.
Again, this isn’t new. This has always been the intention of this long standing policy and this clarification will not affect the vast majority of developers with apps on Google Play. Less than 3% of developers with apps on Play sold digital goods over the last 12 months, and of this 3%, the vast majority (nearly 97%) already use Google Play's billing. But for those who already have an app on Google Play that requires technical work to integrate our billing system, we do not want to unduly disrupt their roadmaps and are giving a year (until September 30, 2021) to complete any needed updates. And of course we will require Google’s apps that do not already use Google Play’s billing system to make the necessary updates as well.
Our policies apply equally to all apps distributed on Google Play, including Google’s own apps. We use the same standards to decide which apps to promote on Google Play, whether they're third-party apps or our own apps. In fact, we regularly promote apps by Google’s competitors in our Editors Choice picks when they provide a great user experience. Similarly, our algorithms rank third-party apps and games using the same criteria as for ranking Google's own apps.
Developers have told us it is very important to be able to speak directly with their customers without significant restrictions. As app developers ourselves, we agree wholeheartedly and our policies have always allowed this.
That said, developers have asked whether they can communicate with their customers directly about pricing, offers, and alternative ways to pay beyond their app via email or other channels. To clarify, Google Play does not have any limitations here on this kind of communication outside of a developer’s app. For example, they might have an offering on another Android app store or through their website at a lower cost than on Google Play.
We understand the importance of maintaining the customer relationship. As such, we have also always allowed developers to issue refunds to their customers and provide other customer support directly.
Developers are coming up with cool things all the time. Using their feedback, we are always trying to adjust our approach to ensure that we continue to help enable new forms of innovation. For example, recent innovations in game streaming have generated new game experiences that are available on Google Play, including Microsoft’s recent launch of Xbox cloud gaming in the Xbox Game Pass Android app.
We really appreciate all the feedback we have received from our developer community and believe the Android ecosystem has never been a more exciting place to be.
It is exciting to see developers such as Duolingo, Truecaller, Hyperconnect, Any.do, and Viber be so successful and grow their business on Android and reach a diverse audience. These kinds of services delight consumers and we are thrilled to have built a platform that can support them.
We’ve also published some additional frequently asked developer questions here.
Posted by Mrinalini Loew, Group Product Manager
We are committed to providing powerful tools and services to help developers build and grow their businesses while ensuring a safe, secure and seamless experience for users. Today we are addressing some of the most common themes we hear in feedback from developers. Below are a few frequently asked developer questions that we thought would also be helpful to address.
A: Yes, you can distribute your app however you like! As an open ecosystem, most Android devices come preinstalled with more than one store - and users can install others. Android provides developers the freedom and flexibility to distribute apps through other Android app stores, directly via websites, or device preloads, all without using Google Play’s billing system.
A: All apps distributed on Google Play that are offering in-app purchases of digital goods need to use Google Play’s billing system. Our payments policy has always required this. Less than 3% of developers with apps on Play sold digital goods over the last 12 months, and of this 3%, the vast majority (nearly 97%) already use Google Play's billing. For those few developers that need to update their apps, they will have until September 30, 2021 to make those changes. New apps submitted after January 20, 2021 will need to be in compliance.
A: We recognize that the global pandemic has resulted in many businesses having to navigate the challenges of moving their physical business to digital and engaging customers in a new way, for example, moving in-person experiences and classes online. For the next 12 months, these businesses will not need to comply with our payments policy, and we will continue to reassess the situation over the next year. For developers undergoing these changes, we're eager to hear from you and work with you to help you reach new users and grow your online businesses, while enabling a consistent and safe user experience online.
A: Yes. Google Play’s developer policies - including the requirement that apps use Google Play’s billing system for in-app purchases of digital goods - apply to all apps on Play, including Google’s own apps.
A: Yes. Outside of your app you are free to communicate with them about alternative purchase options. You can use email marketing and other channels outside of the app to provide subscription offers and even special pricing.
A: Of course. We're an app developer too, and we know how important it is not to restrict your ability to communicate with your users. You can email them or otherwise communicate outside of the app information about your offerings, even if they are different on Google Play than in other places.
A: Yes. It is your service and business, it is up to you. We do not require parity across platforms. You can create different versions of your app to support different platforms, features and pricing models.
A: Yes. Google Play allows any app to be consumption-only, even if it is part of a paid service. For example, a user could login when the app opens and the user could access content paid for somewhere else.
A: No. Business or consumer apps, and verticals like music or email are all treated the same on Google Play.
A: Yes. We understand the importance of maintaining the relationship with your customers. You can continue to issue refunds to your customers and other customer support directly.
A: Yes. Cloud game streaming apps that comply with Play’s policies from any developer are welcome on Google Play.
For more examples and best practices for in-app purchases, visit this Play Academy course and watch this video.
Platform
Android Studio
Google Play
Jetpack
Kotlin
Docs
News
