The Google Play Developer Console has undergone some pretty major changes over the years, including a complete overhaul 2 years ago.
While the improvements continue to make for a more powerful and usable
tool, some developers still find areas where it could be better.
Google's engineers don't have time to build everything for everybody,
but a new version of the Google Play Developer API makes it possible to
build quite a few things for yourself. The new API allows developers to
programmatically upload apks and modify almost every detail about your
store listings.
The new web API allows developers to build scripts or applications to
automate deployment and update product listings quickly and without
directly working with the Developer Console. Most of the new
functionality is bundled into the Publishing API, a transaction-based
system for managing Play Store listings and apks. It exposes the ability
to change just about every field, image, and apk based on language.
Further, apks and expansion files can be uploaded to select tracks (i.e.
alpha, beta, production, rollout). It's even possible to make
modifications to testing groups as needed. It's also possible to change
pricing for in-app products, but it is done outside of the transactional
model.
The Publishing API will probably become a staple in the distribution systems of larger publishers. Companies will be able to build custom software to enforce their own policies and limit the changes employees can make based on their roles. For example, a marketing manager might be limited to modifying descriptions and featured images, but cannot affect pricing, screenshots, or apk updates. This will also allow publishers to rapidly launch promotions and major updates across several countries and different apps instantly.
Version 1.1 of the API was dedicated to accessing the status of an individual in-app purchase or subscription, and cancelling subscriptions. These functions were available so external servers could fulfill in-app transactions (e.g. giving a paid item to a customer after their purchase is complete) and occasionally for customer service. While the original versions of these methods should remain functional for a long time, new names have been given to these methods, which should probably be used in all future development.
Google hasn't made an announcement regarding these changes (a
brief note in the developer console mentions it, thanks Matthieu
Harlé), but its cached pages show that the documentation was updated
sometime after July 4th.
If you're interested in automating some of your Play Store
distribution, or even building an app or web service for other
developers to use, check out the developer docs for more details.
The Publishing API will probably become a staple in the distribution systems of larger publishers. Companies will be able to build custom software to enforce their own policies and limit the changes employees can make based on their roles. For example, a marketing manager might be limited to modifying descriptions and featured images, but cannot affect pricing, screenshots, or apk updates. This will also allow publishers to rapidly launch promotions and major updates across several countries and different apps instantly.
Version 1.1 of the API was dedicated to accessing the status of an individual in-app purchase or subscription, and cancelling subscriptions. These functions were available so external servers could fulfill in-app transactions (e.g. giving a paid item to a customer after their purchase is complete) and occasionally for customer service. While the original versions of these methods should remain functional for a long time, new names have been given to these methods, which should probably be used in all future development.
No comments:
Post a Comment