Aktualizacja wpisu w Google Play za pomocą Google Play Developer API
edits.insert), zmieniasz w niej tekst wpisu i obrazy (edits.listings.update, edits.images.upload), a następnie wywołujesz edits.commit, aby zwalidować i opublikować zmiany — albo edits.abandon, aby je odrzucić. Nic nie trafia na żywo przed commitem. Uwierzytelnianie odbywa się kontem serwisowym Google Cloud, a krok, na którym potyka się prawie każdy: konto serwisowe trzeba zaprosić w Play Console, nie wystarczy nadać mu rolę w Google Cloud IAM.Google Play Developer API (jego oficjalna nazwa to Android Publisher API) pozwala zmieniać wpis w sklepie — tytuł, opisy, zrzuty ekranu, grafikę promującą — bez otwierania Play Console. To dokładnie to, czego potrzebujesz, jeśli wysyłasz zlokalizowane teksty z CMS-a, synchronizujesz zrzuty ekranu z pipeline'u budowania albo aktualizujesz dziesiątki wersji językowych naraz. Poniżej znajdziesz kompletny przepływ, jak zrobić to poprawnie — łącznie z fragmentami, które dokumentacja referencyjna skrzętnie ukrywa.
Edycja to transakcja, nie zestaw zapisów na żywo
Model myślowy, który oszczędzi Ci najwięcej nerwów: nigdy nie edytujesz bezpośrednio wpisu na żywo. Otwierasz edycję, czyli prywatną roboczą kopię aktualnego opublikowanego stanu aplikacji — kopiowane są wpisy, obrazy, ścieżki, wszystko. Wszystkie zmiany wprowadzasz na tej kopii. Następnie zatwierdzasz całość naraz albo ją porzucasz i nic się nie wydarzyło.
Google formułuje to wprost: "Zmiany wprowadzone w ramach edycji nie są aktywne, dopóki edycja nie zostanie zatwierdzona". Przy commicie, jeśli nie ma błędów walidacji, wszystkie zmiany w edycji trafiają na żywo razem, zastępując dotychczasowy stan. Jeśli walidacja się nie powiedzie, API zwraca błąd, a wpis na żywo pozostaje nietknięty. Cały cykl życia to dokładnie cztery kroki:
edits.insert— tworzy edycję, zwracaeditId.- modyfikacja —
edits.listings.updatedla tekstu w danym języku,edits.images.upload/deletealldla zrzutów ekranu i grafik. edits.commit— waliduje wszystko, a następnie publikuje całość atomowo.edits.abandon— odrzuca wersję roboczą, wpis na żywo pozostaje bez zmian.
Jedno twarde ograniczenie, o którym warto pamiętać przy projektowaniu: dane konto może mieć otwartą tylko jedną edycję naraz, a jeśli ktokolwiek zatwierdzi edycję albo zmieni aplikację w interfejsie Play Console, każda inna otwarta edycja tej aplikacji zostaje unieważniona. Traktuj edycję jako coś krótkotrwałego — otwórz ją, zapisz zmiany, zatwierdź. Nie trzymaj jej otwartej godzinami, podczas gdy ktoś klika po konsoli.
Uwierzytelnianie: konto serwisowe plus zaproszenie, o którym wszyscy zapominają
Do zautomatyzowanego aktualizatora potrzebujesz konta serwisowego, a nie OAuth użytkownika. W grę wchodzą dwa systemy i są one naprawdę odrębne:
- Google Cloud. Utwórz konto serwisowe, włącz Google Play Android Developer API w projekcie i pobierz klucz JSON. Jedyny potrzebny zakres to
https://www.googleapis.com/auth/androidpublisher. - Play Console. Przejdź do Użytkownicy i uprawnienia, kliknij Zaproś nowych użytkowników, wklej adres e-mail konta serwisowego (adres
...@...iam.gserviceaccount.com) i nadaj mu dostęp do aplikacji. Dopiero wtedy ten klucz może dotknąć Twojego wpisu.
Jeszcze jeden warunek wstępny: aplikacja musi już istnieć i mieć co najmniej jedno wydanie (co najmniej jeden plik APK/AAB przesłany przez konsolę). Nie da się uruchomić zupełnie nowej aplikacji wyłącznie przez API.
Cztery wywołania jako REST
Aktualizacja tekstu wpisu
edits.listings.update to PUT — pełne zastąpienie wpisu dla danego języka. To, co wyślesz, staje się wpisem; pola, których nie podasz, są czyszczone, a nie zachowywane. Więc jeśli chcesz zmienić tylko krótki opis, nadal musisz wysłać razem z nim tytuł i pełny opis, inaczej je wykasujesz. Gdy naprawdę potrzebujesz częściowej zmiany, istnieje osobne edits.listings.patch, które scala wyłącznie podane pola. Dla większości pipeline'ów pełny PUT jest czystszym rozwiązaniem — i tak renderujesz kompletny wpis ze swojego źródła prawdy, więc zastąpienie go w całości jest dokładnie tym, co potrzebne.
Trzy pola tekstowe i ich limity: title do 30 znaków, shortDescription do 80, fullDescription do 4000. Jeden zasób wpisu na język, identyfikowany tagiem języka BCP-47 w adresie URL (en-US, de-DE, ja-JP itd.). Aby zaktualizować dziesięć języków, wykonujesz dziesięć wywołań listings.update w tej samej edycji — a jeden commit publikuje je wszystkie razem.
Przesyłanie zrzutów ekranu i grafiki promującej
Obrazy są przypisywane do konkretnego języka i typu obrazu. Typ obrazu to wyliczenie, a każde miejsce na zasób we wpisie odpowiada jednej z tych wartości:
phoneScreenshots,sevenInchScreenshots,tenInchScreenshots— zestawy zrzutów ekranu dla telefonu i tabletów.tvScreenshots,wearScreenshots— Android TV i Wear OS.featureGraphic— baner 1024×500 wyświetlany na górze wpisu.icon,tvBanner— ikona aplikacji i baner telewizyjny.
edits.images.upload dodaje do edycji jeden obraz danego języka i typu. Nie ma wywołania "ustaw całą tablicę naraz", więc niezawodnym wzorcem przy wymianie zrzutów ekranu jest najpierw edits.images.deleteall dla danego języka i typu obrazu, a następnie przesłanie nowego zestawu w kolejności, w jakiej mają być pokazane. edits.images.list odczytuje, co aktualnie znajduje się w edycji, a edits.images.delete usuwa pojedynczy obraz po id, gdy potrzebna jest chirurgiczna zmiana. Wszystko to pozostaje w obrębie edycji, dopóki nie zatwierdzisz.
Zatwierdzanie — i co naprawdę oznacza "na żywo"
Kilka rzeczy wartych precyzyjnego wyjaśnienia, bo zaskakują ludzi:
- Nowa wersja aplikacji nie jest potrzebna. Zatwierdzenie edycji dotyczącej wyłącznie wpisu nie wymaga świeżego APK/AAB. Tekst i obrazy to metadane; możesz je aktualizować dowolną liczbę razy w ramach istniejącego wydania. (Aplikacja musi mieć jedynie to jedno wcześniejsze wydanie.)
- Commit najpierw waliduje, potem publikuje. Jeśli zrzut ekranu ma złe wymiary albo pole jest za długie, commit kończy się niepowodzeniem, a wpis na żywo w ogóle się nie zmienia — poprawiasz i zatwierdzasz ponownie.
- To nie jest natychmiastowe. Po udanym zatwierdzeniu zmiany mogą pojawić się nawet po kilku godzinach, tak samo jak edycje wprowadzone ręcznie w Play Console. Nie traktuj kodu 200 przy commicie jako "już widoczne dla użytkowników".
- Porzucenie nic nie kosztuje. Jeśli test na sucho wygląda źle,
edits.abandonodrzuca wersję roboczą bez żadnego wpływu na wpis na żywo. Przydatne do walidowania pipeline'u bez ryzyka.
Droga bez kodu: projektuj, tłumacz, publikuj
Powyższe API to właściwe narzędzie, jeśli masz czas inżynierski do wykorzystania i źródło prawdy do synchronizacji. Czego nie robi, to tworzenie zasobów. Nadal musisz zaprojektować zrzuty ekranu, napisać tytuł i oba opisy oraz przygotować to wszystko dla każdego języka — API dostarcza tylko to, co mu przekażesz.
Właśnie tym zajmuje się Mokbi. Projektujesz zrzuty ekranu w przeglądarce, tworzysz tytuł, krótki opis i pełny opis obok nich, a następnie tłumaczysz cały wpis na 50 języków za jednym razem — dzięki czemu dziesięć wywołań listings.update opisanych powyżej ma do wysłania prawdziwy, zlokalizowany tekst zamiast tekstu zastępczego.
A sama publikacja? Mokbi też to robi. Dla Google Play uruchamia dokładnie ten przepływ pod maską (edits.insert → listings.update → przesłanie obrazów → commit), więc Twój zlokalizowany wpis i zasoby trafiają na żywo bez pisania choćby linijki powyższego kodu. Dla App Store przygotowuje wersję w App Store Connect, wypełnioną i gotową do wysłania, ponieważ Apple wymaga, abyś sam nacisnął ostateczny przycisk Submit i przeszedł proces recenzji. Projektowanie zrzutów ekranu i grafiki promującej, pisanie wpisu, tłumaczenie go na 50 języków i publikowanie na żywo to jeden ciągły proces.