
Portuguese: 
Olá!
Sou Neto Marin, mediador da equipe
de relacionamento com desenvolvedores.
Trabalho no Brasil
com parceiros da América Latina.
Mas não se preocupem.
Não vou falar de samba nem de futebol.
Mas sim sobre a Play Billing Library.
Quando vocês decidem
vender algo no app de vocês,
temos algumas etapas a cumprir.
Atualmente, há várias formas
de vender coisas
para nossos usuários diretamente
no smartphone ou no Google Assistente.
Não é a melhor coisa dizer,
por exemplo, faturamento em apps.
Por isso temos o
Google Play Faturamento.
Estou aqui para falar mais
sobre a Play Billing Library 2.0.
Essa é uma nova versão
da Play Billing Library
que estamos desenvolvendo
desde o ano passado.
A ideia aqui é dar a vocês
uma dica de como migrar de
qualquer coisa que vocês

Spanish: 
Hola.
Soy Neto Marin.
Soy asesor de desarrolladores en el equipo
de relaciones con desarrolladores.
Trabajo en Brasil
con socios de Latinoamérica.
Pero no voy a hablar de zamba
ni de fútbol,
sino de la Biblioteca
de Facturación Google Play.
Decidir vender algún producto en una app
implica dar grandes pasos.
Hoy en día, hay muchas maneras
de vender productos
desde el teléfono
o mediante el Asistente de Google.
Ya no es preciso decir, por ejemplo,
facturación integrada.
Por eso,
la llamamos Facturación Google Play.
Y ahora estoy aquí para hablar más
sobre la Biblioteca
de Facturación Google Play 2.0,
la versión nueva de nuestra
Biblioteca de Facturación Google Play
que continuamos optimizando
desde el año pasado.
Y la idea es que esto
debería darles un indicio
de cómo migrar desde lo que sea que usen

Korean: 
네토 마린: 안녕하세요
저는 네토 마린입니다
저는 개발자 관계팀에 속한 
개발자 애드버킷입니다
저는 브라질 출신이고
라틴 아메리카의 파트너들과 일하고 있습니다
하지만 축구 이야기는 하지 않겠습니다
오늘 주제는 Play 결제 라이브러리입니다
여러분의 앱에서 무엇인가를
판매할 것을 결정할 때
거쳐야 할 몇 가지
중요한 단계가 있습니다
요즘은 스마트폰이나
Google 어시스턴트를 통해 사용자에게
상품을 판매할 수 있는 다양한 방법이
있습니다
인앱 결제와 같은 말은 더 이상
정확하지 않게 된 것이죠
그래서 Google Play 결제라는
이름을 붙이게 되었고요
오늘 저는 Play 결제 라이브러리
2.0에 대해 좀 더 말씀드리고자 합니다
Google Play 결제 라이브러리의
새 버전으로
저희가 작년부터 계속
발전시켜 온 것입니다
그리고 오늘 발표를 통해
현재 사용 중인 시스템에서
Play 결제 라이브러리 2.0으로

English: 
NETO MARIN: Hello.
I'm Neto Marin.
I'm a developer advocate on
the developer relations team.
I'm based in Brazil.
I work with partners
in Latin America.
But OK, I won't talk about
someone neither soccer, OK.
It's about Play Billing Library.
So we have some big steps
when you are deciding
to sell something in your app.
And nowadays, we have
many ways to sell stuff
for our users right on the
phone or through the Google
Assistant.
It's not accurate to say
anymore, like, e-net building.
So this is why we call
the Google Play Billing.
And now I'm here to talk more
about the Play Billing Library
2.0.
This was a new version of
our Play Billing Library
that we keep evolving
since the last year.
And the idea here
should give you
a hint about how to
migrate from whatever

Indonesian: 
NETO MARIN: Halo.
Saya Neto Marin.
Saya adalah Advokat Developer di 
tim hubungan developer.
Saya ditempatkan di Brasil.
Saya bekerja dengan partner
di Amerika Latin.
Baiklah, saya tidak akan membicarakan 
seseorang atau sepak bola.
Topik pembicaraannya adalah
Library Layanan Penagihan Play.
Jadi kami memiliki langkah besar
saat anda memutuskan
untuk menjual sesuatu di
aplikasi anda.
Dan sekarang, kita memiliki 
banyak cara untuk menjual barang
bagi pengguna langsung 
melalui ponsel atau Asisten Google.
Istilah seperti bangunan e-net
sudah tidak lagi akurat.
Sehingga kami menyebutnya
Layanan Penagihan Google Play.
Dan sekarang saya akan 
membicarakan lebih lanjut tentang
Library Layanan Penagihan Play 2.0.
Ini adalah versi baru
Library Layanan Penagihan Play
yang selalu kami kembangkan
dalam satu tahun terakhir.
Dan inti pembicaraan ini
akan memberi Anda
petunjuk tentang cara
bermigrasi dari apa pun

Japanese: 
こんにちは
Neto Marinです
デベロッパーリレーションチームの
デベロッパー アドボケイトをしています
拠点はブラジルで
ラテンアメリカのパートナーと
仕事をしています
さて 今日はサンバやサッカーの話ではなく
プレイ課金ライブラリについてのお話です
アプリで何かを売る方法は
大きく進歩しています
最近は 何か売ろうと思ったら
電話やGoogle Assistantなど
色々な方法があります
e-net課金というと正確ではないので
Google Play課金と呼んでいます
今日は プレイ課金ライブラリ2.0のことを
お話しします
これは 昨年から開発している
プレイ課金ライブラリの
新しいバージョンです
ここのアイデアを見てもらえば
今使っているものから
プレイ課金ライブラリ2.0に移ってもらう

Chinese: 
大家好
我是Neto Marin
来自开发者关系团队的开发技术推广工程师
我在巴西工作
经常与拉丁美洲的合作伙伴协作
不过，今天我要聊的不是桑巴舞，也不是足球
我要谈谈Play结算库
当您决定在应用中出售商品时
需要执行一些重要的步骤
如今，我们有很多途径向用户出售商品
无论是使用手机
还是Google助理
如今再说电子网络结算已经不准确了
因此我们使用了名称Google Play结算
接下来我要详细讲讲
Play结算库2.0
这是我们新版本的Play结算库
从去年开始我们就在持续开发
这里要讲的内容应该可以启发大家
从现在使用的工具

Indonesian: 
yang sedang Anda gunakan
ke Library Layanan Penagihan Play 2.0.
Karena sekarang,
ini adalah yang lebih baik--
dan sebentar lagi akan menjadi
satu-satunya cara-- menggunakan
Layanan Penagihan Play
di aplikasi Android Anda.
Dan saya akan menjelaskan
sedikit alasan kami menerapkan perubahan
ini pada Library Layanan Penagihan Play
2.0, oke?
Jadi Library Penagihan memudahkan cara
menjual produk,
cara menggunakan produk
di dalam aplikasi Anda.
Tetapi ada satu waktu saat
pengalaman tersebut tidak terlalu baik.
Tetapi sekarang jadi
sangat mudah, dan juga sangat
penting untuk 
fitur selanjutnya
yang akan kami umumkan 
dalam Lab Layanan Penagihan Play
untuk ekosistem Penagihan.
Sehingga penggunaan Library Layanan
Penagihan Play
2.0 akan bersifat wajib.
Tetapi ada satu waktu saat
saya mengatakan--
siapa di sini 
yang mengingat antarmuka AIDL
untuk Layanan Penagihan Play?
Ada yang ingat?

Chinese: 
迁移至Play结算库2.0
因为Play结算更好用
并且它很快就会成为Android应用
唯一的结算方式
接下来我解释一下
为什么我们要强制大家改用
Play结算库2.0
使用结算库可以轻松地在应用内
销售和消耗商品
不过，它的使用体验曾经一度不是很好
现在已经大大改善
更重要的是，我们即将
为结算生态系统中的Play结算库
发布下一个新功能
使用Play结算库2.0
将成为强制性要求
说到之前
有谁记得Play结算服务的AIDL接口吗？
有人记得吗？

English: 
you're using to start using
the Play Pilling Library 2.0.
Because now it's the better--
and soon will be the only
way-- to use Play Billing
at your Android app.
And I'm going
explain a little bit
why we are enforcing this change
to the Play Billing Library
2.0, OK?
So the Billing Library makes
easy how to sell products,
how to consume products
within your app.
But there was a time that the
experience was not so great.
So today it's very
easy, and also it's
very important for
the next feature
that we are announcing
for the Play Billing
Lab for the Billing ecosystem.
So the usage of the
Play Billing Library
2.0 going to be mandatory.
But there was a time
when I say that the--
who here remembers the AIDL
interface for Play Billing?
Someone remembers?

Portuguese: 
estejam usando para a
Play Billing Library 2.0.
Hoje ela é a melhor
e logo será a única maneira de usar
o Play Faturamento em apps Android.
Vou explicar por que estamos fazendo
essa mudança na Play Billing Library 2.0.
A Play Billing Library facilita a venda
e o consumo de produtos no app.
Houve um tempo em que
essa experiência não era tão boa.
Hoje, está bastante fácil,
e é muito importante para o recurso
que anunciaremos para a Billing Library,
para o ecossistema de faturamento.
Então, o uso
da Billing Library 2.0 será obrigatório.
Mas os tempos eram outros.
Quem aqui se lembra
da interface AIDL do Play Faturamento?
Alguém se lembra?

Korean: 
전환하는 방법에 대해 
알아보실 수 있습니다
여러분의 Android 앱에서
Play 결제를 사용할 수 있는
더 나은 방법이자 머지않아
유일한 방법이
될 것이기 때문입니다
또한 우리가 이렇게
Play 결제 라이브러리 2.0으로의 변화를
도모하는 이유에 대해 약간의 설명을
해 드리고자 합니다
결제 라이브러리는 여러분의
앱 내에서 제품을 손쉽게 판매하고
손쉽게 소비할 수 있게 해 줍니다
한때는 사용 경험이
그다지 좋지 못한 때가 있었습니다
하지만 지금은 사용이 매우 쉽고
또한 다음 세대를 위해서도
결제 생태계를 위한
Play 결제 실험실을 발표하는 것이
매우 중요합니다
따라서 Play 결제 라이브러리
2.0을 사용하는 것은
필수적인 일이 될 것입니다
하지만 한때는...
여기 계신 분 중에
Play 결제에 쓰이던 AIDL 인터페이스를
기억하시는 분이 계신가요?

Spanish: 
a la Biblioteca
de Facturación Google Play 2.0.
Porque ahora es la mejor.
Y pronto será la única manera de usar
la Facturación Google Play
en apps para Android.
También voy a explicar
por qué implementamos este cambio
en la Biblioteca
de Facturación Google Play 2.0, ¿sí?
La Biblioteca de Facturación
Google Play
facilita la manera de vender productos
y la forma de consumirlos en una app.
Antes, la experiencia no era tan genial.
Pero hoy es sumamente fácil
y también muy importante
para la próxima función que anunciaremos
para el Lab de Facturación Google Play
en el ecosistema de facturación.
Por tanto, usar la Biblioteca
de Facturación Google Play 2.0
va a ser obligatorio.
Pero, como dije, hubo una época en la que…
¿Quién recuerda la interfaz del AIDL
para la Facturación Google Play?
¿Alguien la acuerda?

Japanese: 
きっかけになるかもしれません
どんどんよくなっていますし
すぐにAndroidアプリでプレイ課金を使う
唯一の方法になると思います
なぜプレイ課金ライブラリ2.0に
変更を加えているのか
今から説明しようと思います
いいですね？
課金ライブラリは アプリから
物を売ったり
物を買ったりするのを
簡単にできるようにしてくれます
これまで エクスペリエンスが
あまりよくありませんでしたが
今では すごく使いやすくなり
さらに 私達が発表する
プレイ課金ライブラリの新機能は
課金エコシステムにとって
非常に重要なものです
プレイ課金ライブラリ2.0の使用は
必須になるでしょう
とは言っても
少し前にプレイ課金用にAIDLインターフェースが
あったのを憶えている方は
いらっしゃるでしょうか？
誰かいますか？

Korean: 
사용하기 좋은가요?
아니죠
자, AIDL을 잘 모르는 분을
위해 말씀드리자면
AIDL은 안드로이드 인터페이스 
정의 언어를 말하는데
여러분의 서비스가 여기에 있고
여러분의 앱은
서비스에 연결되어 
거기에서 모든 접속과 통신이
이루어지도록 해야 합니다
하지만 이는 별로 좋은 방식은 아니죠
예를 들어, 이러한 방식은
복잡한 경우가 있습니다
연결이 끊어지기도 하고
유지 관리하기가 어렵습니다
그래서 생각해 낸 것이
Play 결제 라이브러리입니다
Google에서 Play
결제 라이브러리를 출시한 이래로
20억 달러 이상의 구매가 
Google Play 결제 라이브러리를 사용하는 앱에서
발생했습니다
따라서 이미 거래의 상당수가 
이 라이브러리를 통해서
발생하고 있는 것입니다
Blinkist의 말을 인용하겠습니다
"Google Play 결제 라이브러리 2.0은
사용하기가 매우 쉽고
너무나 많은 일들을 해 주어서 지금
우리가 해야 할 일들이 별로 없다"
여기에 핵심적인 생각이 담겨 있습니다
우리가 어디에서 
클라이언트 라이브러리를 작성할 수 있을까요?

Spanish: 
Era fácil usarla, ¿no?
Para nada.
El AIDL, para quienes
no están familiarizados,
es el Lenguaje de definición
de la interfaz de Android
donde tienen un servicio.
Así su app se conecta al servicio
y se establecen
todas las conexiones y comunicaciones.
Pero no es la mejor manera.
A veces, por ejemplo, es complicado.
Se pierde la conexión.
Y es difícil mantenerla.
Y entonces surgió
la Biblioteca de Facturación Google Play.
Por ejemplo, las apps que la usan
han recaudado más de 2,000 millones
de dólares desde que la lanzamos.
Así que muchas de las transacciones
ya pasan por esa biblioteca.
Veamos esta cita de Blinkist:
"Usar la Biblioteca de Facturación
Google Play 2.0 es mucho más fácil.
Hace tantas tareas por nosotros
que no tenemos que preocuparnos".
Y esa es la idea principal.
¿Dónde podemos escribir
una biblioteca cliente?

Japanese: 
使いやすかったですか？
良く知らない人のためにご説明しますと
AIDLというのは
Androidのインターフェイス定義言語
のようなもので
サービスがあって
アプリはそのサービスに
接続する必要があり
その接続や
通信を全部やります
これはあまりいい方法ではありません
例えば 複雑になってしまうことがあります
接続が失われます
接続を維持するのは困難です
そこでプレイ課金ライブラリが開発されました
たとえば 課金ライブラリの開始以来
これを使ったアプリから
20億ドル以上の
購入がありました
すでに 多くの売買が
このライブラリを使って
行われています
例えば
Blinkistからの引用ですが
「Google Play課金ライブラリ2.0は
ずっと使いやすく
色々なことをやってくれるので
手間がはぶけます」
中心となる考え方は
クライアントライブラリを
どこに書くか？ということです

Chinese: 
用起来还可以，是吧？
不记得
好吧，如果您不熟悉AIDL也无妨
它就像Android接口定义语言
可以提供某种服务
应用必须连接至该服务
才能建立所有连接和通信
但这种方法并不太好
比如说，有时比较复杂
您会失去连接
而且维护难度较大
于是我们推出了Play结算库
自从我们推出Play结算库以来
超过20亿美元的购买额
来自使用该库的应用
许多交易现在已经
通过这个结算库进行
例如，Blinkist这样评价
“使用Google Play结算库2.0
要轻松很多
很多事情它都可以代劳，我们无需亲力亲为”
这就是关键所在
我们为什么要编写客户端库？

Portuguese: 
Era bom de usar, né?
Não.
Então, AIDL, para quem não sabe,
é a Linguagem de definição
de interface do Android,
em que você tem um serviço,
depois seu app precisa
se conectar ao serviço e fazer
as conexões e comunicações.
Não é uma boa abordagem.
Pode ser complicado.
Você perde a conexão,
e é difícil mantê-la.
Depois, viemos com a Play Billing Library.
E já foram mais de 
US$ 2 bilhões em compras
desde que a Billing Library foi lançada.
Muitas transações já estão
passando por essa biblioteca.
Por exemplo, de acordo com
uma citação do Blinkist,
"Usar a Billing Library 2.0
é muito mais fácil.
Ela faz muitas coisas para nós agora."
Essa é a ideia principal.
Criar uma biblioteca de cliente.

English: 
It's good, right, to use?
Nah.
So, well, this AIDL, for
those who are not familiar,
it's like the Android
Interface Definition Language
where you have a service,
then your app has
to connect to the service
and make all the connections
and communications of that.
But that's not a great way.
It's-- for example, it's
sometimes complicated.
You lose connection.
And it's hard to maintain.
And then we come up with
the Play Billing Library.
For example, from the apps
using Google Play Billing
Library over to Billing and
Purchase since we launched
the Play Billing Library.
So many of the
transactions are already
going through this library.
So for example, this one
quote from Blinkist--
"Using Google Play
Billing Library 2.0
is just so much easier.
It does so many things for us
that we don't have to do now."
And this is the main idea.
Where can we write
a client library?

Indonesian: 
Itu bagus, kan, untuk digunakan?
Tidak.
Jadi, AIDL ini, bagi 
yang tidak familier dengannya,
adalah Android
Interface Definition Language
di mana Anda memiliki layanan,
lalu aplikasi Anda
harus terhubung ke layanan dan 
membuat semua koneksi
dan komunikasi.
Tetapi itu bukanlah cara yang bagus.
Itu--misalnya, itu terkadang
sedikit rumit.
Anda kehilangan koneksi.
Dan sulit untuk mempertahankannya.
Lalu kami membuat Library
Layanan Penagihan Play.
Misalnya, dari aplikasi yang
menggunakan Library Layanan
Penagihan Play 
sampai Penagihan dan Pembelian
sejak kami meluncurkan 
Library Layanan Penagihan Play.
Banyak sekali 
transaksi telah melewati library ini.
Misalnya, satu kutipan ini
dari Blinkist--
"Layanan Penagihan
Google Play 2.0
sangat mudah untuk digunakan.
Layanan ini melakukan banyak hal sehingga
kita tidak perlu melakukannya lagi".
Dan ini adalah intinya.
Di mana kita bisa menulis
library klien?

Indonesian: 
Ini seharusnya 
mendukung developer
dan pengalaman developer.
Dan Anda tidak perlu 
menulis sekumpulan kode,
sekumpulan tugas sendirian.
Sehingga kami bisa diandalkan,
karena kami dibayar untuk itu.
Jadi kami dapat membantu Anda 
mendapatkan pengalaman yang baik.
Jadi ini tidaklah terlalu elok,
seperti yang anda lihat dari reaksi
saat saya bertanya tentang
AIDL.
Reaksinya seperti, oh, sial.
Oke, ya.
Maaf.
Tetapi itulah mengapa kami membuat
Library Layanan Penagihan
Google Play, bukan?
Misalnya, AIDL 
mengharuskan Anda
untuk menyalin sekumpulan kode 
ke project Anda.
Dan setiap kali, 
untuk setiap project,
Anda terkadang harus menyalin file
yang sama berkali-kali, bukan?
Lalu menambahkan fitur baru
akan sedikit sulit,
karena kita perlu berkomunikasi.
Kita perlu menemukan 
cara agar developer tahu
bahwa kita sedang membuat fitur baru.
Dan ini bersifat tidak rawan error,
karena misalnya,
jika kita mengubah parameter, jika
kita menambahkan kolom baru di paket,
itu dapat menyebabkan 
banyak aplikasi error.

Chinese: 
为了支持开发者，改善开发者体验
这样您就不需要自己写一堆代码
一堆任务
大家支付了费用，就可以依赖我们的服务
我们可以帮您获得良好的体验
以前体验不是很好，我刚才问到AIDL时
大家的反应说明了这一点
大家都觉得有些差劲
好吧，是的
抱歉
不过，正因为如此
我们构建了Google Play结算库
过去，AIDL要求您
复制一堆代码到项目中
每个项目都要复制
有时需要多次复制相同的文件
并且添加新功能也不容易
因为需要通信
我们需要找到一种方法
让开发者知道我们正在开发新功能
还要不易出错
因为如果我们改一个参数
在数据包中新增一个字段
就会使很多应用崩溃

Korean: 
그것은 개발자와 개발자 환경을
지원하는 것이어야 합니다
여러분이 많은 양의 코드를 
작성하거나 많은 작업을 혼자 감당할
필요가 없게 말이죠
우리 자신을 의지할 수 있게 말이죠
우리는 그에 대한 대가를 받으니까요
따라서 Google에서는 여러분이 
좋은 환경을 갖도록 도울 수 있습니다
그래서 제가 AIDL에 대해
물었을 때 반응이 별로
좋지 않았던 것입니다
반응이 영 시큰둥했습니다
좋습니다
죄송합니다
하지만 그래서 저희가
Google Play 결제 라이브러리를
구축한 것입니다
예를 들어 AIDL은 여러분이
많은 양의 코드를 프로젝트에
복사해 넣을 것을 요구합니다
그리고 항상
모든 프로젝트에 대해
같은 파일을
여러 번 복사해야 할 때가 있죠
또한 새로운 기능을
추가하기가 어려웠습니다
통신을 해야 하기 때문이죠
저희는 저희가 새로운 기능을
만들고 있다는 것을 개발자가 알 수 있는
방법을 찾아야 했습니다
그리고 AIDL은 오류 발생의
가능성이 있는데, 가령
매개변수를 변경할 때 
새로운 필드를 번들로 추가하면
많은 앱과 충돌을 일으킬 수 있습니다

Japanese: 
デベロッパーとデベロッパーのエクスペリエンス
をサポートしなければなりません
自分でたくさんコードやタスクを
書く必要はありません
これでお金をもらっている私達に
任せればよいのです
私達が皆さんのお手伝いをします
AIDLについて質問したとき
みなさんの反応はあまり
よくはありませんでしたね
反応は 何か
〇ソ みたいな
あの
すいません
ですが そのせいで
グーグル プレイ課金ライブラリを
作ることになったのです
たとえば AIDLでは
コードをたくさん
プロジェクトにコピーする必要が
ありました
どのプロジェクトでも 常に
ときには同じファイルを何回も
コピーする必要がありましたね？
新しい機能の追加は困難でした
なぜなら
コミニュケーションが必要だったからです
私達が新しい機能を作成中であることを
デベロッパーに知らせる方法を
見つける必要がありました
エラーを起こしやすいものであってはなりません
なぜなら 例えば
パラメーターを変更したり 
バンドルに新しいフィールドを追加したりすると
アプリをクラッシュさせる可能性が
あるからです

Spanish: 
Debería ayudar a los desarrolladores
y su experiencia.
Y así no tienen que escribir un montón
de código o tareas ustedes mismos.
Pueden confiar en nosotros
porque para eso nos pagan.
Para que podamos ayudarlos a tener
una buena experiencia.
No era muy agradable,
como pueden ver por la reacción,
cuando pregunté acerca del AIDL.
La reacción fue: "qué porquería".
Lo siento.
Pero por eso desarrollamos la Biblioteca
de Facturación Google Play, ¿cierto?
Entonces, por ejemplo, AIDL requería
que copiaran un montón de código
en el proyecto.
Y, todo el tiempo, para cada proyecto,
debían copiar los mismos archivos
muchas veces, ¿no?
Agregar funciones nuevas era difícil,
porque necesitamos que haya comunicación.
Debemos encontrar una forma
de que los desarrolladores
sepan que creamos una función nueva.
Y que no sea susceptible a errores
porque, por ejemplo,
si cambiamos un parámetro,
si agregamos un campo nuevo en un paquete,
pueden dejar de funcionar muchas apps.

English: 
It should support developers
and the developer experience.
And so you don't need to write a
bunch of code, a bunch of tasks
by yourself.
So we can rely on us,
because we are paid for that.
So we can help you
have a good experience.
So it wasn't so pretty, as
you can see by the reaction
when I asked about the AIDL.
The reaction was
kind of, oh, shit.
OK, yeah.
Sorry.
But that's why we built
the Google Play Billing
Library, right?
So for example,
the AIDL required
you to copy a bunch of
cold to your project.
And all the time,
for every project,
you have to copy sometimes the
same files many times, right?
And then adding new features
was kind of difficult,
because we need to communicate.
We need to find a way that
developers know that we
are creating a new feature.
And it's not error prone,
because then for example,
if we change a parameter, if
we add a new field in a bundle,
it can crash many apps.

Portuguese: 
Ela deve apoiar
as experiências dos desenvolvedores.
Assim, vocês não têm que criar
códigos e tarefas sozinhos.
Vocês podem contar conosco,
porque somos pagos para isso.
Podemos ajudar vocês
a ter uma excelente experiência.
Como vocês puderam notar,
a resposta não foi muito boa
quando perguntei sobre a AIDL.
A reação foi péssima.
Desculpe.
Foi por isso que criamos a
Google Play Billing Library.
Por exemplo, a AIDL exigia
vários códigos no projeto.
E, para cada projeto, era preciso
copiar os mesmos arquivos várias vezes.
E adicionar novos recursos
era um tanto difícil,
porque precisamos nos comunicar.
Precisamos informar os desenvolvedores
que estamos criando um novo recurso.
Isso não é à prova de erros porque,
se mudarmos um parâmetro ou
adicionarmos um novo campo a um pacote,
ele poderá travar muitos apps.

Spanish: 
Así que siempre era complicado
cuando había que actualizar algo
o tener en cuenta una función nueva.
Y, nuevamente,
muchísimo código aglutinante.
Por lo que hay
que pegar el mismo código una y otra vez.
Y, a veces, con solo cambiar un parámetro
de In a Subs, por ejemplo,
se puede romper esa parte del código.
Y no era muy fácil
ver por qué se rompía el código,
ya que era solo código aglutinante
que se podía evitar.
Y, por ejemplo, algunas funciones nuevas,
como las compras en cualquier lugar…
No sé si estaban aquí en la otra sesión
de Facturación Play que dio Oscar
sobre el seguimiento de Play Store, ¿bien?
Entonces, este tipo de función
solo se puede hacer con una versión nueva,
una refactorización de nuestros servicios
de Facturación Google Play.
Por eso es que surgió
la Biblioteca de Facturación Google Play.
Y, como dije, en la…
Cuando usan AIDL,
dado que es una interfaz del servicio,

Portuguese: 
É sempre complicado quando você
tem que atualizar algo ou
considerar um novo recurso.
Novamente,
um monte de códigos para colar.
Você tem que colar
o mesmo código várias vezes.
Às vezes, se você simplesmente
muda um parâmetro
para assinaturas, por exemplo,
simplesmente quebra o código.
E nem sempre era fácil ver isso
porque era um código inevitável.
E em alguns recursos novos,
como o de compra em qualquer lugar...
Não sei se vocês estavam na sessão
do Oscar sobre o Play Faturamento,
sobre compras fora da Play Store.
Esse tipo de novo recurso
só é possível com uma nova versão,
uma refatoração
dos serviços do Play Faturamento.
Foi por isso que apresentamos
a Play Billing Library.
Quando você usa a AIDL,
como ela é uma interface de serviço,

Indonesian: 
Sehingga ini selalu menjadi
hal yang sulit saat Anda
harus mengupdate sesuatu atau
mempertimbangkan fitur baru.
Dan lagi, kode perekat yang banyak.
Sehingga Anda harus menempelkan
kode yang sama lagi dan lagi.
Dan terkadang, jika Anda 
mengubah parameter
dari in ke subs, misalnya, itu dapat
merusak bagian kode
yang sedang Anda gunakan.
Dan tidaklah mudah 
untuk mengetahui
alasan Anda merusak kode tersebut 
karena hanya kode perekat
yang dapat Anda hindari.
Misalnya, beberapa fitur baru
seperti pembelian di mana saja--
Saya tidak tahu apakah Anda di sini 
saat sesi lain
tentang Layanan Penagihan Play 
dijelaskan oleh Oscar, misalnya, mengejar
Play Store, bukan?
Jadi sejenis fitur baru ini
hanya dapat digunakan dengan versi baru, 
pemfaktoran ulang
Layanan Penagihan Play kami.
Inilah mengapa kami membuat
Library Layanan Penagihan Play,
bukan?
Dan seperti yang telah saya katakan,
pada--
saat Anda menggunakan AIDL, 
karena ini adalah layanan antarmuka,

Korean: 
그래서 여러분이
무언가를 업데이트하거나
새로운 기능을 고려하는 것은
항상 어려운 일이었습니다
또한 글루 코드의 양이 너무 많습니다
그래서 같은 코드를 
반복해서 붙여넣여야 합니다
가령 매개변수를 
in에서 subs로 변경하는 경우
사용 중인 코드의 일부에
문제가 발생할 수 있습니다
그리고 왜 문제가 발생하는지
알기가 쉽지 않습니다
왜냐하면 이것은 여러분이 피해야 하는
글루 코드이기 때문입니다
그리고 예를 들어
'어디에서나 구매'와 같은
새로운 기능의 경우...
여기 계신 분 중에 오스카가 진행한
Play 결제 관련 세션, 예를 들어
Play Store에서 Play 결제를
개선하는 것에 관한 세션에 참여하신
분이 계신지 모르지만
이러한 새로운 기능은 Google의 
Play 결제 서비스를 리팩토링한
새로운 버전에서만
실행 가능합니다
이것이 Google에서 
Play 결제 라이브러리를
생각해 낸 이유입니다
그리고 제가 말씀드린 것처럼
AIDL을 사용 중이신 경우
AIDL은 서비스 인터페이스이기 때문에

Chinese: 
因此要进行更新
或考虑新功能时，总是令人头疼
同样，也涉及大量粘合代码
需要一次又一次地粘贴相同的代码
有时，只要更改一个参数
例如从in改成subs
就会破坏正在使用中的代码
对应的部分
而且您还不太容易弄明白
为什么会破坏代码，因为它只是粘合代码
是可以避免破坏的
还有一些新功能
比如“Purchase Anywhere”
不知道你们有没有听Oscar主讲的
另一场Play结算会议
是关于在Play商店外购买的
这种新功能
只有发布新版本，重构Play结算服务
才能实现
这就是我们推出Play结算库
的原因
此外，如前所述
使用AIDL时，由于它是一个服务接口

English: 
So it's always a
hard time when you
had to update something or
have to consider a new feature.
And again, loads of glue code.
So you need to paste the same
code over and over again.
And sometimes it's just
if you change a parameter
from in to subs, for example, it
can break that part of the code
that you are using.
And it was not so
easy to see why
you are breaking the code
because it's just glue code
that you could avoid that.
And for example,
some new features
like the purchase anywhere--
I don't know if you were here
in the other session about Play
Billing that Oscar did about,
for example, chasing out
of Play Store, right?
So this kind of
new feature, it's
only possible to do with a
new version, a refactoring
of our Play Billing Services.
So this is why we come up
with the Play Billing Library,
right?
And like I said, on the--
when you're using AIDL, because
it's a service interface,

Japanese: 
何かアップデートしたり
新しい機能を加えたりするのは
いつも大変です
グルーコードだらけになります
同じコードを何回も何回もペーストしなければ
なりません
パラメーターを例えば
inから
subsに変えたとき
使っているコードが一部
だめになったりします
なぜコードをダメにしてしまったのか
を理解するのは
それほど簡単でありません
なぜなら 単なるグルーコードであり
避けることもできたはずだからです
たとえば
purchase anywhereのような
新しい機能
オスカーが話した
プレイ課金のセッションは
出ましたか？
プレイストアから
チェースアウトするやつです
そういう新機能のために
プレイ課金サービスをリファクタリングするには
新しいバージョンで対応するしかありません
そういった訳で 私達はプレイ課金ライブラリを
開発しました
さきほども申し上げましたが
AIDLを使っていたとき
サービスインターフェースだったので

Spanish: 
como un archivo
donde deben introducir su código
y que deben vincular al servicio,
no hay una manera clara
de buscar versiones nuevas,
porque, entonces,
tienen que consultar
la documentación del sitio de Google,
la documentación de Android
y buscar las especificaciones nuevas
del servicio
y, luego, implementarlas en el cliente.
Así que no hay manera de, por ejemplo,
como cuando usamos dependencias
en Gradle,
ver y decir:
"hay una versión nueva".
Puede actualizar aquí y hay una versión
con funciones nuevas, ¿sí?
Pero con AIDL, eso no era posible.
Algo que no ofrecía
una buena experiencia a los usuarios
era que los desarrolladores
tenían la responsabilidad
de invocar la IU de Play Store
y de administrarla.
Así que si usan resultados XXXX,
algo así,
podría ser una experiencia
muy lenta o no muy amena.
Y ahora nos estamos ocupando de esto.
Ahora hablaremos de la Biblioteca
de Facturación Google Play 2.0.

English: 
it's like a file that you
have to put in your code
and have to bind to the
service, there was no way--
clear way-- to check
for new versions,
because then you must go to the
Google website documentation,
Andoid documentation, and
check the new specifications
of service, and then
implement in your client.
So there is no way
to, for example,
when we are using the pen--
this is on [INAUDIBLE]----
you can say, hey, there
there's a new version.
It can update here and
there is a new version
with new features, right?
But with AIDL, this
was not possible.
And other things
that kind of could
give not a very good
experience for users,
that the developers were
responsible for calling
the Play Store UI and
the way you manage this.
So if you are using [INAUDIBLE]
results, something like that,
could be a very slow or very
not friendly experience.
And now we are taking
care about this.
So we here come to the
Play Billing Library 2.0.

Portuguese: 
é como um arquivo que você
tem que colocar no código
e vincular ao serviço, não há uma forma
clara de verificar se há novas versões,
porque você tem que consultar a
documentação do Google
e do Android para conferir
as novas especificações do serviço
e depois implementar no cliente.
Por exemplo, com o Gradle,
vocês podem dizer:
"Uma nova versão. Eu atualizo aqui."
E há uma nova versão com mais recursos.
Com a AIDL isso não era possível.
E tem outras coisas que poderiam
não ser boas experiências aos usuários,
como a responsabilidade
dos desenvolvedores de chamar
a IU da Play Store
e o gerenciamento isso.
Dependendo do que você usasse,
a experiência poderia ser
lenta ou não tão intuitiva.
Estamos cuidando disso agora.
Aqui entra a Play Billing Library 2.0.

Japanese: 
それはファイルで コードの中に入れなければ
ならなかったわけで
サービスにバインドする必要があり
新しいバージョンをチェックする
良い方法がなく
そうすると グーグルのウェブサイト
ドキュメンテーションに行って
Androidドキュメンテーションまで行って
サービスの新しいスペックをチェックして
それからクライアントにインプリメント
しなければなりません
たとえば
Gradleでペンを使っていて
新しいバージョンが出ている
この部分がアップデートされている
新しい機能のある新しいバージョンが
出ている みたいな状況です
AIDLでは これができませんでした
ユーザーにとってあまり良い
エクスペリエンスにならないものとして
他にあるのは
プレイストアのUIを呼び出す責任が
デベロッパーにあることと
これの管理の仕方です
結果を使っている場合
動作が遅かったり あまり使いやすい
エクスペリエンスでなかったりします
今は こういったことに対応しています
プレイ課金ライブラリ2.0で できるようになっています

Chinese: 
它就像一个文件，您需要放入代码
然后绑定至服务
没有清晰的途径来查看新版本
您必须依次转到Google网站文档
Android文档，并查看新的服务规范
然后在客户端上实现
相反
如果我们使用Gradle
就可以直接说明有新版本
可以在这里更新
获取新功能
但使用AIDL无法做到这一点
此外，还有其他一些不足
会给用户带来不太好的体验
例如，开发者要调用Play商店UI
并按一定方式管理这些UI
如果您使用类似[听不清]的结果
速度会非常慢，体验也会非常不好
现在我们要解决这些问题
我们推出了Play结算库2.0

Korean: 
코드를 입력하고 
서비스에 바인딩해야 하는
파일과 같은 것이며
새로운 버전을 확인할
분명한 방법이 없었습니다
따라서 여러분은 
Google 웹사이트 문서,
Andoid 문서로 가서
서비스의 새로운 사양을
확인한 다음 클라이언트에서
구현해야 하기 때문에
어디에 새로운 버전이 있다고
여기에서 업데이트할 수 있다거나
저기에 새로운 기능을 지닌
새 버전이 있다고
말할 수 있는 방법이 없었습니다
AIDL에서는 이것이 불가능했습니다
이와 유사한 다른 것들도
사용자에게 좋은 경험을
제공하지 못했기에
개발자는 Play Store UI를 호출하고
이를 관리하는 방식에 대한
책임이 있었습니다
따라서 여러분이 
그와 같은 것을 사용 중인 경우
매우 느리고 그다지 좋지 않은
경험이 될 수 있었습니다
이제 Google에서
그러한 점을 십분 고려하여
Play 결제 라이브러리 2.0을
개발하였습니다

Indonesian: 
ini seperti file yang kodenya
harus Anda masukkan
dan harus diikatkan pada layanan,
tidak ada cara--
cara yang jelas-- untuk 
memeriksa versi baru,
karena Anda harus membuka
dokumentasi situs Google,
dokumentasi Android, dan 
memeriksa spesifikasi layanan baru,
dan menerapkannya
di klien Anda.
Jadi, tidak ada cara untuk, misalnya,
saat kita menggunakan pena--
ini pada [TIDAK TERDENGAR]----
Anda dapat mengatakan, 
hai, ada versi baru.
Ini dapat mengupdate di sini dan
ada versi baru dengan fitur baru, bukan?
Tetapi dengan AIDL, hal ini tidak mungkin.
Dan hal lain yang
dapat memberikan pengalaman 
yang kurang baik bagi pengguna,
adalah developer bertanggung jawab
untuk memanggil UI Play Store
dan cara Anda
mengelola ini.
Jika Anda menggunakan [TIDAK TERDENGAR]
hasilnya, semacam itu,
bisa jadi pengalaman yang
sangat lambat atau tidak nyaman.
Dan sekarang kami
sedang menangani hal ini.
Mari kita bahas Library 
Layanan Penagihan Play 2.0.

Indonesian: 
Beberapa ringkasan tentang apa yang kami
lakukan pada versi ini--
sekarang kita memiliki lebih banyak
class pendukung.
Kita tidak perlu membuat 
sekumpulan kode boilerplate.
Kita memiliki class 
yang siap digunakan.
Parser-- parser API dan hal
[TIDAK TERDENGAR] lainnya,
yang dapat kita gunakan.
[TIDAK TERDENGAR] yang dapat diandalkan 
ini sangat menarik
karena pada layanan Anda harus
membuat konstanta di kode Anda
atau semacamnya.
Lalu selalu membandingkan kode--
atau kode operasi dengan class konstanta,
semacamnya.
Dan kita tahu bahwa kita
ingin berakhir seperti--
kita tidak ingin melakukan
terlalu banyak hal seperti antarmuka
hanya untuk menampung
sekumpulan konstanta.
Sehingga mengapa tidak mengandalkan 
sistem untuk memberi tahu kita
kode yang tepat untuk digunakan.
Sehingga kita memiliki kode 
untuk diuji dan di-debug.
Parser API otomatis, ini adalah,
menurut saya,
salah satu fitur terbaik saat 
Anda menggunakan library klien,

Portuguese: 
Um resumo das coisas
que fizemos nesta versão.
Agora temos mais classes auxiliares.
Não precisamos mais
desse monte de códigos repetidos.
Temos as classes prontas para usar aqui.
Analisadores de APIs
e outras coisas úteis.
Códigos de erro confiáveis.
Isso é interessante
porque, nos serviços, você precisa
criar constantes no seu código.
E depois comparar o erro do código
ou o código da operação
com a classe de constantes.
Nós não queremos tantas interfaces
só para manter muitas constantes.
Então, por que não contar com
o sistema para dar o código correto?
Agora, os códigos facilitam
os testes e as depurações.
Na minha opinião, o 
analisador automático de APIs
é um dos melhores recursos
da biblioteca de cliente,

Chinese: 
下面简要介绍一下这个版本的功能
现在我们有更多的辅助程序类
因此不需要大量使用样本代码
可以用类取而代之
此外，还有API解析器和其他[听不清]功能
可以使用
可靠的错误代码，这一点非常有意思
因为在服务中，必须在代码中创建常量
或类似的东西
并将代码
或运行代码与常量类持续比较
类似这样的操作
我们不希望
最后做了很多接口工作
却只是为了存放一批常量
所以，何不依赖系统本身来告诉我们
要使用的正确代码是什么
现在，我们可以借助这些代码来简化测试和调试
自动API解析器
我个人认为这是客户端库的最佳功能之一

Japanese: 
このバージョンでできるようになったことを
すこし紹介すると
ヘルパークラスが増えました
定型コードをたくさん書く必要が
なくなりました
すぐに使えるクラスを用意されています
APIパーサーや[不明]が
使えます
信頼性の高い[不明]もあり
これは面白いです
どういうことかと言うと
サービスではコードに
定数をつくる必要があって
コードやオペレーションコードを
定数クラスと比べることなどが
必要です
このようなことはやめたいのですが
定数を保持するためだけに
インターフェースを
保持したくはありません
使える正しいコードを書くのは
システムに任せて
しまいましょう
このようなコード作成のテストとデバッグを
しなければなりません
自動APIパーサーです
私の考えでは
クライアントライブラリーでは
一番優れた機能だと思います

English: 
Some summary of the things
that we did on this version--
now we have more helper classes.
So we don't need to do this
bunch of boilerplate code.
We have the classes
ready to use here.
So parser-- API parsers and
other [INAUDIBLE] stuff,
so we can use.
Reliable [INAUDIBLE] here
it's very interesting
because on the services you must
create constants in your code
or something like that.
And then keep
comparing the code--
or the operation code with
your constant class, something
like that.
And we know that we
want to end like--
that we don't want to do
too much like interfaces
just to hold a
bunch of constants.
So why not rely on the
system to give us what
is the correct code to use.
So now we have these codes
making to test and debug.
Automatic API parser,
here it's, in my opinion,
one of the best features
when you're using the client

Spanish: 
Un resumen
de lo que hicimos en esta versión…
ahora tenemos más clases de ayuda.
Así que no tenemos
que escribir código repetitivo.
Tenemos las clases listas para usar aquí.
Unos analizadores de API
y otros recursos que se pueden usar.
Códigos confiables.
Esto es muy interesante
porque en los servicios
se deben crear constantes
en el código o algo parecido.
Y, luego, comparar el código
o el código de operación
con la clase de constante, algo así.
Y sabemos que queremos llegar al final,
que no queremos
hacer demasiadas interfaces,
sino solo conservar
una cierta cantidad de constantes.
Entonces, ¿por qué no confiar
en que el sistema nos indicará
el código correcto para usar?
Así que ahora tenemos estos códigos
para probar y depurar errores.
En mi opinión,
el analizador de API automático
es una de las mejores funciones
cuando se usa la biblioteca cliente

Korean: 
이번 버전에서 추가된 사항을 요약하자면
이제 헬퍼 클래스가 더 많아졌습니다
이제는 다량의 보일러플레이트
코드 작업을 할 필요가 없습니다
사용할 준비가 된 클래스가 있습니다
따라서 API 파서 및 다른 것들을
사용할 수 있게 되었습니다
이는 매우 흥미롭습니다
왜냐하면, 서비스에서 여러분은
코드 내에 상수나 그와 같은 것을
만들어야 하기 때문입니다
그런 다음 코드나 운영 코드를
상수 클래스나 그와 유사한 것과
계속해서 비교해야 합니다
그리고 우리는 단지
수많은 상수를 유지하기
위한 인터페이스와 같은
번거로운 작업을 하고 싶지 않습니다
따라서 우리가 사용할 수 있는
올바른 코드를 제공하는
시스템에 의존해야 합니다
이제 이러한 코드가 있어서
테스트 및 디버그가 보다 쉬워졌습니다
자동 API 파서는
제 생각으로는
클라이언트 라이브러리를 
사용 중이시라면 가장 좋은 기능 중의

Indonesian: 
karena Anda tidak tahu
apakah harus melewati semua paket
dan melakukan semua hal dari peta hash
dan memasukkan class Anda sendiri.
Dan misalnya, jika kita mengubah sesuatu,
Anda mungkin mengalami error
saat mencoba untuk mendapatkan
hal yang tidak ada di dalam peta hash,
atau hal sejenis ini.
Di sini, API sedang--
selalu library klien-- Anda selalu
mengikuti perkembangan API.
Sehingga Anda tidak perlu terus khawatir
Oke, apakah saya menulis nama 
parameter ini dengan benar
Control C, Control V, oke, pastikan 
bahwa [TIDAK TERDENGAR] benar.
Sehingga Anda tidak perlu 
menggunakan itu.
Kita memiliki pemroses dasar
untuk semua interaksi API.
Sehingga Anda tidak perlu 
memblokir kode.
Anda dapat menggunakan 
paradigma interaksi
untuk menerima notifikasi 
dari layanan Penagihan Play
saat sesuatu telah selesai.
Jika pembelian diproses 
dan langganan kami dibatalkan,
Anda akan menerima
semua notifikasi, semua respons
dari server Layanan Penagihan Play.
Hal ini memudahkan developer

Chinese: 
因为您不需要检查整个软件包
从哈希映射完成所有工作
然后放入您自己的类
如果我们修改了什么
您可能会在尝试获取
哈希映射中不包含的内容时遇到错误
或者类似的情况
现在，API可以代劳
客户端库会始终
跟随API演进
您不用时时担心
输入的参数名称是不是正确
然后Ctrl+c、Ctrl+v，确保参数正确
现在不需要这样做了
我们还有适用于所有API交互的基础监听器
因此无需屏蔽代码
您可以使用交互范式
在某项操作完成时，接收Play结算服务
发出的通知
例如，购买交易已处理
或订阅被取消时
您收到的所有通知和回复
都将由Play结算服务器发出
这样可以简化开发者的工作

Korean: 
하나라고 생각합니다
왜냐하면 여러분은
모든 번들을 거쳐 해시맵에서
모든 가져오기를 수행하고
여러분 자신의 클래스에 넣는
작업을 할 필요가 없기 때문입니다
예를 들어 우리가
무엇인가 변경할 경우
해시맵 내에 있지 않은 
무엇인가를 가져오려고 시도하면
오류가 발생할 수
있습니다
API가 항상
클라이언트 라이브러리 작업을 수행하며
여러분은 API를 따라가면 됩니다
따라서 여러분은
매개변수의 이름을 제대로 타이핑했는지
Control C, Control V 키를
제대로 눌렀는지 신경 쓸 필요가 없습니다
그런 것을 사용할 필요가 없는 것이지요
우리는 모든 API 상호 작용에 대한
기본 리스너가 있기 때문에
여러분은 코드를 차단할 필요가 없습니다
어떤 작업이 완료되면
상호 작용의 패러다임을 사용하여
Play 결제 서비스로부터
통지를 받을 수 있습니다
따라서 구매가 처리되고
구독이 취소되면
여러분은 Play 결제 서버로부터
모든 통지 및 응답을 받게 됩니다
이는 무엇인가 확인하기 위해
Play 서비스를 폴링하는 것보다

Portuguese: 
porque você não precisa
passar por todo o pacote,
fazer tudo no mapa de hash
e colocar na sua classe.
Por exemplo, se mudarmos algo,
você receberá um erro ao tentar
ter algo que não está no mapa de hash.
Aqui, a biblioteca de cliente
sempre segue a evolução da API.
Você não tem mais que se preocupar
se o nome do parâmetro está correto,
Ctrl C, Ctrl V,
ver se o formato está certo.
Você não precisa disso.
Temos listeners básicos para
todas as interações da API.
Você não precisa bloquear seu código.
Pode usar o paradigma das interações
para receber notificações do serviço
Play Faturamento quando algo termina.
Se uma compra é processada,
se uma assinatura é cancelada,
você recebe todas as notificações,
todas as respostas
do servidor do Play Faturamento.
Isso facilita as coisas
para um desenvolvedor,

Japanese: 
バンドルにすべて目を通して
ハッシュマップから
getをすべて行い
自分のクラスにputするようなことを
やってくれます
たとえば どこか変更したとき
ハッシュマップにないものを
getしようとして エラーになるかもしれません
そういったことです
APIがやること
クライアントライブラリーに
APIの展開に従っていればいいのです
このパラメーターの名前は正しくタイプしたとか
コピー ペーストをしたりとか
気にすることはなくなります
そういうのはやらなくてよくなります
すべてのAPIインタラクションには
基本的にリスナーがいます
したがって コードをブロックする
必要はありません
インタラクションのパラダイムを使って
何かやったときに
プレイ課金サービスから通知を
受けることができます
購入が処理されたり
サブスクリプションがキャンセルされたりすると
すべて通知が
プレイ課金サーバーから
届きます
何かをチェックするのに
プレイサービスに問い合わせるより

English: 
library, because you don't know
to go through all the bundle
and do the all the
gets from the hash map
and put in your own class.
And for example, if
we change something,
you might have an
error trying to get
something that's not
inside the hash map,
or this kind of thing.
So here, the API is doing--
always the client
library-- you always
follow the API evolution.
So you don't need
to keep concerning
about, OK, did I type correctly
the name of this parameter
Control C, Control V, OK, make
sure that [INAUDIBLE] correct.
So you don't need to use that.
We have basic listeners
to all API interactions.
So you don't need
to block your code.
You can use the
paradigm of interactions
to receive notification from
the Play Billing service
when something is done.
So if a purchase is processed
and our subscription
is canceled, you're
going to receive
all the notifications, all the
response from the Play Billing
server.
Just makes much
easier for a developer

Spanish: 
porque uno
no sabe cómo revisar todo el paquete,
hacer todas las obtenciones
del mapa de hashes
y colocar la propia clase.
Y, por ejemplo, si cambiamos algo,
es posible cometer un error
al intentar obtener algo
que esté fuera del mapa de hashes
o algo de este tipo.
Y, aquí, la API hace…
siempre la biblioteca cliente…
siempre se sigue la evolución de la API.
No hay que preocuparse
de si escribieron bien el nombre
de un parámetro.
Ctrl + C y Ctrl + V…
Asegurarse de que todo sea correcto.
No es necesario usar eso.
Tenemos objetos de escucha básicos
de todas las interacciones de la API.
Así que no tienen que bloquear el código.
Pueden usar el paradigma de interacciones
para recibir una notificación del servicio
de Facturación Google Play
cuando se hace algo.
Así que si se procesa una compra
y se cancela la suscripción,
recibirán todas las notificaciones,
todas las respuestas del servidor
de Facturación Google Play.
Es mucho más fácil para un desarrollador,

English: 
instead of just polling the
Play service to check something.
So you just receive a
callback when it happens.
Manage connection
to Google Play.
I'm going to show some piece of
code comparing both approaches,
but now you don't need
to bind to the server,
check the connection, and then
unbind the connection when
you are done, or
for example, taking
care of doing retry mechanism
if it requires you to reconnect.
So it's all-- it's everything
done by the library now.
You just use the library, and
all this connection stuff,
it's managed by the
Play Billing Library.
And easier adoption of
new features I would say
may be the only way
to adopt new features,
because we are
going to put only--
new features only available
on the Play Billing Library.
So the AIDL interface won't
receive any updates anymore.
So because we are
involved-- we are

Japanese: 
デベロッパーの仕事はずっと
簡単になります
何か起こったときに
コールバックが来ます
Google Playとの接続を管理するだけです
2つのアプローチを比較したコードをお見せします
ずっと サーバーに縛り付けられる必要はありません
接続をチェックして
終わったら接続を切って
たとえば
再接続が必要なときは
リトライ メカニズムを使う
必要はありません
ライブラリがすべてやってくれます
ライブラリに任せておけば
このような接続関連のことは
プレイ課金ライブラリで管理されます
新機能の採用がしやくなったと
思います
新機能を採用する方法は
プレイ課金ライブラリからしか
できないようになっています
AIDLインターフェースは
もう更新されません
私達がやっているのは

Korean: 
개발자에게 훨씬 쉬운 방식입니다
따라서 여러분은 콜백이
발생할 때 이를 수신하고
Google Play로의
연결을 관리하면 됩니다
두 가지 접근 방법을 비교하는
코드의 일부를 보여드리려고 하는데
하지만 이제 여러분은 서버에
바인딩하고, 연결을 확인하고
작업이 완료되면 바인딩을 해제하거나
다시 연결해야 하는 경우
재시도 메커니즘을 수행해야 하는
번거로운 작업을 할 필요가 없습니다
이제는 모든 것이 
라이브러리에 의해 수행됩니다
여러분은 라이브러리와
이 모든 연결 기능을 사용하면 됩니다
이는 Play 결제
라이브러리에서 관리합니다
그리고 새로운 기능은 반드시
손쉽게 도입할 수 있어야 합니다
왜냐하면 Google에서는
Play 결제 라이브러리에서 사용할 수 있는
새로운 기능만 출시할 것이기 때문입니다
따라서 AIDL 인터페이스는 더 이상
아무런 업데이트도 받지 못할 것입니다
Google에서는 라이브러리가

Chinese: 
不需要再轮询Play服务进行检查
只需在操作发生时接收回调
下一个是管理与Google Play的连接
我将展示一些代码，比较两种方法
现在您不需要绑定到服务器
检查连接，然后在完成操作后
断开连接
也不用在系统要求您重新连接时处理重试机制
现在，这一切都由结算库来完成
您只需使用结算库，所有的连接工作
将由Play结算库负责管理
下一个是更容易获取新功能
准确地说，是获取新功能唯一的方式
因为我们将只在Play结算库中
提供新功能
AIDL接口将不再进行任何更新
此外，我们

Spanish: 
en lugar de sondear el servicio de Play
para buscar algo.
Así que, cuando pasa eso,
solo se recibe una devolución de llamada.
Administrar una conexión con Google Play.
Voy a mostrar un poco de código 
para comparar ambos enfoques,
pero ahora no tienen
que vincular el servidor,
comprobar la conexión y, después,
desvincular la conexión
cuando haya finalizado o, por ejemplo,
ocuparse de establecer un mecanismo
de reintentos si se requiere conexión.
Ahora todo lo hace la biblioteca.
Solo se usa la biblioteca
y todo lo relacionado con la conexión,
se administra a través de ella.
Y diría que un proceso más sencillo
puede ser la única manera
de adoptar nuevas funciones,
porque solo estarán disponibles
en la Biblioteca de Facturación Google Play.
De este modo, la interfaz de AIDL
no recibirá más actualizaciones

Portuguese: 
porque ele não tem que procurar
o serviço do Play para verificar algo.
Você simplesmente recebe um
callback quando isso acontece.
Conexão gerenciada com o Google Play.
Vou mostrar partes do código
comparando as duas abordagens,
mas agora você não precisa
se vincular ao servidor,
verificar a conexão e depois
se desvincular quando terminar
ou, por exemplo, refazer o mecanismo
se for necessário se reconectar.
Tudo é feito pela biblioteca agora.
Basta usar a biblioteca e todas
as coisas relacionadas à conexão
são gerenciadas pela Play Billing Library.
A adoção mais fácil de novos recursos
pode ser a única maneira
porque os novos recursos estarão
disponíveis só na Play Billing Library.
A interface AIDL não receberá
mais nenhuma atualização.

Indonesian: 
bukan hanya melakukan jajak pendapat
layanan Play untuk memeriksa sesuatu.
Sehingga Anda hanya akan menerima 
callback ketika hal tersebut terjadi.
Mengelola koneksi ke Google Play.
Saya akan menunjukkan sebagian kode 
yang membandingkan kedua pendekatan,
tetapi sekarang Anda tidak perlu
mengikatnya pada server,
memeriksa koneksi, dan 
melepaskan koneksi saat
Anda telah selesai, atau misalnya, 
menangani
mekanisme coba ulang jika ini mengharuskan
Anda untuk menyambungkan ulang.
Jadi itu-- sekarang semuanya diselesaikan
oleh library.
Anda dapat menggunakan library, dan semua 
hal yang berhubungan dengan koneksi ini,
dikelola oleh
Library Layanan Penagihan Play.
Dan adopsi fitur baru yang lebih mudah
menurut saya
mungkin adalah satu-satunya cara 
mengadopsi fitur baru,
karena kami hanya akan meletakkan--
fitur baru hanya tersedia pada
Library Layanan Penagihan Play.
Sehingga antarmuka AIDL tidak akan 
menerima update lagi.

Portuguese: 
Isso porque estamos melhorando a interação
da biblioteca com o Play Faturamento.
Outra coisa legal é que ela cuida
do cache da IU do Play.
Você não precisa mais se preocupar
em chamar o Play e colocar os dados dele
no cache do seu app.
A Play Billing Library
faz tudo isso também.
Aqui está a novidade.
Talvez alguns de vocês já saibam.
Após 1º de maio de 2021, todos
os apps novos e atualizações
que usam AIDL ou a Play
Billing Library 1.0
não serão mais aceitos.
Então, vocês têm cerca de 18 meses
para começar a migração.
Esperamos que seja tempo suficiente.
Tomamos essa decisão exatamente
para oferecer uma melhor solução,
porque da versão 1.0 para a 2.0,
por exemplo,
houve uma refatoração completa.
A biblioteca agora é feita no Kotlin.

Korean: 
Google Play 결제와 통신하는 방식을
개선하고 있습니다
또 다른 좋은 점은 Play UI 캐싱을
지원한다는 것입니다
따라서 여러분은 Play를 호출하고
여러분의 애플리케이션과
캐시에 Play의 데이터를 저장하느라
신경을 쓰지 않아도 됩니다
이 부분에서도 Play 결제 라이브러리에서
여러분을 위해 모든 작업을
수행하고 있습니다
또한 새로운 소식이 있습니다
여러분 중 일부는
이미 들으셨을 수도 있는데요
2021년 5월 1일 이후로는
AIDL 또는 Play 결제 라이브러리
1.0을 사용하는 신규 앱과 업데이트는
모두 허용되지 않습니다
따라서 마이그레이션을 시작할 때까지
18개월 정도가 남아있는 셈이며
이 정도면 충분한 시간이라고 생각합니다
Google에서 이러한 결정을 내린 것은
더 나은 솔루션을 제공하기 위함입니다
이는 버전 1.0에서 버전 2.0으로
전면적인 리팩터링을 했기 때문입니다
이제 라이브러리는
Kotlin 기반으로 작성되기 때문에

Indonesian: 
Karena kami terlibat-- kami
menyempurnakan
cara library bekerja dengan
Layanan Penagihan Google Play.
Dan hal keren lainnya, fitur baru
menangani penyimpanan cache UI Play.
Jadi Anda tidak perlu 
memikirkan lagi
tentang memanggil Play dan 
menyimpan data cache dari Play
di aplikasi Anda sendiri,
cache Anda sendiri.
Jadi Library Layanan Penagihan Play
juga melakukan segalanya untuk Anda.
Dan berikut adalah beritanya.
Seseorang mungkin
menawarkan Anda--
beberapa penawaran yang 
pernah Anda dengar.
Setelah 1 Mei 2021, semua
aplikasi dan update baru
yang menggunakan AIDL atau
Library Layanan Penagihan Play 1.0
tidak akan diterima.
Sehingga Anda memiliki sekitar 18 bulan
untuk mulai melakukan migrasi.
Kami berharap itu adalah waktu yang cukup.
Tetapi kami mengambil 
keputusan ini
untuk menawarkan solusi 
yang lebih baik, karena dari versi 1.0
ke versi 2.0, misalnya, kami melakukan 
pemfaktoran ulang penuh.
Library sekarang, dibuat di Kotlin.

Chinese: 
正在改进结算库与Google Play结算的通信方式
因此，另一个
很酷的功能是它会管理Play UI缓存
您不需要再
调用Play，然后从Play将数据缓存
到您自己的应用缓存中
Play结算库也会为您处理所有这些
工作
这里公布一个消息
你们中的某些人
可能已经知道
2021年5月1日之后，我们将不再接受
使用AIDL或Play结算库1.0的
新应用和更新
因此有大概18个月的时间
可以进行迁移
希望这个时间对大家来说足够
我们这样做
完全是为了提供更好的方案
因为从1.0版到2.0版，我们做了完全的重构
最新的结算库以Kotlin为基础

English: 
improving how the library
talks with Google Play Billing.
And another cool stuff, it takes
care of the Play UI caching.
So you don't have
to mind anymore
about calling Play and
caching the data from Play
in your own application,
your own cache.
So the Play Billing Library is
doing everything that for you,
as well.
And here is the news.
Maybe someone offer
you-- some offer
you already heard about it.
After May 1, 2021, all
new apps and updates
that use AIDL or Play
Billing Library 1.0
will not be accepted.
So you have something
around 18 months
to start doing the migration.
So we hope it's enough time.
But we are taking
this decision exactly
to offer a better solution,
because from the version
1.0 to version 2.0, for
example, we did a full refactor.
The library now,
it's made on Kotlin.

Spanish: 
porque estamos mejorando la forma
en que interactúan la biblioteca
y la Facturación Google Play,
y algo genial es que se ocupa
de la caché de IU de Google Play.
Así que no tienen que preocuparse
de llamar a Google Play
y guardar datos en la memoria caché
de su propia app, su propia memoria caché.
La Biblioteca de Facturación Google Play
también se ocupa de todo eso.
Y les cuento la novedad.
Es posible que algunos de ustedes
ya hayan escuchado sobre esto.
Después del 1 de mayo de 2021,
las actualizaciones y apps nuevas
que usen AIDL o la Biblioteca
de Facturación Google Play 1.0
dejarán de aceptarse.
Así que tienen varios meses
para comenzar la migración.
Esperamos que el plazo sea suficiente.
Decidimos esto
para ofrecer una mejor solución,
porque de la versión 1.0
a la 2.0, por ejemplo,
hicimos una refactorización completa.
Ahora, la biblioteca se hace en Kotlin.

Japanese: 
ライブラリとGoogle Play課金の関係を
向上させることだけです
もう一つの優れた特徴についてですが
プレイUIキャッシングも取り扱っています
プレイを呼んだときに
プレイからデータを
自分のアプリや自分のキャッシュに
キャッシングするのを
もう気にする必要はありません
プレイ課金ライブラリがこれも
すべてやってくれます
新しい情報です
もう誰かから聞いて
ご存知かもしれませんが
2021年5月1日以降
AIDLやプレイ課金ライブラリ1.0を
用いているアプリやアップデートは
認められなくなります
移行の期間は
18ケ月ぐらいです
時間に余裕があればいいと思います
このように決めたのは
よりよいソリューションを提供できる
と考えたからです
たとえば バーション1.0 からバージョン2.0 への移行は
フルでリファクターを行いました
ライブラリは 現在
Kotlinで作られています

Korean: 
Kotlin 친화적이기도 합니다
Kotlin을 실행하고 계시다면
앱에서 Kotlin을 사용하고 계신 것입니다
이는 새로운 기능을
최선은 아닐지라도
보다 원활한 방식으로 구현하여
여러분이 새로운 기능을
앱에 구현할 수 있게 해 줍니다
따라서 Play 결제 라이브러리를
사용하는 것은 상당히 쉽습니다
방법은 다음과 같습니다
PBL(Play 결제 라이브러리)을 
Gradle에 추가합니다
문서를 확인하여
소수의 작업에 어떤 메소드를
호출해야 하는지 살펴봅니다
연결하고, 제품 목록을 만들고,
구매를 수행하는 것이
기본적으로 여러분이 하는 것입니다
물론 사용자가 이미 구매한
제품의 목록을 작성하는 것도
마찬가지입니다
따라서 여러분은 수많은
서비스 연결 작업과 검사 작업을
할 필요가 없습니다
사용하기 시작하면 모든 작업이 완료되고
준비가 되는 것이죠
결제 기능을 하루만에
구현할 수 있다고 말씀드릴 수 있습니다
단 하루에 아무런 오류 없이
테스트를 비롯해 모든 작업이
Play 결제 라이브러리를
사용함으로써 완료되는 것이죠

Chinese: 
因此它与Kotlin的兼容性很好
如果您在应用中使用Kotlin
这也是实现新功能的一个途径
即使不是最好的
也是更加顺利的
在应用中实现新功能的途径
使用Play结算库非常简单
具体方法如下
将PBL，也就是Play结算库，添加到Gradle
检查文档以了解
要调用哪些方法来完成少数几种操作
包括连接、列出产品、购买
等基本操作
当然，还要列出
用户已经购买的产品
您不需要执行一大堆服务连接
和检查的工作
只需开始使用
便一切都已就绪
可以说，一天之内就可以完成实施
不会出现什么错误
一天即可完成测试和所有工作

English: 
So it's much, also,
Kotlin friendly
if you are doing Kotlin--
you're using Kotlin in your app.
And this is also a way
to implement new features
in a best--
not best, but in a
more smooth way so
you can implement new
features, also, in your app.
So using the Play Billin
Library is as easy as--
it's really this way.
You add the PBL, the Play
Biling Library, to the Gradle.
You check the docs
to see which methods
you have to call
to few operations--
connect, list the products,
and do the purchase basically
is what you do.
And also, of course,
list the products
that the user already purchased.
So you don't need to do a
bunch of service connection
and a bunch of exam.
Just start using and it's done.
You are ready.
I could say that you could
implement billing in a day,
just in a day, with no errors
like testing and everything
else with using the
Play Billing Library.

Indonesian: 
Jadi ini, juga, ramah Kotlin
jika Anda menggunakan Kotlin-- Anda
menggunakan Kotlin di aplikasi Anda.
Dan ini juga adalah cara
untuk mengimplementasikan fitur baru
dalam-- terbaik
bukan terbaik, tetapi dengan cara
yang lebih halus
sehingga Anda juga bisa
mengimplementasikan fitur baru 
di aplikasi anda.
Jadi menggunakan Library
Layanan Penagihan Play akan semudah--
ini memang seperti ini.
Anda menambahkan PBL,
Library Layanan Penagihan Play, ke Gradle.
Anda memeriksa dokumen
untuk melihat metode mana
yang harus Anda panggil
ke beberapa operasi--
menyambungkan, mendata produk,
dan melakukan pembelian
adalah hal yang pada dasarnya 
Anda lakukan.
Dan juga, tentunya, buat daftar produk
yang telah dibeli pengguna.
Sehingga Anda tidak perlu melakukan
sekumpulan koneksi layanan
dan sekumpulan ujian.
Cukup mulai gunakan dan selesai.
Anda sudah siap.
Saya dapat katakan 
bahwa Anda bisa
mengimplementasikan 
penagihan dalam satu hari.
hanya satu hari, tanpa error 
seperti pengujian atau yang lainnya
dengan menggunakan 
Library Layanan Penagihan Play.

Portuguese: 
Ela é bastante adequada para o Kotlin,
se você usa essa linguagem no seu app.
É também uma forma de
implementar novos recursos
de uma maneira melhor,
ou mais estável.
Para implementar novos
recursos no seu app.
Usar a Play Billing Library
é muito fácil.
É assim:
Você adiciona
a Play Billing Library ao Gradle.
Verificamos nos documentos
quais métodos chamar
para algumas operações...
conectar, listar os produtos e
fazer as compras.
Basicamente, é isso.
E, claro, listar os produtos
que o usuário já comprou.
Você não precisa fazer
várias conexões e testes.
É só começar a usar e pronto.
Só isso.
Eu diria que você pode implementar
o faturamento em apps em um dia.
Um único dia, sem erros,
com os testes e tudo
relacionado ao uso da
Play Billing Library.

Japanese: 
アプリでKotlinを使っているなら
ライブラリはKotlinフレンドリーです
新しい機能を実装するには
もっとも優れた…
ベストではないですが
よりスムーズな方法です
自分のアプリにも新機能が実装できます
プレイ課金ライブラリを使うのは
とても簡単です
こんな感じです
PBLプレイ課金ライブラリをGradleに追加します
ドキュメントを見て
いくつかのオペレーション
どのメソッドを呼べばよいか
たとえば コネクト プロダクトのリストなどについて確認して
購入をする というのが
基本的にやることです
もちろん
ユーザーの過去の購入履歴も
リストします
サービスの接続や試験もほとんど
必要なくなります
ただ使い始めるだけです
すぐ準備ができます
課金は一日で始められます
たった一日のうちに
プレイ課金ライブラリを使って
すべて実現できます

Spanish: 
Así que anda muy bien
si usan Kotlin en su app.
Y esta también es una manera
de implementar funciones nuevas
de la mejor…
no mejor, pero de una manera más fluida
para que también puedan implementar
funciones nuevas en su app.
Es muy fácil usar
la Biblioteca de Facturación Google Play.
Es así:
Agregan la biblioteca a Gradle.
Comprueban los documentos
para ver los métodos
que tienen que invocar
en algunas operaciones…
Conectar, mostrar los productos
y hacer la compra.
Esto es lo que se hace, básicamente.
Además, por supuesto,
de mostrar los productos
que el usuario ya compró.
Así que no tienen que hacer
muchas conexiones de servicio ni exámenes.
La empiezan a usar y están listos.
Diría que pueden implementar
la facturación en un día,
solo en un día, sin errores, como
las pruebas y todo lo demás
con el uso de la Biblioteca
de Facturación Google Play.

Korean: 
따라서...
내용을 종합해서 안내해 드리겠습니다
첫 번째 단계는 물론 Gradle에
종속성을 추가하는 것입니다
2.0.3 그러니까
시작하는 즉시
문서를 확인하세요
하지만 제가 말씀드렸듯이
여러분이 구 버전을 사용 중인 경우
Gradle에서 여러분에게 알려줄 것입니다
새로운 버전이 있다고 말이죠
새로운 버전을
사용하기 시작하세요
그런 다음 일부 클래스를 삭제하세요
이미 AIDL을 사용 중인 경우
일부 클래스를 삭제할 수 있습니다
왜냐하면 이제 무료니까요
예를 들어, 
이 그림에서 여러분은
이것이 Google의 Trival Drive 샘플에서
왔음을 볼 수 있습니다
2013년에 Google에서 
Trival Drive용으로 만든
첫 번째 샘플이죠
그리고 많은 클래스가
있다는 것도 알 수 있습니다
purchase.java, 
EIB result AB helper, 이 모든 클래스가
보일러플레이트 코드로서 생성되었습니다
그리고 이제 이러한 클래스--
정확히는 이러한 클래스가 아니지만

Indonesian: 
Jadi mari lihat--
Saya menyusun panduan.
Jadi langkah pertama adalah, tentu saja,
tambahkan dependensi pada Gradle.
Jadi 203, tentunya, periksa dokumentasi
saat Anda mulai melakukannya.
Tapi seperti yang saya katakan,
Gradle akan memberi Anda notifikasi
jika Anda menggunakan versi lama.
Notifikasinya akan berkata, 
hai, ada versi baru.
Cukup mulai gunakan versi baru.
Dan hapus beberapa class.
Jika Anda telah menggunakan AIDL, ya,
Anda bisa menghapus beberapa class
karena sekarang semuanya gratis.
Misalnya, di gambar ini, 
Anda dapat melihat
itu berasal dari 
contoh Trivial Drive kami,
contoh pertama yang kami buat tahun 2013,
saya rasa,
untuk Trivial Drive.
Dan Anda bisa lihat,
ada sekumpulan class--
purchase.java, hasil EIB, pendukung AB,
semua class ini 
dibuat sebagai kode boilerplate.
Dan sekarang class ini--
tentu bukan class ini, tentunya,

English: 
So let's see--
I put together, like, a guide.
So the first step is, of
course, add the dependencies
on the Gradle.
So 203, of course,
check the documentation
the moment you are start doing.
But like I said,
Gradle will notify you
if you are using an old version.
It will say, hey,
there is a new version.
Just start using
the new version.
And then delete some classes.
If you are already
using AIDL, yes, you
can delete some classes
because now they are for free.
For example, in
this picture, you
can see it's from
our Trivial Drive
sample, the first sample
we made in 2013, I think,
for Trivial Drive.
And you can see, there
is a bunch of classes--
purchase.java, EIB result
AB helper, all these classes
were created as a
boilerplate code.
And now these classes--
not exactly these
classes, of course,

Japanese: 
さて…
ガイドをまとめると
まず最初に
Gradleで依存性を
定義します
開始と同時に
ドキュメントをチェックして
言ったように
古いバージョンを使っていたら
Gradleが教えてくれます
新しいバージョンがありますよ
と言ってくるので
新しいバージョンを使います
クラスをいくつか消去します
AIDLを使っていた場合は
クラスをいくつか消去できます
なぜならフリーだからです
たとえば このスライドの
Trivial Driveサンプルで
最初のサンプルはたしか
2013年に作ったものだと
思いますが
ご覧のようにクラスが
たくさんあります
purchase.javaとかEIB result
AB helperなど
これらのクラスが定型コードとして
作られていました
今では
これらのクラスは
正確に言うと もちろん
クラスではないのですが

Portuguese: 
Vamos dar uma olhada no guia que eu criei.
A primeira etapa é
adicionar as dependências no Gradle.
2.0.3. Verifiquem a documentação
quando começarem.
O Gradle avisará
se estiver usando uma versão antiga.
Ele vai dizer: "Tem uma
versão nova. Use-a".
E exclua algumas classes.
Se você usa a AIDL, exclua algumas classes
porque agora elas são gratuitas.
Por exemplo, aqui vocês podem ver
que ela é da amostra do Trivial Drive.
Acho que fizemos a primeira
amostra do Trivial Drive em 2013.
Vocês podem ver que há várias classes:
Purchase.java, IabResult, IabHelper.
Todas criadas como código repetido.
Agora, essas classes...
não exatamente essas, obviamente,

Chinese: 
接下来
我总结了一个指南
第一步肯定是在Gradle中添加
依赖项
203，在开始使用时
要检查文档
不过，如果您使用的是旧版本
Gradle会通知您
它会提示您有新版本
您选择新版本即可
然后，删除一些类
如果您已经在使用AIDL
就可以删除一些类，因为现在它们是免费的
例如，在这张图中
展示了我们2013年
为Trivial Drive制作的
第一个样本
其中包含一系列类
purchase.java、labResult、labHelper
所有这些类都是作为样板代码创建的
现在，这些类
更准确地说

Spanish: 
Entonces, veamos…
Lo organizo, como una guía.
El primer paso es, por supuesto, agregar
las dependencias en Gradle.
203, por supuesto, comprueban
la documentación
en el momento que comienzan,
pero, como dije, Gradle los notificará
si usan una versión anterior.
Les dirá que hay una versión nueva
que tienen que comenzar a usar.
Luego, quiten algunas clases.
Si ya usan AIDL,
pueden quitar algunas clases
porque ahora son gratuitas.
Por ejemplo, esta imagen es
de nuestra muestra de Trivial Drive,
la primera muestra que hicimos en 2013.
Como pueden ver, hay un montón de clases:
Purchase.java, IabHelper,
IabResult, etcétera.
Se crearon todas esas clases
como código repetitivo.
Y ahora esas clases…
no exactamente estas clases,

English: 
but these functionalities,
it's embedded
into the client library.
So you don't need anymore
to change your EIB
helper every time you update
a new product, something
like that.
So you can use all the classes.
And what changes you
need to do in your code
if you are migrating from AIDL
to the Play Billing Library
2.0?
So first you don't need
to manage connection
with Play Service
by ourself anymore.
So what you do is create an
instance of BillingClient.
Then you have to implement
the BillingClientStateListener
to receive the callbacks
about the service status.
So you don't need to manage.
You just need to know what is
happening, so if it's connected
or it's disconnected.
But you don't need
to retry by yourself.
For example, if the
connection is lost,
the service will redo
the connection by itself.
So you don't need to
take care about this,
but you can check the status.
And then you call the
method start connection

Indonesian: 
tetapi fungsionalitas ini, akan disematkan
ke dalam library klien.
Sehingga Anda tidak perlu lagi mengganti
pendukung EIB Anda
setiap kali mengupdate produk baru, 
seperti itu.
Sehingga Anda bisa 
menggunakan semua class.
Dan perubahan apa 
yang perlu Anda lakukan di kode
jika Anda bermigrasi dari AIDL ke
Library Layanan Penagihan Play 2.0?
Jadi pertama-tama, Anda
tidak perlu lagi mengelola koneksi
dengan Layanan Play sendiri.
Sehingga yang perlu Anda lakukan adalah
membuat instance BillingClient.
Lalu Anda harus mengimplementasikan
BillingClientStateListener
untuk menerima callback
tentang status layanan.
Sehingga Anda tidak perlu mengelola.
Anda hanya perlu mengetahui
apa yang terjadi, apakah ini terhubung
atau terputus.
Tetapi Anda tidak perlu 
mencoba ulang sendiri.
Misalnya, jika koneksi terputus,
layanan tersebut akan menghubungkan ulang
dengan sendirinya.
Jadi Anda tidak perlu menangani hal itu,
tetapi Anda dapat memeriksa statusnya.
Lalu memanggil metode startConnection()

Korean: 
이러한 기능들이 클라이언트 라이브러리에
임베드됩니다
따라서 여러분은 더 이상
새로운 제품을 업데이트할 때마다
EIB helper를 변경할 필요가 없습니다
따라서 여러분은 모든 클래스를 사용할 수 있습니다
AIDL에서 Play 결제 라이브러리 2.0으로
마이그레이션할 경우 
여러분이 코드에서 변경해야 할 것이
무엇일까요?
우선 여러분은 더 이상
Play 서비스와의 접속을
혼자서 관리해야 할 필요가 없습니다
여러분이 해야 할 것은
BillingClient의 인스턴스를 만드는 것입니다
다음으로 
BillingClientStateListener를 구현하여
서비스 상태에 대한 콜백을 수신하는 것입니다
따라서 여러분은 관리할 필요가 없습니다
어떤 일이 발생하고 있는지 즉,
연결이 되어 있는지 또는
연결이 끊어졌는지만 알면 됩니다
혼자서 재시도할 필요가 없습니다
예를 들어, 연결이 끊어진 경우
서비스가 자동으로 연결을 다시 실행합니다
따라서 여러분은 이에 대해 신경쓰지 않고
상태를 확인하면 됩니다
그런 다음 BillingClient 인스턴스에서

Portuguese: 
mas essas funcionalidades
estão incorporadas à biblioteca.
Você não precisa mais mudar IabHelper
sempre que atualiza um novo produto etc.
Pode usar todas as classes.
E quais mudanças fazer no código
ao migrar para a Billing Library 2.0?
Primeiro, você não precisa mais gerenciar
conexões com o Play Services sozinho.
Crie uma instância de BillingClient.
Depois, implemente o
BillingClientStateListener
para receber os callbacks
sobre o status do serviço.
Não é necessário gerenciar.
Só saber o que está acontecendo,
se ele está conectado ou não.
Não precisa ficar repetindo.
Se a conexão se perde,
o serviço a restabelece.
Você não precisa se preocupar,
mas pode verificar o status.

Japanese: 
これらの機能は
クライアントライブラリに
エンベッドされています
したがって 新しいプロダクトを
更新するたびに
EIBヘルパーを変更する必要は
ありません
クラスは全部使えます
AIDLからプレイ課金ライブラリ2.0に移ってきた場合
自分のコードではどこを変更すれば
よいのでしょうか？
まず 自分でプレイサービスへの
接続を管理する必要はありません
やることは 
BillingClientのインスタンスを作ることです
そしてBillingClientStateListenerを
インプリメントして
サービスステータスのコールバックを
受けれるようにします
管理する必要はありません
何が行われているか知るだけでよく
つながっているか
つながっていないかが分かっていれば
十分です
自分でリトライする必要はありません
たとえば 接続が失われた場合
サービスが再接続を試みてくれます
自分でやる必要はなく
ステータスをチェックするだけです
そしてstart connectionメソッドを

Spanish: 
sino estas funcionalidades,
están integradas
en la biblioteca del cliente.
Así que no necesitan nada más
para cambiar su IabHelper
cada vez que actualizan
un producto nuevo.
Pueden usar todas las clases.
Y, ¿qué cambios tienen que hacer
en el código
si migran de AIDL a la Biblioteca
de Facturación Google Play 2.0?
En primer lugar, no tienen que volver
a administrar la conexión
con el servicio de Google Play.
Lo que hacen
es crear una instancia de BillingClient.
Después, tienen que implementar
BillingClientStateListener
para recibir las devoluciones
sobre el estado del servicio.
No deben ocuparse
de la administración.
Solo tienen que saber lo que sucede,
si está conectado o desconectado.
Pero no tienen
que volver a intentarlo por su cuenta.
Por ejemplo, si se pierde la conexión,
el servicio volverá a establecerla.
No se tienen que ocupar de hacerlo,
pero sí pueden comprobar el estado.
Y luego llaman la conexión
de inicio del método

Chinese: 
是这些类的功能已嵌入
客户端库
因此，您不用在每次更新新产品时
更改labHelper
等等
您可以使用所有类
那么，您需要对代码做出哪些更改
才能从AIDL迁移至Play结算库
2.0呢？
首先，不再需要自己管理
与Play服务的连接
您只需创建BillingClient的实例
然后实现BillingClientStateListener
接收关于服务状态的回调
您不需要进行管理
只需要知道结果是已连接
还是未连接
您不需要自己去重试
例如，如果失去连接
服务会自动重试连接
您不用为此费心
但是您可以查看状态
然后针对BillingClient实例

English: 
on the BillingClient
instance, just like that.
You don't need to
create a service, bind.
You don't need to
check for the intent.
Just use the BillingConnect
and you'll do it for you.
And if you are using
the old AIDL style,
you have to remove the--
all the own active result
code because what happens
is, when you are using
AIDL, you call Play Store.
And when it's done, the
app is call it back.
And then you have
to process what
this result in your
activity, because it comes
as a parameter in the intent.
So now you don't
need to do that.
Now you can implement
the listeners.
And the listener
will be notified
when the purchase is completed.
So it's much easier
than managing states
and all the lifecycle
potential issues
you know that can happen
when you are handling
this kind of own
activity result.
So let's check a
little bit about code.

Indonesian: 
pada instance BillingClient,
hanya begitu.
Anda tidak perlu
membuat layanan, ikatan.
Anda tidak perlu memeriksa intent.
Hanya gunakan BillingConnect dan Anda
akan membuatnya bekerja untuk Anda.
Jika menggunakan gaya AIDL lama,
Anda harus menghapus--
semua kode hasil aktif sendiri
karena yang terjadi adalah,
saat Anda menggunakan AIDL,
Anda memanggil Play Store.
Dan saat selesai, aplikasi
akan memanggilnya kembali.
Lalu Anda harus memproses pengaruhnya
di aktivitas Anda, karena ini datang
sebagai parameter dalam intent.
Sehingga Anda sekarang
tidak perlu melakukan itu.
Sekarang Anda dapat mengimplementasikan
pemroses.
Dan pemroses itu akan diberi notifikasi
saat pembelian selesai.
Sehingga ini jauh lebih mudah
dari mengelola status
dan semua potensi masalah siklus proses
yang Anda tahu bisa saja terjadi
saat Anda menangani 
hasil aktivitas sendiri sejenis ini.
Jadi mari memeriksa sedikit tentang kode.

Portuguese: 
Depois, chame o método startConnection()
na instância BillingClient. Só isso.
Você não tem que criar um serviço, 
uma vinculação.
Não precisa verificar o intent.
Basta usar BillingConnect e pronto.
Se você estiver usando
o estilo antigo da AIDL,
remova o código onActivityResult
porque, quando você usa a AIDL,
você chama a Play Store.
Quando acaba, o app é chamado novamente.
Aí, você tem que processar
esse resultado na sua atividade
porque ele vem
como um parâmetro no intent.
Mas você não precisa fazer isso.
Agora você pode implementar os listeners.
E o listener será notificado
quando a compra for concluída.
É muito mais fácil que gerenciar estados
e todos os possíveis problemas
de ciclo de vida que podem ocorrer
ao lidar com onActivityResult.
Vamos analisar um pouco sobre códigos.

Korean: 
연결 시작 메소드를 호출하세요
서비스를 만들어 바인딩할 필요가 없습니다
인텐트를 확인할 필요가 없습니다
BillingConnect를 사용하면
알아서 자동으로 해 줍니다
그리고 이전 AIDL 스타일을
사용 중이신 경우
모든 자체 활성 결과 코드를
제거해야 합니다
왜냐하면 AIDL을 사용할 때
Play Store를 호출하기 때문입니다
호출이 완료되면
앱에서 다시 호출을 수행합니다
결과가 인텐트에
매개변수 형태로 제공되므로
이 결과를 처리해야 합니다
따라서 이제 여러분이
처리하지 않아도 됩니다
이제 여러분은 리스너를 구현할 수 있고
구매가 완료되면 리스너가
통지를 받게 됩니다
따라서 이러한 종류의 활동 결과를 
처리할 때 발생할 수 있는
모든 수명주기 잠재 문제와
상태를 관리하는 것보다 훨씬 쉽습니다
코드에 대해 잠시 살펴보겠습니다

Chinese: 
调用方法startConnection，仅此而已
您不需要创建服务，然后绑定
也不需要检查intent
只需要使用BillingClient，它会代劳
如果您使用旧的AIDL
则需要删除
所有旧的activity结果代码，因为现在的情况是
如果您使用的是AIDL，就要调用Play商店
完成后，应用会进行回调
这时，您就要处理activity中的结果
因为它以参数的形式
出现在intent中
现在，您不需要做这些工作了
您可以实现监听器
监听器会在
购买完成时收到通知
相较于管理状态
以及处理这种自身activity结果时
可能出现各种潜在的生命周期问题
这要轻松很多
我们来看看代码

Spanish: 
en la instancia de BillingClient.
Así de fácil.
No tienen que crear un servicio,
sino vincularlo.
No tienen que comprobar el intent.
Simplemente usen BillingConnect,
y lo hará por ustedes.
Y si utilizan el estilo AIDL anterior,
tienen que quitar todo el código
de resultado activo propio
porque lo que sucede es que,
cuando usan el AIDL, llaman a Play Store.
Y cuando se hace,
se llama nuevamente a la app.
Y luego tienen que procesar
lo que esto genera en su actividad
por aparecer
como un parámetro en el intent.
Así que ahora no tienen que hacer eso.
Ahora pueden implementar
los objetos de escucha.
Y se notificará a ese objeto
cuando se complete la compra.
Así que es mucho más fácil
que administrar estados
y todos los problemas potenciales
del ciclo de vida útil
que saben que pueden suceder
cuando manejan este tipo
de resultado de actividad propia.
Pasemos al código.

Japanese: 
BillingClientインスタンス上で呼びます
サービス バインドを生成する必要は
ありません
インテントをチェックする必要もありません
BillingConnectを使うだけで
あとはやってくれます
古いAIDLのスタイルを使っていたら
自分のアクティブな結果のコードを
すべて削除する必要があります
なぜなら AIDLを使っている場合
プレイ ストアを呼び
終わると
アプリがコールバックします
この結果をアクティビティの中で
処理する必要があります
なぜなら インテント中の
パラメータとして
得られるからです
今では この必要はありません
リスナーをインプリメントするだけです
すると 購入が終わると
リスナーに連絡がきます
今までよりずっと簡単です
この種の結果を取り扱う場合に
起こる可能性のある
ライフサイクルにわたった問題や
状態を管理するのは
ずっと大変です
コードについて見てみましょう

Korean: 
듣기만 하는 것보다
코드를 보는 게 나으니까요
이것이 AIDL을 사용할 때 
여러분이 해야 하는 것입니다
보시는 것처럼
서비스의 연결이 끊어지고
연결이 될 때 무엇이 발생하는지
정의하셔야 합니다
그런 다음 인터페이스를 구현해야 합니다
그런 다음 인텐트의
이름을 기억해야 합니다
따라서 출력 문자열에
이러한 내용을
하드코딩해야 합니다
이것을 복사하세요
그리고 저도 경험한 바이고
여러분도 경험한 바일 수 있는데
이 문자열에 오타가 있어
한 시간 동안 디버깅을 하지만
오류를 찾지 못하고
4시간이 지나서
샤워를 하면서 이런,
오타가 있었네 하는 경험이 있으셨죠?
그렇죠?
여러분도 경험한 적이 있나요?
항상 발생하는 일이죠
이제 이런 일을 겪을 필요가 없습니다
이것이 Play 결제 라이브러리를
사용할 때의 코드입니다
따라서 여러분은 새로운
빌더 디자인 패턴을 사용하는
새로운 인스턴스를 갖게 됩니다

Portuguese: 
Sei que vocês gostam de ver códigos,
não apenas falar sobre eles.
É assim que você faz quando usa a AIDL.
Como vocês podem ver, é preciso definir
o que acontece quando um serviço
está desconectado ou conectado.
Você tem que implementar esta interface.
Depois, lembrar o nome do intent
para inserí-lo na string de saída.
Mas tem que copiar isso.
Aconteceu comigo, e talvez
já tenha acontecido com vocês.
Você tem um erro de digitação nesta string
e continua depurando por uma hora.
Você não acha o erro.
Depois de quatro horas,
você percebe:
"Tem um erro de digitação!"
Certo?
Já aconteceu com vocês?
Acontece sempre.
Não precisamos mais fazer isso.
Este é o código quando usamos a
Play Billing Library.
Então, vocês têm a nova instância
usando o novo padrão de design do builder.

English: 
I know you like to see
code, so not just talking.
Well, this is the way you
should do when using AIDL.
So as you can see,
you need to define
what happens when a
service is disconnected
and service connected.
Then you have to
implement this interface.
Then you need to remember
the name of the intent,
so you have to hard core
these in your output
[INAUDIBLE] string.
But you need to copy this.
And it happened to me, and
maybe happened to you already.
You just miss-- you have a typo
in this string and then you
don't--
like, you keep
debugging for one hour.
You don't find the error.
And then after-- find,
like, after four hours,
you take a shower, oh, yes.
There is a typo.
Right?
That ever happen to you?
It happens every time.
So now we don't need
to do this anymore.
So this is the code when
using Play Billing Library.
So you have the new
instance using the pattern--
the new builder design pattern.

Chinese: 
我知道大家喜欢看代码，而不是纸上谈兵
这里展示了使用AIDL时的方法
您需要定义
服务在断开连接和建立连接时
会发生什么
然后需要实现这个接口
记住intent的名称
您需要隐藏代码，把它们放到
一个字符串中
然后复制
我们可能都遇到过这样的情况
字符串中存在拼写错误
然后
您花了一个小时不断调试
也没有找到错在哪里
找了四个小时之后
洗了个澡回来，才发现
哦，错误在这里
是吧？
你们有过这样的遭遇吗？
这非常常见
现在不会再这样了
这是使用Play结算库时的代码
新的实例使用
新的生成器设计模式

Japanese: 
みなさんは 話を聴くだけでなく
コードも見てみたいですよね
AIDLの場合はこうなります
ご覧のように
サービスが切り離された場合
サービスが繋がっている場合に
どうするかについて
定義しておく必要があります
そして このインターフェースを
インプリメントしなければなりません
インテントの名前を覚えておいて
自分の出力にこれらをコード化する
必要があります
これをコピーしなければなりません
私がよく経験したことで
皆さんも経験があるかと思いますが
このストリングにタイプミスがあって
そのせいで
1時間もデバッグに費やすこともあります
ミスは見つけにくいものです
4時間頑張って
シャワーを浴びて
ようやく見つかったのが
タイプミスでした
こんな感じです
似たような経験がおありでしょう？
私はしょっちゅうです
もうこんなことは必要ありません
これがプレイ課金ライブラリを使った場合の
コードです
パターンを使ってインスタンスを作ります
新しいビルダーデザインパターンです

Spanish: 
Sé que les gusta ver código,
no solo escuchar hablar de él.
Esto es lo que deberían hacer
al usar el AIDL.
Como pueden ver,
tienen que definir lo que sucede
cuando se conecta
y desconecta un servicio.
Luego,
tienen que implementar esta interfaz
y recordar el nombre del intent
para poder incorporarlo en los resultados.
Pero tienen que copiar esto.
Esto me pasó, y tal vez a ustedes también.
Apenas omiten, tienen un error tipográfico
en la string y después no…
Siguen depurando errores
durante una hora.
No encuentran el problema.
Y más tarde, después de cuatro horas,
mientras se están bañando,
dicen “oh, hay un error tipográfico".
¿No es así?
¿Alguna vez les pasó eso?
Pasa todo el tiempo.
Ahora no tenemos que hacerlo más.
Este es el código cuando usan
la Biblioteca de Facturación Google Play.
En la instancia nueva, se usa
el patrón de diseño de compilación nuevo.

Indonesian: 
Saya tahu Anda senang melihat kode,
tidak hanya berbicara saja.
Jadi, ini adalah cara yang seharusnya
Anda lakukan saat menggunakan AIDL.
Jadi seperti yang Anda bisa lihat, 
Anda perlu menentukan
hal yang terjadi saat layanan terputus
dan saat layanan terhubung.
Lalu Anda perlu mengimplementasikan
antarmuka ini.
Lalu Anda perlu mengingat nama intent,
sehingga Anda harus memasukkan 
semua ini di string
[TIDAK TERDENGAR] output Anda.
Tetapi Anda perlu menyalin ini.
Dan itu terjadi pada saya, dan mungkin
telah terjadi pada Anda.
Anda hanya kurang-- Anda memiliki
salah ketik di string ini lalu Anda
tidak--
Anda terus melakukan proses debug
selama satu jam.
Anda tidak menemukan error.
Lalu setelah-- menemukannya,
setelah empat jam,
Anda mandi, oh, iya.
Ada salah ketik.
Benar, kan?
Hal itu pernah terjadi pada Anda?
Itu selalu terjadi.
Sehingga sekarang kita tidak perlu lagi
melakukan ini.
Jadi ini adalah kode saat menggunakan
Library Layanan Penagihan Play.
Sehingga Anda memiliki instance baru
menggunakan pola--
pola desain builder yang baru.

Portuguese: 
Você define o listener.
Nesse caso, a atividade é o listener.
Você pode usar qualquer classe,
qualquer elemento da estrutura.
E depois faz uma compilação.
Depois disso, é só iniciar a conexão.
Não há nome de intent, de permissão, nada.
É só chamar startConnection().
Aqui, é necessário substituir
onBillingSetupFinished.
Você não precisa repetir,
por exemplo, como eu disse.
Não precisa repetir se está desconectado.
Mas pode ser útil chamar querySkuDetails
após conectar para listar os detalhes
da SKU para esse usuário, por exemplo.
Mas isso depende da sua lógica.
Se você chama querySkuDetails
quando o usuário quer ver o produto, OK.
É só um modo de mostrar
que você chamar querySkuDetails
porque o cliente
de faturamento está pronto.

Indonesian: 
Anda menyetel
pemrosesnya.
Di kasus ini, kita mengatakan
bahwa aktivitas sendiri adalah pemroses.
Tetapi Anda bisa menggunakan 
class apa pun yang diinginkan,
apa pun di struktur Anda jika diinginkan.
Lalu lakukan build.
Setelah itu, mulai koneksi saja.
Tidak ada nama intent.
Tidak ada nama izin, kosong.
Anda hanya memanggil startConnection.
Dan di sini Anda harus mengganti
penyiapan pembuatan sendiri selesai.
Ini hanya-- Anda tidak perlu
mencoba ulang.
misalnya, seperti yang saya katakan.
Anda tidak perlu mencoba ulang
saat ini terputus.
Tapi Anda mungkin ingin untuk-- Anda ingin
memanggil querySkuDetails
setelah koneksi selesai sehingga Anda 
bisa membuat daftar
semua detail SKU yang Anda miliki 
untuk pengguna tersebut, misalnya.
Tapi ini sesuai dengan logika Anda.
Jika Anda hanya memanggil
querySkuDetails
saat pengguna meminta
untuk melihat produk, tidak masalah.
Ini adalah salah satu cara
yang kita tunjukkan bahwa Anda harus--
Anda bisa memanggil querySkuDetails
karena klien penagihan telah siap.

English: 
You set the listener.
In this case, we are saying
that the own activity
is the listener.
But you could use any
class you want, anything
in your structure if you want.
And then do a build.
After that, start
connection only.
There is no name of intent.
There is no name of
permission, nothing.
You just call start connection.
And here you have to override
the own building set up finish.
It's just-- you
don't need to retry,
for example, like I said.
You don't need to retry
if it's disconnected.
But you want to probably-- you
want to call querySkuDetails
after the connection
is done so you
can list all the SKU details
you have for that user,
for example.
But it's according
to your logic.
So if you are only calling
the querySkuDetails
when the user asks to see
the product, no problem.
It's just a way that we
are showing that you must--
you can call the querySkuDetails
because a billing
client is ready.

Spanish: 
Configuran el objeto de escucha.
En este caso, es la propia actividad.
Pero podrían usar la clase que quieran,
lo que sea de la estructura que quieran.
Y después hacer una compilación.
Entonces, solo queda comenzar la conexión.
Sin nombre de intent ni de permiso. Nada.
Simplemente invocan la conexión de inicio.
Y aquí, tienen que anular la finalización
de configuración de la propia compilación.
No tienen que volver a intentarlo,
por ejemplo, como ya dije,
si está desconectado.
Pero es probable que quieran llamar
a querySkuDetails
después de que se establezca la conexión
para poder mostrar todos los detalles
de SKU que tienen para ese usuario.
Pero depende de su lógica.
Así que si solo invocan a querySkuDetails
cuando el usuario solicita
ver el producto, está bien.
Es una manera de mostrar
que pueden llamar a querySkuDetails
porque un cliente
de facturación está listo.

Chinese: 
设置监听器
在这个例子中，我们将自身activity
设置成监听器
但您可以使用您想用的任何类
或结构中的任何内容
然后进行编译
之后，只需开始连接
不存在intent名称
也没有权限名称，什么都没有
只需调用startConnection
此时，您需要替换onBillingSetupFinished
但不需要重试
我刚才说过
如果连接断开，您不需要重试
不过，建立连接后，您可能需要
调用querySkuDetails
从而列出该用户对应的所有SKU详情
这只是个例子
具体情况取决于您的逻辑
如果只在用户请求查看产品时
才调用querySkuDetails，那也无妨
这个例子只是为了向您展示
您可以调用
querySkuDetails，因为结算客户端
已准备就绪

Japanese: 
リスナーをセットします
この場合 自分のアクティビティがリスナーに
なります
やりたければ ストラクチャーの中で好きなクラスを
使えます
そして ビルドします
そのあと コネクションだけスタートします
インテントの名前も
パーミションの名前もありません
Start connectionを呼ぶだけです
ここでは自分のセットアップを
オーバーライドする必要があります
前にも言ったように
リトライする必要は
ありません
接続が切れても
リトライする必要はありません
接続後 
querySkuDetailsを
呼びたくなるかも知れません
そのユーザー用のSKU詳細を
リストすることもできます
あなたのロジック次第です
ユーザーが商品を見ようとしている場合に
querySkuDetailsを呼ぶだけなら
問題はありません
課金をするユーザーの
準備ができたので
querySkuDetailsを呼ぶことができる
ことを示しただけです
さて

Korean: 
여러분이 리스너를 설정합니다
이 경우 우리는 자체 액티비티는 리스너라고
말합니다
하지만 여러분이 원하는
어떤 클래스라도 사용할 수 있습니다
원한다면 스트럭처에 있는 
어떤 것이든 말이죠
그런 다음 빌드를 합니다
그 후에는 연결만 시작합니다
인텐트의 이름이 없습니다
권한의 이름도 없습니다
연결 시작을 호출하기만 하면 됩니다
여기서 여러분은 자체 결제
설정 완료를 재정의해야 합니다
다시 시도할 필요가 없습니다
제가 말씀드린 것처럼 말이죠
연결이 끊어진 경우
다시 시도할 필요가 없습니다
하지만 연결이 완료된 후에
querySkuDetails를 호출하고
싶어하실지도 모르겠습니다
해당 사용자에 대해 가진 모든
SKU 세부사항의 목록을
만들 수 있도록 말이죠
하지만 이는 여러분의 논리를 따릅니다
따라서 사용자가 제품 보기를 요청할 때만
querySkuDetails를 호출한다면
문제가 없습니다
이는 결제 클라이언트가
준비되었기 때문에
여러분이 querySkuDetails를
호출할 수 있다는 것을 보여주는
한 가지 방법에 불과합니다

Portuguese: 
Aqui é quando você cria PendingIntent
para chamar a Play Store.
Muito código, certo?
Vocês precisam lembrar do contexto,
receber o código de resposta do pacote...
Então, comparar com
um código que, nesse caso,
era uma constante na minha classe.
Vários códigos que se repetem a cada ação.
Aqui, ao usar Play Billing Library,
só há os parâmetros de compra.
Então, usar novamente o padrão
do builder, definir uma SKU,
definir o tipo, consolidar as SKUs,
no caso de upgrade
ou downgrade de uma assinatura.
Depois, iniciar um fluxo de faturamento.
Pronto.
Neste ponto, a Play Billing Library
chamará a Play Store, enviando
todos os parâmetros.
Quando ela volta, quando
sua compra é concluída,

Indonesian: 
Oke.
Dan di sini, misalnya, adalah saat Anda
membuat intent tertunda
sehingga Anda bisa memanggil Play Store.
Jadi sekumpulan kode, bukan?
Anda perlu membuat--
ingat konteksnya
Anda perlu mendapatkan--
kita memiliki kode respons dari paket.
Lalu Anda membandingkan dengan kode,
di kasus ini,
yang merupakan konstanta di class saya.
Sehingga sekumpulan kode boilerplate
yang hanya mengulangi
setiap tindakan yang Anda lakukan.
Jadi di sini, saat Anda memanggil
Library Layanan Penagihan Play,
Anda hanya memiliki-- Anda memiliki
parameter pembelian.
Jadi, lagi, menggunakan pola builder,
setSKU,
setType, tentukan SKU jika
Anda melakukan upgrade atau downgrade
pada langganan.
Lalu luncurkan alur penagihan.
Selesai.
Saat ini, Library Layanan Penagihan Play
akan memanggil Play Store
yang mengirimkan semua parameter.
Dan saat kembali,
saat pembelian Anda berhasil,

Japanese: 
たとえば ペンディングされたインテントを
作っている場合
プレイストアを呼ぶことができます
コードがたくさんですね？
生成するのは…
コンテクストを思い出してください
ゲットするのは…
バンドルからレスポンスコードを取ってきます
そして このケースでは
私のクラスではコンスタントだった
コードと比べます
実行するすべてのアクティビティを
繰返す定型コードです
ここでは プレイ課金ライブラリ使って
コールするときは
購入パラメータだけです
再び ビルダーパターンを使って
SKUをセットし
タイプをセットして
サブスクリプションでアップグレードか
ダウングレードをしている場合は
SKUを解決します
そして 課金フローを開始します
これでおわりです
この時点で 
プレイ課金ライブラリは
プレイストアをコールして
パラメータをすべて送ります
購入がうまくいって 戻ってくると

Korean: 
좋습니다
그리고 이것은 예를 들면,
Play Store를 호출할 수 있도록
펜딩 인텐트를 만들 때의 모습입니다
많은 코드가 있죠?
여러분은
컨텍스트를 기억해야 합니다
이 번들에 응답 코드가 있고
이를 내 클래스에서 상수였던 코드와
비교합니다
다량의 보일러플레이트 코드가
여러분이 수행하는 모든 작업을 반복합니다
따라서 Play 결제 라이브러리 사용을 요청할 때
여러분은 구매 params를 갖게 됩니다
따라서 빌더 패턴을 다시
사용하여 SKU를 설정하고
타입을 설정하고
구독에 대한 업그레이드나
다운그레이드를 실행할 경우에 대비하여
SKU를 정착시킵니다
그런 다음 결제 흐름을 실행합니다
그러면 다 된 것입니다
이때 Play 결제 라이브러리가
모든 매개변수를 전송하면서
Play Store를 호출할 것입니다
그리고 매개변수가 되돌아오면
구매에 성공한 것이고

Chinese: 
好
这个例子展示了
创建pendingIntent来调用Play商店的情况
又是一大段代码，是吧？
您需要
记住上下文
您需要
从软件包中获得响应代码
然后与另一个代码相比较，在本例中
比较的是一个类中的常量
这些样本代码会伴随您的每步操作
重复出现
在这个例子中，您使用Play结算库进行调用
就可以使用purchaseParams
同样，使用生成器模式，setSKU
setType，如果要升级
或降级订阅，还要setOldSKU
然后，launchBillingFlow
就完成了
这时，Play结算库
会调用Play商店发送所有参数
当它返回结果，购买已成功完成时

English: 
OK.
And here, for
example, is when you
are creating the pending intent
so you can call the Play Store.
So a bunch of code, right?
You need to create--
remember the context.
You need to get the--
we had the response
code from the bundle.
Then you compare with a
code that, in this case,
was a constant in my class.
So a bunch of boilerplate
code that it's just repeating
every act that you do.
So here, when you are calling
on using Play Billing Library,
you just have-- you have
the purchase params.
So using, again, the builder
pattern, so set a SKU,
set type, settle
the SKUs in case
you are doing an upgrade or
downgrade on a subscription.
And then launch a billing flow.
It's done.
At this moment, the
Play Billing Library
will call the Play Store
sending all the parameters.
And when it's back, when
your purchase has succeeded,

Spanish: 
Y aquí, por ejemplo, es cuando
crean el intent pendiente de modo
que pueden llamar a Google Play Store.
Mucho código, ¿no?
Tienen que crear…
recuerden el contexto.
Tienen que obtener la…
tenemos el código de respuesta
del paquete.
Después, lo comparan con un código que,
en este caso,
fue una constante en mi clase.
Un montón de código repetitivo
que simplemente repite todo lo que haces.
Aquí, cuando llaman o usan la Biblioteca
de Facturación Google Play,
tienen parámetros de compra.
Deben usar nuevamente el patrón
de compilación, establecer un SKU,
establecer un tipo y establecer los SKU,
en caso de pasar
a una suscripción de versión
superior o inferior.
Y después iniciar un flujo de facturación.
En este momento, la Biblioteca
de Facturación Google Play
llama a Play Store, que envía todos
los parámetros.
Y cuando está de vuelta, cuando la compra
se realizó correctamente,

Portuguese: 
o usuário gasta US$ 500 no seu app,
você tem que lidar com o resultado.
Isso é o que você precisa fazer na AIDL.
Receber o resultado da atividade,
testar o código de solicitação,
testar os dados, receber o código
de resposta, receber a string extra,
depois comparar tudo e executar uma ação.
Isso em todos os apps ou atividades
que interagem com a Play Store.
Agora, você só tem que
implementar o listener onPurchasesUpdated.
Recebe o código e usa a classe
BillingResponse para ver o status.
Nesse caso, está tudo certo.
Você tem o código para gerenciar a
compra, porque, neste momento,
talvez você queira fazer algo no app.
Por exemplo, adicionar esta moeda ao
inventário do usuário
ou ativar o acesso do
usuário a um recurso.
Neste ponto, está seu código
de acordo com sua lógica.
Imagine que o processamento da compra seja

Chinese: 
用户在您的应用中支付了500美元
您要需要处理结果
这里展示了使用AIDL时的做法
您需要接收activity结果，测试请求代码
测试数据，获取响应代码，获取extra字符串
然后比较方方面面，再采取行动
您需要对处理中的每个应用或与Play商店
交互的每个活动重复这些步骤
现在，您只需要实现这个监听器
onPurchaseUpdated
您收到了代码
现在可以使用BillingResponse类
来检查结果
在本例中，结果是OK
您可以根据这个代码来管理购买
因为这时
您可能想要在应用内执行一些操作
例如将金币加到用户的库存中
或为用户启用某个功能的访问权限
到这里，您可以根据自己的逻辑编码
可以想象成

Korean: 
사용자는 여러분의 앱에서
500달러를 지출하고
여러분은 결과를 처리해야 합니다
이것이 AIDL을 사용할 경우
여러분이 해야 할 일입니다
따라서 여러분은 활성 결과를 받고,
요청 코드를 테스트하고,
데이터를 테스트하고, 응답 코드를 받고,
스트링 엑스트라를 받고,
모든 것을 비교한 다음
조치를 취해야 합니다
여러분이 실행하는 모든 앱 또는
여러분이 Play Store와 상호작용하는
모든 액티비티에 대해 이처럼 해야 합니다
이제 구매 및 업데이트에 대해 이 리스너를
구현하면 됩니다
코드를 받았으므로 이제
결제 응답 클래스를 사용하여
이 탭을 확인할 수 있습니다
이 경우에는 괜찮네요
여러분은 구매를 관리할 코드를
가지고 있습니다
왜냐하면 지금은
여러분의 앱에서 어떤 작업을
수행하길 원하실 테니까요, 가령
코인을 사용자 인벤토리에 추가하거나
사용자가 기능에 액세스할 수
있도록 하는 등 말이죠
따라서 코드가
여러분의 로직을 따릅니다
따라서 이 구매 처리는

English: 
the user spend $500
in your app, then
you have to handle
the result. So here
is what you need to do
if you are using AIDL.
So you need to receive an active
result, test the request code,
test the data, get the response
code, get the string extra,
and then compare everything
and then take an action.
Like this you should do
for every app you are doing
or for every activity that you
interact with the Play Store.
Now you have only to
implement this listener
on purchase and update.
You received the code and now
I can use the billing response
class to check this tab.
So it's, in this case, OK.
You have the code to manage the
purchase because at this time
you have--
you maybe want to do something
in your app, for example,
add that coin to
the user inventory
or enable the user
access to a feature.
So at this point is your
code according to your logic.
So this handle
purchase imagine is

Spanish: 
el usuario gasta USD 500 en la app.
Después, tienen que procesar el resultado.
Esto es lo que tienen que hacer
si usan el AIDL.
Tienen que recibir un resultado activo,
probar el código de solicitud,
probar los datos, obtener el código
de respuesta, obtener el adicional de cadena
y, después, comparar todo y realizar
una acción.
Esto es lo que tienen que hacer
para cada app que desarrollan
o para cada actividad
que interactúa con Google Play Store.
Ahora, lo único que tienen que hacer
es implementar el objeto de escucha
en la compra y actualizar.
Recibieron el código y ahora se puede usar
la clase de respuesta de facturación
para comprobar esta pestaña.
En este caso, está bien.
Tienen el código para administrar
la compra porque en este momento
tienen…
tal vez quieran hacer algo en la app,
como agregar esa moneda
al inventario del usuario
o permitir que acceda a una función.
En este punto, es su código en función
de su lógica.
Imagínense que este manejo
de compra corresponde a su lógica,

Indonesian: 
pengguna telah menghabiskan $500
di aplikasi Anda,
lalu Anda harus menangani hasilnya.
Jadi di sini adalah hal 
yang perlu Anda lakukan
jika menggunakan AIDL.
Jadi Anda perlu menerima hasil aktif,
menguji kode permintaan,
menguji data, mendapatkan kode respons,
mendapatkan string ekstra,
lalu membandingkan semuanya
dan mengambil tindakan.
Seperti ini Anda seharusnya melakukannya
untuk setiap aplikasi yang Anda tangani
atau setiap interaksi aktivitas Anda
dengan Play Store.
Sekarang Anda hanya
harus mengimplementasikan pemroses ini
pada pembelian dan update.
Anda menerima kode dan sekarang
saya bisa menggunakan 
class respons penagihan
untuk memeriksa tab ini.
Jadi, di kasus ini, ini tidak apa-apa.
Anda memiliki kode untuk mengelola
pembelian karena saat ini
Anda memiliki--
Anda mungkin ingin melakukan sesuatu
di aplikasi Anda, misalnya,
tambahkan koin itu ke inventaris pengguna
atau aktifkan akses pengguna ke fitur.
Jadi di sini adalah kode sesuai
dengan logika Anda.
Jadi bayangkan handlePurchase
ini adalah logika Anda,

Japanese: 
ユーザーは あなたのアプリ内で
500ドル使って
その結果を処理する必要があります
これは AIDLを使った場合に
行う必要があることです
アクティブなリザルトを受け取って
リクエストコードを渡して
データを渡して レスポンスコードをゲットし
ストリングエクストラをゲットし
すべてを比較して
アクションをおこします
このようなことをすべてのアプリまたは
プレイストアとインタラクトしている
すべてのアクティビティに対して行う必要があります
今なら 購入やアップデートに
リスナーをインプリメントするだけです
コードを受け取ったら
課金レスポンスクラスを使って
ステータスをチェックします
この場合は問題ありません
購入を管理するコードがあります
その理由は 今回は
自分のアプリで
たとえば
コインをユーザーインベントリーに加えたり
ユーザーがフィーチャーにアクセスできるように
しようとするからです
この時点で コードはロジックに沿った
ものだとします
これで購入を扱います
このビジネスロジックで

Korean: 
여러분의 로직, 즉
사용자 구매를 처리하기 위한 비즈니스 로직입니다
그리고 결과 코드가 취소되면
무슨 일이 발생했는지
왜 취소하는지에 대해 의문이 들 수 있습니다
또는 앱을 확인할 수 있습니다
따라서 구현을 훨씬 분명하게 볼 수 있으며
훨씬 편리합니다
왜냐하면 제 생각에
좋은 코드란
쉽게 읽을 수 있는 코드이기 때문입니다
따라서 이것들은
AIDL의 많은 보일러플레이트 코드와
비교할 때 훨씬 좋은 코드입니다
구현 체크리스트를 살펴보겠습니다
Play 결제 라이브러리와 
Play 결제 서비스에
도입되는 새로운 특징인데,
모든 구매를 확인해야 합니다
이것은 사기를 방지하고
Play 결제의 오용을
방지하기 위한 것입니다
따라서 모든 구매가
여러분의 앱에서 확인되어야 합니다
Android 앱에 있는
여러분의 앱을 통해서도 확인될 수 있고
서버 측을 통해서도 확인될 수 있습니다

Portuguese: 
sua lógica de negócio
para processar a compra do usuário.
Se o código do resultado é "CANCELED",
você pode ver o que aconteceu.
Se for só um erro,
é possível conferir aqui.
A implementação fica muito mais clara.
Muito mais amigável porque,
na minha opinião,
um bom código é aquele
que você lê com facilidade.
Esses são códigos muito melhores
que as repetições da AIDL.
Agora, a lista de verificação
da implementação.
A primeira novidade a Play Billing Library
e do Play Faturamento em geral
é confirmar todas as compras.
Isso é para evitar fraudes
e uso indevido do Play Faturamento.
Todas as compras precisam ser
confirmadas pelo seu app.
Isso pode ser feito
no app para Android ou no servidor.

Spanish: 
su lógica comercial
para manejar la compra de un usuario.
Y si el código de resultado es cancelar,
pueden decir:
“¿Qué ocurrió? ¿Por qué cancela?”
O si es solo una app o algo,
se puede comprobar aquí.
Es mucho más claro de ver, ¿cierto?
La implementación.
Mucho más ameno porque, en mi opinión,
el buen código es un código que
se puede leer con facilidad, ¿verdad?
Este código es mucho mejor
si lo comparan con el montón de código
repetitivo del AIDL, ¿cierto?
Pasemos a la lista de verificación
de la implementación.
La primera novedad en la Biblioteca
de Facturación Google Play,
para el servicio en general,
es reconocer todas las compras.
Esto es para prevenir fraudes
y el uso indebido
de la Facturación Google Play.
La app tiene que reconocer
todas las compras.
Se puede hacer en la app de Android
o mediante el servidor.

Chinese: 
按照您的业务逻辑来处理用户购买交易
如果结果代码是“Canceled”，您可以问
怎么回事？
为什么要取消？
如果是因为出错了，您也可以在这里查看
所以，实现过程更加清晰
更加友好
好的代码应该读起来很轻松
这些代码要比
AIDL的一堆样本代码好得多
下面说说实现检查清单
首先，Play结算库
和整个Play结算服务新增了一个环节
确认所有购买交易
这是为了防止欺诈
防止滥用Play结算服务
每次购买必须得到应用的确认
这可以在Android应用中执行
也可以在服务器端完成

Indonesian: 
logika bisnis Anda
untuk menangani pembelian pengguna.
Dan jika resultCode adalah Canceled,
Anda bisa berkata, hei, apa yang terjadi?
Mengapa Anda membatalkan?
Atau hanya aplikasi atau yang lainnya,
Anda bisa memeriksanya di sana.
Jauh lebih jelas untuk melihat
implementasi, bukan?
Jauh lebih bersahabat,
karena menurut saya,
kode yang bagus adalah kode
yang dapat Anda baca dengan mudah, bukan?
Sehingga ini adalah kode 
yang jauh lebih baik
jika dibandingkan dengan sekumpulan
kode boilerplate AIDL, bukan?
Sehingga inilah
kotak centang implementasi.
Hal pertama yang cukup baru di 
Library Layanan Penagihan Play,
di Layanan Penagihan Play secara umum,
adalah mengonfirmasi semua pembelian.
Jadi ini untuk mencegah penipuan,
untuk mencegah
penyalahgunaan Layanan Penagihan Play.
Sehingga setiap pembelian
harus dikonfirmasi oleh aplikasi Anda.
Ini bisa dilakukan melalui aplikasi Anda
di aplikasi Android,
atau juga melalui sisi server.

English: 
your logic, your business logic
for handling the user purchase.
And if the result code is
cancel, so you can say,
hey, what happened?
Why you are canceling?
Or just an app or something,
you can check there.
So much more clear to see,
right, implementation?
Much more friendly,
because in my opinion,
good code is a code that
you can read easily, right?
So these are much
better code than
if you compare to AIDL bunch
of boilerplate code, right?
So implementation checklist.
First thing that it's kind
of new to the Play Billing
Library, to the Play
Billing service in general,
acknowledge all purchase.
So this is to prevent
frauds, to prevent
misuse of the Play Billing.
So every purchase must be
acknowledged by your app.
It can be done through your
app in the Android app,
or also through the server side.

Japanese: 
ユーザーの購入を処理するとします
リザルトコードがキャンセルされると
何が起こったんだろう？
キャンセルの理由は？
その時点でチェックします
もっと分かりやすくすると…
実装ですか？
ずっとフレンドリです
なぜなら 私の意見では
良いコードと言うのは
読みやすいコードだからです
なので このコードは
定型コードだらけのAIDLと比べると
ずっと良いコードです
インプリメンテーションのチェックリストです
まず プレイ課金ライブラリあるいは
プレイ課金サービスでは
初めてですが
すべての購入を確認します
これは 詐欺を防ぐ目的です
プレイ課金の誤使用を
防ぐためのものです
購入はすべて アプリで
確認する必要があります
自分のアプリで行うか
あるいは
サーバー側で行えます

Korean: 
따라서 클라이언트 측과
서버 측 모두에서 호출이 발생합니다
3일 이내에 구매를 확인하지 않으면
구매는 자동으로 환불됩니다
따라서 소비성 제품인 경우--
소비성 제품이란 무엇일까요?
소비성 제품은 예를 들어
게임에서의 코인과 같은 것입니다
여러 번 구매를 해야 합니다
그렇죠?
Google Play에서는
제품을 관리하여
사용자가 동기화된 제품을
두 번 구매하는 것을 허용하지 않습니다
다시 판매를 하기 전에
제품을 소비해야만 합니다
따라서 이런 경우, 제품을 소비할 때
동시에 구매를 확인하게 됩니다
왜냐하면 실제로 받지도 않은 것을
소비할 수는 없으니까요
그렇죠?
하지만 소비성 제품이 아닌
프리미엄 환경 또는 구독을 판매한다고
상상해 보세요
이 경우 구매를 확인해야 합니다
그렇지 않으면
3일 후에 환불을 받게 됩니다
오용을 방지해야 합니다
일반적으로

Spanish: 
Podemos manejar las llamadas
tanto en el cliente como en el servidor.
Si no se reconoce la compra en tres días,
se reembolsa automáticamente.
Si se trata de un producto de consumo…
¿Qué es un producto de consumo?
Son, por ejemplo, las monedas de un juego.
Productos que tendrían
que comprar varias veces, ¿no?
Dado que estos productos
de Google Play se administran
y Google Play no permite que el usuario
compre dos veces un producto sincronizado,
debes consumir el producto
antes de volver a venderlo.
En este caso,
cuando se consume un producto,
al mismo tiempo se reconoce la compra,
porque no se puede simplemente
consumir algo que se recibió.
Pero si no es un producto de consumo…
Imagínense que venden una experiencia
o una suscripción premium.
En estos casos, deben reconocer la compra
sino tendrán un reembolso en tres días.
Eviten los abusos.

Portuguese: 
Temos as chamadas no
cliente e no servidor.
As compras não confirmadas em três dias
são canceladas automaticamente.
Se for um produto de consumo...
O que é um produto de consumo?
É algo como moedas em um jogo.
Você tem que comprar várias vezes.
Como os produtos no Google Play
são gerenciados,
o usuário não pode
comprar o mesmo produto duas vezes.
Então, você tem que consumir o produto
antes de vender novamente.
Assim, quando você consome um produto,
está, ao mesmo tempo, 
confirmando a compra,
porque você não pode consumir
algo que realmente não recebeu.
Mas se o produto não é de consumo...
imagine que você venda
uma experiência premium ou assinatura...
Nesse caso, você precisa
confirmar a compra.
Caso contrário, haverá
um reembolso em três dias.
Evite o abuso.

Indonesian: 
Sehingga kita memiliki panggilan
baik di klien dan sisi server.
Jika Anda tidak mengonfirmasi pembelian
dalam tiga hari,
dana pembelian secara otomatis
dikembalikan.
Jika itu adalah
produk yang dapat dikonsumsi--
apa itu produk yang dapat dikonsumsi?
Produk yang dapat dikonsumsi, 
misalnya, koin dalam game.
Jadi Anda harus membeli--
Anda seharusnya membeli berulang kali,
bukan?
Jadi karena produk di Google Play
dikelola--
jadi Google Play
tidak akan mengizinkan pengguna
untuk membeli produk
yang disinkronkan dua kali,
Anda harus menggunakan produk
sebelum menjualnya lagi.
Jadi di kasus ini, 
saat Anda menggunakan produk,
Anda juga mengonfirmasi
pembelian tersebut,
karena Anda tidak bisa menggunakan sesuatu
yang memang Anda terima, bukan?
Tetapi jika itu bukanlah
produk yang dapat dikonsumsi--
bayangkan Anda sedang menjual
pengalaman premium
atau langganan--
di kasus ini, Anda harus mengonfirmasi
pembelian.
Jika tidak, Anda akan mengalami
pengembalian dana dalam tiga hari.
Hindari penyalahgunaan.

English: 
So we have the calls both in
client and the server side.
If you don't acknowledge
that purchase in three days,
the purchase is
automatically refunded.
So if it's a
consumable product--
what is a consumable product?
Consumable product like, for
example, coins in a game.
So you have to purchase-- you
should purchase many times,
right?
So since products in
Google Play are managed--
so Google Play
won't allow the user
to purchase a synced
product twice,
you must consume the product
before selling again.
So in this case, when
you consume a product,
you are at that same time
acknowledging the purchase,
because you just can't consume
something that you really
received, right?
But if it's not a
consumable product--
imagine you are selling
a premium experience
or a subscription--
in this case, you most
acknowledge the purchase.
So otherwise, you're going to
have a refund in three days.
Avoid abuse.

Japanese: 
クライアントとサーバーの両方で
コールできます
購入を3日以内に確認しなければ
自動的に返金されます
消耗品の場合
消耗品って？
たとえばゲームで使うコインなどです
何回も買うようなものです
Google Play内の商品は
管理されているので
Google Playはユーザーが
同期した製品を2回買えないように
していて
ユーザーは売る前に
消費しなければなりません
この場合 商品を消費するとき
それと同じタイミングで
購入を確認することになります
なぜなら実際に受け取ったものは
消費できないからです
いいですか？
消耗品でない場合
プレミアエクスペリエンスや
サブスクリプションを
売ろうとしているとすると
この場合 購入を確認する
必要があります
確認しなければ3日以内に
払い戻しをうけます
悪用を避けます

Chinese: 
在客户端和服务器端都可以调用
如果购买交易在三天内未得到确认
该交易就会自动退款
如果是消耗型商品
什么是消耗型商品？
比如，游戏中的金币就是消耗型商品
您需要多次购买
对吧？
由于Google Play会管理这些商品
它不会允许用户
购买已同步的商品两次
您必须先消耗该商品，才能再次销售
在这种情况下，当您消耗商品时
同时也就确认了购买交易
因为您只能消耗已收到的
商品，对吧？
但如果它不是消耗型商品
假设您在出售高级体验
或者订阅服务
在这种情况下，您必须确认购买交易
否则三天后将退款
下面说防止滥用

Chinese: 
通常，我们需要
验证购买交易和签名
我们建议您在服务器端执行该操作
尽管并不是所有应用都有服务器端
或可以实现这样的用户体验
但这是防止滥用的一种方法
因为您可以验证接收情况
另外，还可以针对订阅使用开发者通知
接下来是移除负载
在上一个版本中，大家就要求我们
选择开发者有效负载
开发者有效负载是一个任意字符串
您可以把它附加到购买流程，然后
稍后查看
问题是，很多人把它用作
安全验证
这并不是正确的用法
因为它可能被当作攻击而被拦截
还很容易
遭遇逆向工程

Indonesian: 
Jadi umumnya kita perlu, misalnya,
memvalidasi pembelian, 
tanda tangan, kami merekomendasikan
Anda untuk menggunakan
sisi server untuk melakukannya.
Saya tahu bahwa terkadang 
tidak semua orang memungkinkan
untuk memiliki sisi server atau 
pengalaman pelanggan seperti itu.
Tetapi itu adalah cara
menghindari penyalahgunaan,
karena Anda dapat
memvalidasi tanda terimanya.
Dan gunakan juga notifikasi 
developer untuk langganan.
Dan hapus payload.
Hal yang orang tanyakan kepada
kami di versi sebelumnya
adalah memilih payload developer.
Payload developer adalah string arbitrer.
Anda dapat menambahkan alur pembelian
yang dapat 
Anda periksa nanti dengan itu.
Masalahnya adalah, 
banyak orang menggunakannya
sebagai validasi keamanan.
Dan ini adalah penggunaan 
yang tidak tepat
karena bisa dicegat 
seperti menghadapinya dalam serangan,
dan bisa saja sangat mudah--
seperti, merekayasanya balik.

English: 
So we know that in general
we need, for example,
to validate a purchase,
a signature, what
we recommend is that you use
a server side to do that.
I know that sometimes it's
not possible for everybody
to have a server side or a
customer experience like that.
But it's a way to avoid
abuse, because then you
can validate the receipt.
And use also your developer
notification for subscriptions.
And remove payloads.
Something that people asked
us in the previous version
is choose developer payload.
Developer payload is
an arbitrary string.
You can add should the purchase
flow that you can check later
with that.
The problem is, many
people were using
that as a security validation.
And this is not a
correct use because it
can be intercepted like
meeting them in attack,
and can be very easy--
like, reverse engineer it.

Portuguese: 
Sabemos que, em geral, é necessário
validar uma compra ou assinatura.
Recomendamos que vocês usem
um servidor para fazer isso.
Sei que, às vezes, nem todos podem
ter um servidor ou uma experiência
de cliente como essa.
Mas é uma forma de evitar abuso,
porque vocês podem validar o recebimento.
Use também a notificação do seu
desenvolvedor para assinaturas.
E remova payloads.
Um pedido da versão anterior
foi escolher o payload do desenvolvedor.
Isso é uma string arbitrária que
você pode adicionar ao fluxo de compra
para fazer verificações depois.
O problema é que muitas
pessoas estavam usando isso
como uma validação de segurança.
Esse uso não é correto, porque
ele pode ser interceptado em um ataque
e usado em
engenharia reversa com facilidade.

Korean: 
구매나 서명을 검증할 필요가 있는데
우리가 권장하는 것은 
서버 측을 사용하여 그렇게 하라는 것입니다
저는 모두가 서버 측이나
그와 같은 고객 환경을 갖는 것이
불가능하다는 것을 알고 있습니다
하지만 이를 통해
오용을 방지할 수 있습니다
왜냐하면 수령 여부를
확인할 수 있기 때문입니다
또한 구독에 대해
개발자 알림을 사용하세요
그리고 페이로드를 제거하세요
이전 버전에서 사람들이
Google에 요청한 것 중의 하나는
개발자 페이로드를 선택하라는 것입니다
개발자 페이로드는 임의 문자열입니다
구매 흐름에 추가하여 나중에 확인할 수
있습니다
문제는 많은 사람들이
이것을 보안 인증으로 사용했다는 것입니다
그리고 이는 올바른 사용이 아닙니다
왜냐하면
공격 중에 만나는 것과 같이
가로채일 수가 있고
리버스 엔지니어링하기가
매우 쉽기 때문입니다

Japanese: 
一般的に
購入の確認が必要で
サインとか
お勧めの方法は
サーバー側でやることです
サーバー側でできないことがあるのは
理解しています
カスタマーエクスペリエンスです
これは悪用を避ける方法です
なぜなら
受けとったことが検証できるからです
サブスクリプションには
デベロッパー通知も使えます
ペイロードをなくします
前のバージョンでみなさんに
頼まれたことは
デベロッパーのペイロードを
選ぶことでした
デベロッパーペイロードは
任意のストリングです
購入のフローに加えることができ
あとでチェックできます
問題は
たくさんの人がセキュリティの検証に
使っていることです
これは正しい使い方では
ありません
攻撃にあったときに
インターセプトされる可能性があるからです
リバースエンジニアリングで簡単に
できてしまいます

Spanish: 
Sabemos que, en general,
necesitamos, por ejemplo,
validar una compra o una firma.
Nuestra recomendación es que usen
un servidor para hacerlo.
Sé que, a veces, no todos pueden tener
un servidor o una experiencia
de cliente de ese tipo.
Pero es una manera de evitar el abuso,
porque pueden validar el recibo.
Y también usar la notificación
para desarrolladores en las suscripciones
y eliminar las cargas útiles.
Algo que nos pidieron en la versión anterior
es elegir la carga útil del desarrollador,
que es una string arbitraria
que se puede agregar al flujo de compra
para revisarlo más tarde.
El problema es que muchas personas
usaban esto como validación de seguridad.
Y ese uso no es correcto
porque se puede interceptar,
como en un ataque de intermediario
y es fácil aplicar ingeniería inversa.

English: 
So in the first version, we
didn't support the payload.
But it's now required
by the other features.
So we, in the Play
Billing Library 2.0,
you have the developer payload.
But please, don't use the
developer payload unless it's
really necessary for you.
Try to use another mechanism
to validate or to integrate
the purchase.
So some other things that
not specifically related
to the purchase specifically,
on-time purchase,
but real-time
developer notification.
This is a way to
receive notification
about any event related
to subscriptions.
So this is very good
because then you
can receive real-time updates
about cancelations, about
new subscriptions, upgrade,
grace period, and account hold
events.
So basically also
you reduce your usage
for the Google
Play Developer API.

Korean: 
따라서 첫 버전에서 Google은
페이로드를 지원하지 않았습니다
하지만 지금은 다른 기능에서 
이를 필요로 하고 있습니다
따라서 Play 결제 라이브러리 2.0에서
여러분은 개발자 페이로드를 갖게 됩니다
하지만 정말 필요한 경우가 아니라면
개발자 페이로드를 사용하지
마시기 바랍니다
다른 메커니즘을 사용하여
구매를 인증하거나
통합하세요
정기적 구매와 특별히 관련되지 않은
다른 것으로는
실시간 개발자 알림이 있습니다
이 방식을 통해서 구독과 관련된
모든 이벤트에 대한 알림을 받게 됩니다
이것은 매우 유용한데, 그 이유는
취소, 새로운 구독, 업그레이드,
유예 기간 및 계정 중지 이벤트에 대한
실시간 업데이트를 받을 수 있기
때문입니다
따라서 기본적으로 Google
Play Developer API에 대한 사용량도
줄어들게 됩니다

Spanish: 
En la primera versión, no admitíamos
la carga útil del desarrollador.
Pero ahora lo requieren
las otras funciones.
Así que en la Biblioteca
de Facturación Google Play 2.0,
tienen la carga útil.
Pero, por favor, no la usen
a menos que sea realmente necesario.
Intenten usar otro mecanismo
para validar la compra o para integrarla.
Otros aspectos que no se relacionan
específicamente con la compra puntual,
sino con la notificación del desarrollador
en tiempo real,
tratan sobre recibir notificaciones
de los eventos
relacionados con suscripciones.
Esto es muy bueno porque pueden recibir
actualizaciones en tiempo real
sobre cancelaciones, suscripciones nuevas,
actualizaciones a versiones superiores,
períodos de gracia
y suspensiones de cuenta.
También reducen el uso de la API
de desarrolladores de Google Play.

Indonesian: 
Jadi di versi pertama, kami 
tidak mendukung payload.
Tetapi, ini sekarang diperlukan
oleh fitur lainnya.
Jadi di Library Layanan
Penagihan Play 2.0,
Anda memiliki payload developer.
Tetapi tolong, jangan gunakan 
payload developer
kecuali Anda sangat membutuhkannya.
Gunakan mekanisme lain untuk 
memvalidasikan atau mengintegrasikan
pembelian.
Beberapa hal lain yang 
tidak berhubungan khusus
dengan pembelian, 
pembelian tepat waktu,
tetapi notifikasi developer real-time.
Ini adalah cara untuk menerima notifikasi
tentang setiap peristiwa yang berhubungan 
dengan langganan.
Hal ini sangat bagus
karena Anda dapat menerima update 
real-time tentang peristiwa pembatalan,
langganan baru, upgrade, 
masa tenggang, dan penangguhan akun.
Pada dasarnya Anda juga
mengurangi penggunaan
untuk Google Play Developer API.

Portuguese: 
Na primeira versão, não havia
compatibilidade com payload.
Agora, isso é exigido
pelos outros recursos.
Na Play Billing Library 2.0,
você tem o payload do desenvolvedor.
Mas não usem esse payload
se não for muito necessário.
Tentem usar outro mecanismo
para validar ou integrar a compra.
Há outras coisas que não estão
especificamente relacionadas
a compras únicas,
mas notificações em tempo real.
Essa é uma maneira de receber notificações
sobre qualquer evento
relacionado a assinaturas.
Isso é muito bom, porque é possível
receber atualizações em tempo
real sobre cancelamentos,
novas assinaturas, upgrades,
período de carência e suspensão de conta.
Basicamente, você também reduz o uso
da API Google Play Developer.

Japanese: 
そんなわけで 最初のバージョンでは
ペイロードをサポートしていませんでした
しかし 現在ではほかのフィーチャーでも
必要とされています
そこでプレイ課金ライブラリ2.0では
デベロッパーペイロードが用意されています
でも 本当に必要なとき以外は
デベロッパーペイロードは使わないでください
購入を確認したりまとめたりするには
別のメカニズムを使ってください
購入に特に関係しないこととして
オンタイムの購入に関係しないこととして
リアルタイムのデベロッパー通知があります
これはサブスクリプションに関連する
すべてのイベントの通知を
受ける方法です
これはとてもいい方法です
キャンセルや新規のサブスクリプションや
アップグレード
猶予期間 アカウントホールドイベントなど
リアルタイムのアップデートを
受けられます
基本的には
グーグルデベロッパーAPIの使用を
減らします

Chinese: 
因此在第一版中，我们不支持该负载
但是现在，其他一些功能必须使用该负载
因此，在Play结算库2.0中
可以选择开发者有效负载
但是，除非真正必要
否则请勿使用
请使用其他机制来验证或集成
购买交易
接下来的内容
不是专门针对购买交易的
这就是实时开发者通知
通过这种方式可以接收
与订阅相关的任何事件的通知
这个功能很好，因为您可以
接收有关取消、新订阅
升级、宽限期和帐号保留事件
的实时更新
这可以减少
对Google Play Developer API的使用

Spanish: 
Y esto es algo que, por ejemplo…
Hemos visto a muchos socios,
muchas apps con problemas,
que comprueban todo el tiempo
la API de desarrolladores de Google Play.
Y cuando tienen un aumento,
un uso importante,
como un anuncio en los medios,
algo así, se quedan sin cuota
porque realizan la solicitud
para cada compra nueva.
Y, a veces, se puede agotar la cuota.
Y eso es algo
que podemos hacer por ustedes.
Tienen que contactarse con Google,
tienen que incrementar la cuota.
A veces, lleva tiempo
porque es un proceso manual.
Así que si usan estas notificaciones
en tiempo real,
no tienen que ir
y revisar nuestro servidor.
Pueden recibir la notificación
y hacerlo ustedes mismos.
Y así no se exceden de la cuota.
Este es un pequeño resumen,
digamos, del flujo.
Cuando cambia un estado
o una suscripción nuevos…
Supongamos que el usuario
tiene un problema con su tarjeta de crédito
y entra en modo de suspensión de cuenta
y de período de gracia…

English: 
And this is something
that, for example, we've
seen many partners, many apps
having problem, for example,
checking all the time the
Google Play Developer API.
And when they have a spike,
a big usage like a media
announcement, something like
that, they run out of quota
because they keep doing the
request for every new purchase.
And sometimes it can
be run out of quota.
And that's something that
we can do much for you
because then you need to
get in contact with Google.
Then you need to
increase the quota.
Sometimes it takes time,
because it's a manual process.
So if you use real-time
developer notification,
you don't need to go
and poll our server.
So you can just
receive notification
and do by yourself.
And then they stay under quota.
So for example, here is,
like, little bit a summary
of the flow.
So when a new subs
or status change--
so for example, the user has a
problem with their credit card,
so it enters in the account
hold mode and the grace period
mode--

Japanese: 
これはたとえば
多くのパートナー 多くのアプリが
グーグルプレイデベロッパーAPIを
いつもチェックして
メディア発表などで一時的にアクセスが
集中してしまうようなことがあると
クオータがオーバーしてしまいます
新しい購入すべてが
リクエストを出し続けるからです
クオータがなくなってしまうこともあります
そのような場合
グーグルに連絡する必要があるので
私達がおおいにお役に立てます
クオータを増やす必要があります
これはマニュアルのプロセスなので
時間がかかります
リアルタイムのデベロッパー通知を
使えば
サーバーまで行って
問い合わせる必要はありません
通知を受けて
自分で処理するだけです
クオータをオーバーすることはありません
フローの概要をここに示します
ステータスに変更があると
たとえば ユーザーのクレジットカードで
問題が起こった場合
アカウントホールド モードとなり
猶予期間モードに入り

Korean: 
또한 저희는
많은 파트너들, 많은 앱에
Google Play Developer API를 항상 확인하는
문제가 있음을 목격했습니다
미디어 발표를 할 때처럼
사용량이 매우 크게 증가할 때
할당량이 소진됩니다
왜냐하면
모든 새로운 구매에 대한
요청이 지속되기 때문입니다
때로는 할당량이 소진될 수 있습니다
바로 이때 Google에서
여러분을 도울 수 있습니다
왜냐하면 여러분이 
Google에 연락을 취하고
할당량을 늘려야 하기 때문이죠
때로 이 작업은 시간이 걸립니다
왜냐하면 수동으로 처리되기 때문입니다
따라서 실시간 개발자
알림을 사용하시는 경우
Google 서버를 폴링할 필요가 없습니다
알림을 받고
여러분 스스로 작업을 수행하면 됩니다
그러면 사용량이 할당량 아래로 유지됩니다
따라서 예를 들어
흐름을 조금만 요약하자면
새로운 구독이 발생하거나
상태가 변경될 때
예를 들어 사용자가
신용카드에 문제가 있는 경우
계정 중지 모드 및 유예 기간 모드로
들어가게 됩니다

Portuguese: 
Isso é algo que...
por exemplo, temos visto muitos parceiros
e apps com problemas, como
verificar a API o tempo todo.
Quando eles têm um aumento,
um grande uso, como um anúncio
na mídia, algo assim, eles ficam sem cota,
porque continuam fazendo a
solicitação para cada nova compra.
Às vezes, eles podem ficar sem cota.
E isso é algo que podemos fazer para você,
porque vocês precisam
contatar o Google.
Vocês precisam aumentar a cota.
Às vezes, isso leva tempo, 
porque o processo é manual.
Se você vê uma notificação em tempo real,
não precisa pesquisar nosso servidor.
Basta receber uma notificação
e fazer você mesmo.
Assim, é possível ficar abaixo da cota.
Por exemplo, aqui está
um pequeno resumo do fluxo.
Quando há uma nova assinatura
ou quando um status muda...
Por exemplo, o usuário
tem um problema com o cartão
e entra no modo de suspensão da conta
e no período de carência...

Chinese: 
很多合作伙伴、应用
都存在这方面的问题
他们需要时时检查Google Play Developer API
当出现峰值时，例如发布媒体公告等
大规模使用情况，就会用尽配额
因为他们要针对每个新的购买交易不断发送请求
有时就会用尽配额
这时就需要我们的帮助
因为您需要与Google联系
需要增加配额
有时这很耗时，因为过程是手动的
如果使用实时开发者通知
就不需要去轮询我们的服务器
可以直接接收通知
并自行处理
配额就不会用尽
下面总结一下
这个流程
如果有新的订阅或者状态更改
比如，用户的信用卡出现问题
因此进入帐号保留模式和宽限期
模式

Indonesian: 
Dan ini adalah sesuatu yang, misalnya,
kita telah melihat banyak partner, banyak 
aplikasi mengalami masalah, misalnya,
selalu memeriksa
Google Play Developer API.
Dan saat mereka memiliki lonjakan, 
penggunaan besar seperti pengumuman
media, semacam itu,
mereka kehabisan kuota karena
mereka terus melakukan 
permintaan untuk setiap pembelian baru.
Dan terkadang ini dapat kehabisan kuota.
Dan itu adalah hal yang dapat 
kami lakukan untuk Anda
sehingga Anda perlu
menghubungi Google.
Lalu Anda perlu meningkatkan kuota.
Terkadang ini akan memakan waktu, 
karena ini adalah proses manual.
Jika Anda menggunakan
notifikasi developer real-time,
Anda tidak perlu 
melakukan pemeriksaan server kami.
Anda hanya menerima notifikasi
dan melakukannya sendiri.
Lalu mereka tidak akan melebihi kuota.
Misalnya, di sini, seperti, 
sedikit ringkasan alurnya.
Saat sub baru 
atau perubahan status -- misalnya,
pengguna memiliki masalah 
dengan kartu kredit mereka,
sehingga rekening akan memasuki 
mode penangguhan akun
dan mode masa tenggang--

Chinese: 
您应该知道发生了这件事，然后发送一条消息
”您好，您在处理付款时遇到问题
要不要检查并重试？“
这可以大大减少应用的
客户非自愿流失
通过这种方式可以主动赢回用户，对不对？
发生事件时，Play商店会使用
PubSub主题发送一条推送
PubSub是Google Cloud Platform的一款产品
不用担心
您可以使用免费配额
处理Play结算通知完全够用
当然，如果您想使用该产品
我们也十分欢迎您尝试
PubSub是用于消息通信的
一款出色产品
注册这个主题后
通过这条信息消费该主题
之后，您会发现

Korean: 
여러분은 이러한 일이 발생한 것을 알게 되며
Google에서는 메시지를 보냅니다
지불을 처리하는 데 문제가 발생했으니
확인하고 다시 시도하겠느냐고 말이죠
이렇게 하면 앱에서
비자발적인 이탈이 발생하는 것을
크게 줄일 수 있습니다
이렇게 하여 적극적으로 사용자를
되찾아올 수 있습니다
그런 다음 어떤 일이 발생하면
Play Store에서 
PubSub 주제를 사용하여 푸시를 보냅니다
PubSub는
Google Cloud Platform 제품입니다
하지만 걱정하지 마세요
여러분에게는 사용할 수 있는
무료 할당량이 있으며
이는 Play 결제 알림용으로 충분합니다
원한다면 한 번 사용해 보실 것을
권합니다
PubSub는 메시징을 위한 통신에
유용한 제품입니다
여러분은 이 주제에 등록되어 있습니다
따라서 이 메시지를 통해
주제를 소비합니다
이를 소비한 후에는

Japanese: 
そうなったことを知らせるのに
メッセージが送られます
支払い処理で問題が生じていますよ
チェックして
もう一度試しますか？
こうすれば
アプリの負担をかなり
軽減できます
ユーザーを積極的に取り戻す方法に
なりますね？
何か起これば
プレイストアがPubSubトピックを使って
プッシュを送ってきます
PubSubはGoogle Cloud Platform
の製品です
心配はいりません
無料で使えるクオータがあって
プレイ課金の通知には十分な容量です
もちろん 容量を増やしていただいても結構です
PubSubはメッセージングには
すばらしい製品です
このトピックで登録されています
このメッセージでこのトピックが
コンシュームできます
それをコンシュームしたあと

English: 
you should know that it happens
so we can send a message.
Hey, you're having problems
should process your payment.
Like to check this
and try again?
So this can reduce the
involuntary churn a lot
in your app.
So it's a way that you actively
win back your user, right?
Then when something
happens, that Play Store
will send a push using
the PubSub topic.
It's a-- PubSub is a Google
Cloud Platform product.
But don't worry.
You have free quota to
use, like the free quota
is totally enough for the
Play Billing notification.
Of course, if you
want to use, you're
more than welcome to try.
The PubSub is a great
product for communication
for messaging.
But then you are
registered to this topic.
So you consume this
topic with this message.
And after you consume that
you can say, OK, these--

Spanish: 
Tienen que saber que esto ocurre
para que podamos enviar un mensaje:
"Hay un problema para procesar el pago.
¿Desea verificarlo y volver a intentarlo?".
Esto puede reducir mucho
las bajas involuntarias en la app.
Es una manera de recuperar
activamente a los usuarios.
Entonces, cuando pase algo,
Play Store enviará una notificación push
con el tema de Pub/Sub.
Pub/Sub es un producto
de Google Cloud Platform.
Pero no se preocupen.
Tienen cuota de uso libre,
que es suficiente para la notificación
de la Facturación Google Play.
Por supuesto, si quieren usarlo,
son más que bienvenidos a probarlo.
Pub/Sub es un producto excelente
para las comunicaciones
mediante mensajería.
Pero quedan registrados en este tema.
Y consumen el tema con este mensaje.
Y después de ese consumo,
pueden decir:

Portuguese: 
Isso acontece,
então podemos mandar uma mensagem:
"Estamos tendo problemas
com o processamento do seu pagamento.
Por favor, verifique e tente novamente."
Isso pode reduzir bastante
o desligamento involuntário de usuários.
É uma forma de reconquistar
ativamente o usuário.
Quando algo acontece, a Play Store
envia uma mensagem push usando
o tópico do PubSub.
PubSub é um produto
do Google Cloud Platform.
Mas não se preocupem.
Há cotas gratuitas,
suficientes para as notificações
do Play Faturamento.
Façam o teste.
O PubSub é ótimo para envio de mensagens.
Você está registrado nesse tópico.
Você consome esse tópico com a mensagem.
Depois de consumir, você pode dizer:

Indonesian: 
Anda seharusnya tahu bahwa itu terjadi
sehingga kami dapat mengirimkan pesan.
Hai, Anda memiliki masalah dalam
proses pembayaran.
Ingin memeriksa dan mencoba lagi?
Sehingga hal ini dapat mengurangi banyak 
churn paksa di aplikasi Anda.
Sehingga ini adalah cara Anda
memenangkan kembali pengguna, bukan?
Lalu saat sesuatu terjadi,
Play Store akan mengirimkan push 
menggunakan topik PubSub.
Itu adalah-- PubSub adalah produk 
Google Cloud Platform.
Jangan khawatir.
Anda memiliki kuota gratis 
untuk digunakan, kuota gratis
pastinya cukup untuk 
notifikasi Layanan Penagihan Play.
Tentu saja, jika Anda ingin
menggunakannya,
Anda sangat disarankan untuk mencoba.
PubSub adalah produk yang bagus 
untuk komunikasi untuk perpesanan.
Tetapi Anda sudah terdaftar ke topik ini.
Sehingga Anda menggunakan topik ini
dengan pesan ini.
Dan setelah Anda menggunakannya,
Anda dapat mengatakan, oke, ini--

English: 
a change has occurred
on this subscription.
Like, the person has--
the user has canceled
the subscription.
And how you know that?
You receive-- this is a
notification, for example.
In this case, it's buy a new
subscription, subscription
purchase.
OK.
This will be received
by your server side.
Remember, this is
on our server side.
So you can use--
you have to develop, like,
a little infrastructure
to process this.
Can be whatever language
you want to use--
GoLang, Kotlin,
Python, whatever,
because it's an API, right?
It's a Pub/Sub.
It can just consume that.
And here you have
the purchase token.
That is what you need to
validate the purchase.
Then you have the subscription
package, and in this case,
the subscription
ID that you can use
as your SKU, your product ID.
With that, you know that
this user at that moment
has purchased a subscription.

Indonesian: 
perubahan telah terjadi pada 
langganan ini.
Seperti, orang tersebut telah--
pengguna telah membatalkan langganan.
Dan bagaimana Anda tahu?
Anda menerima-- ini adalah
notifikasi, misalnya.
Di kasus ini, hal ini adalah beli
langganan baru, subscription_purchased.
Oke.
Ini akan diterima oleh sisi server Anda.
Ingat, ini berada di sisi server kita.
Sehingga Anda dapat menggunakan--
Anda perlu mengembangkan, 
seperti, infrastruktur kecil
untuk memprosesnya.
Bahasa apa pun 
bisa Anda gunakan--
GoLang, Kotlin, Python, apa pun,
karena ini adalah API, bukan?
Ini adalah Pub/Sub.
Ini dapat menggunakannya.
Dan di sini Anda memiliki purchase_token.
Itu adalah hal yang Anda perlukan
untuk memvalidasi pembelian.
Lalu Anda memiliki paket
langganan, dan di kasus ini,
ID langganan yang dapat Anda gunakan
sebagai SKU Anda, ID produk Anda.
Dengan itu, Anda tahu bahwa pengguna ini
telah membeli langganan.

Spanish: 
"Bueno, hubo un cambio
en esta suscripción".
Por ejemplo,
el usuario canceló la suscripción.
¿Y cómo lo saben?
Esta es una notificación, por ejemplo.
En este caso, es para comprar
una suscripción nueva,
una compra de suscripción.
Esto se recibe en su servidor.
Recuerden que esto está
en nuestro servidor.
Así que pueden usar…
Tienen que desarrollar, digamos,
una pequeña infraestructura
para procesar esto.
Puede ser en el lenguaje que quieran.
GoLang, Kotlin,
Python, el que quieran,
porque es una API.
Es un Pub/Sub.
Puede consumir eso.
Y este es el token de compra.
Esto es lo que necesitan
para validar la compra.
Después, tienen el paquete de suscripción
y, en este caso,
el ID de suscripción que pueden usar,
como SKU o el ID de producto.
Con eso, saben que este usuario
compró la suscripción en ese momento.

Chinese: 
该订阅发生了变化
比如说
用户已经取消了订阅
您是怎么知道的？
这里是一个通知的例子
针对的是新的订阅
购买交易
好
这将由服务器端接收
请记住，是在服务器端
因此
您需要开发一个小型基础架构
来处理它
您可以使用任意语言
GoLang、Kotlin、Python 都可以
因为它是一个API
是Pub/Sub
可以直接使用
这里是purchaseToken
您需要用它来验证购买
这里是订阅包，在本例中
就是SubscriptionId
可以将它作为SKU/产品ID
这样，您就知道该用户在这个时间
购买了订阅

Japanese: 
このサブスクリプションで変化が
起こったことがわかり
たとえば
ユーザーがサブスクリプションをキャンセルした
などです
どうやってわかるのでしょうか？
これが受取る通知の例です
この場合は 
新たにサブスクリプションを買った例です
サブスクリプションの購入です
OK
これがサーバー側で受け取られます
これはサーバー側です
これを使うには
これを処理するには
ちょっとしたインフラを開発する
必要があります
どんな言語でもかまいません
GoLang Kotlin Pythonなど
APIだからですね
これがPubSubです
コンシュームするだけです
ここに購入トークンがあります
購入でこれを認証する必要があります
そしてサブスクリプションパッケージです
この場合
SKUプロダクトIDとして
サブスクリプションIDが使えます
これを使えば
その時点でのこれのユーザーが
サブスクリプションを買ったことがわかります

Korean: 
이 구독에 사용자가 구독을
취소하는 것과 같은 변경이 발생했음을
파악할 수 있습니다
그것을 어떻게 알 수 있을까요?
여러분은 예시와 같은 알림을 받게 됩니다
이 경우 새로운 구독 구매가
발생한 것입니다
아시겠죠?
이것은 여러분의 서버 측에서 발생합니다
기억하세요, 이것은 서버 측에 있습니다
따라서 여러분은
이를 처리할 약간의 인프라를
개발해야 합니다
사용하고 싶으신 어떤 언어든
괜찮습니다
GoLang, Kotlin, Python, 어떤 것이든지요
왜냐하면 이건 API이기 때문입니다
Pub/Sub라서
소비할 수 있습니다
그리고 여기에
구매 토큰이 있습니다
이것은 여러분이 구매를 인증하기 위해
필요한 것입니다
그 다음으로 여러분은
구독 패키지를 갖게 됩니다
SKU, 제품 ID로 사용할 수 있는
구독 ID이죠
이를 통해 여러분은
이 사용자가 그 순간에
구독을 구매했음을 알 수 있습니다

Portuguese: 
"Houve uma mudança com essa assinatura."
O usuário cancelou a assinatura.
E eu sei disso porque recebo
uma notificação como esta, por exemplo.
Nesse caso, é sobre a comprar de uma
nova assinatura, SUBCRIPTION_PURCHASED.
Ela será recebida pelo seu servidor.
Lembre-se de que é no nosso servidor.
Desenvolva uma
pequena infraestrutura de processamento.
Pode ser em qualquer linguagem,
Go, Kotlin, Python, porque é uma API.
É PubSub. Ele pode consumir.
Aqui você tem o token de compra.
É o que você precisa para
validar a compra.
Você tem o pacote de assinaturas e,
nesse caso,
o ID da assinatura que você pode usar
como SKU, ID do produto.
Com isso, você sabe que
esse usuário, nesse momento,
comprou uma assinatura.

Portuguese: 
Não é preciso criar uma solicitação da API
para validação, porque ela vem do Google.
E só você pode consumi-la,
porque está registrada
no Console do Cloud.
Além disso, é muito mais confiável
usar a notificação em tempo real
do que pesquisar novas assinaturas
no servidor.
Meu tempo está acabando.
Versões em Kotlin e C++...
Estamos trabalhando nas
novas versões para C++.
Sabemos que isso é necessário
para Unity e Unreal.
Estamos trabalhando com eles.
Se você quer receber atualizações
e testar C++
nos plug-ins da Unity e da Unreal,
falem conosco.
Você pode nos visitar aqui ou
enviar um e-mail para os contatos
que vamos mostrar no final.
O Play Pass é outro recurso legal
que lançamos recentemente.

Spanish: 
Para validarla, no necesitan una solicitud
a la API de Google Play Developer
porque esto viene de Google.
Y solo ustedes pueden consumirlo
porque está registrado en Cloud Console.
Y, además, es mucho, mucho más…
más confiable usar la notificación
de desarrolladores en tiempo real
que consultar el servidor en busca
de suscripciones nuevas.
Se me está acabando el tiempo.
Las versiones de Kotlin y C++.
Estamos trabajando
en versiones nuevas de C++.
Y sabemos que eso es necesario
para Unity y para Rio.
Así que estamos trabajando en eso.
Y si les interesa tener actualizaciones,
recibir actualizaciones y probar C++
o Unity y complementos de Rio,
vengan a conversar con nosotros.
Pueden visitarnos aquí o enviar
un correo electrónico a los contactos
que mostraremos al final.
Y Google Play Pass es otro servicio
que está muy bueno y lanzamos hace poco.

Japanese: 
プレイ デベロッパーAPIリクエストを出して
認証する必要はありません
なぜならこれはグーグルから
来ているからです
これをコンシュームできるのは
クラウドコンソールに
登録されているからです
そのため
新規サブスクリプション用に
問い合わせるより
リアルタイム デベロッパー通知を使うほうが
ずっと信頼性があります
OK
時間がなくなってきました
KotlinとC++バージョンです
C++の新しいバージョンに
取り組んでいます
UnityとRioで使います
これに取組んでいます
アップデートを手に入れたい人は
アップデートの入手や
C++またはUnity Rioプラグインのテストについては
ご相談ください
ブースに来ていただくか
連絡先にメールをください
プレゼンの最後にお見せします
プレイパスです
別の仕組みです
最近 発表した優れものです

Korean: 
따라서 여러분은
Play Developer API 요청을 실행하여
이를 인증할 필요가 없습니다
이것은 Google로부터 오는 것이기 때문입니다
이것이 Cloud Console에
등록되어 있기 때문에
여러분만 이를 소비할 수 있습니다
또한 실시간 개발자 알림을 사용하는 것이
새로운 구독을 확인하기 위해
서버를 폴링하는 것보다
훨씬 더 신뢰할 만합니다
좋습니다
시간이 다 되어 가는데요
Kotlin과 C++ 버전에 관해 말씀드리겠습니다
Google은 C++의 새로운 버전을 위한
작업을 하고 있습니다
그리고 저희는 이것이 Unity와
Unreal에 필요하다는 것을 압니다
그래서 저희는 이들과 협력하고 있습니다
새로운 소식을 받고
C++ 또는 Unity 및 Unreal
플러그인을 테스트하는 데 관심이 있으시면
저희에게 말씀해 주세요
Google에 방문하시거나
제가 말미에 보여드릴 연락처로
이메일을 보내 주세요
그리고 Play 패스입니다
이건 또 다른 것인데요
저희가 최근에 출시한
매우 근사한 서비스입니다

Chinese: 
您不需要发送Play Developer API请求
来验证，因为这些信息来自Google
只有您可以使用该信息
因为它已在Cloud Console上
注册
此外
对于新的订阅，使用实时开发者通知
比轮询服务器要可靠得多
好
时间快不够了
Kotlin和C++版本，我们正在为C++开发
新的版本
这对Unity和Unreal很有必要
因此我们正在和他们合作
如果您有兴趣获取更新
接收更新、测试C++或Unity和Unreal插件
欢迎来找我们讨论
您可以在这里与我们交流，也可以发送电子邮件
会议结束时会提供联系信息
下面说Play Pass
这是我们最近推出的
又一个酷炫功能

English: 
So you don't need to
do a Play Developer API
request to validate it, because
this is coming from Google.
And only you can consume
this because it's registered
on the Cloud Console.
And also it's much, much more--
it's much more reliable
using the real time developer
notification then polling the
server for new subscriptions.
OK.
I am also running
out of the time,
so Kotlin and the C++ versions,
we are working on new versions
for C++.
And we know that it's
necessary for Unity and Rio.
So we are working with them.
And if you are interested
on having updates,
receiving updates, and testing
C++ or Unity and then Rio
plugins, come to talk with us.
So you can come visit us here
or send an email to the contacts
we're going to show in the end.
And Play pass.
Is also another stuff.
Very cool that we
launch it recently.

Indonesian: 
Anda tidak perlu melakukan 
permintaan API Developer Play
untuk memvalidasinya, 
karena ini datang dari Google.
Dan hanya Anda 
yang dapat menggunakannya
karena ini terdaftar pada Cloud Console.
Dan ini juga jauh lebih--
ini jauh lebih dapat diandalkan 
menggunakan notifikasi developer real time
lalu melakukan pemeriksaan
server untuk langganan baru.
Oke.
Saya juga kehabisan waktu,
Kotlin dan versi C++, kami 
sedang mengerjakan
versi baru untuk C++.
Dan kita tahu bahwa ini
perlu untuk Unity dan Rio.
Sehingga kami mengerjakannya
dengan keduanya.
Dan jika Anda tertarik
untuk melakukan update,
menerima update, dan menguji
plugin C++, atau Unity,
dan Rio, datang dan berbincang
dengan kami.
Anda dapat mengunjungi kami di sini atau 
mengirimkan email
ke kontak yang akan 
kami tampilkan di akhir sesi.
Dan Play pass.
Adalah hal lainnya.
Sangat keren yang kami
luncurkan baru-baru ini.

Chinese: 
大家可能已经有所了解
您只需按固定价格付款一次
就可以获取许多游戏和订阅
这非常酷
如果您希望尝试不同的游戏和产品
这很实用
如果您想在您自己的产品中使用它
可以访问developer.android.com上的表格
最后，立即开始使用
您可以访问Play结算库参考资料
只需进入developer.andorid.com/google/
play/billing
它全面介绍了开发者实施
Play结算库的各个环节
您还可以看看我们的样本
我们提供实时开发者通知的样本
包括服务器端代码
我们提供使用Kotlin的Trivial Drive 2.0版
从中可以看到我们的实施过程
请在社交媒体上关注我们
并提供反馈

Korean: 
보신 적이 있겠지만 이것을 사용하면
정해진 액수와 가격으로
여러 게임과 구독에 액세스할 수 있습니다
매우 훌륭하죠
다양한 게임과 제품을
사용해 보고 싶은 경우
아주 유용합니다
제품 사용에 관심이 있으시면
developer.android.com에서
양식을 작성하시면 됩니다
오늘 바로 시작하세요
Play 결제 라이브러리 레퍼런스를
사용하실 수 있습니다
d.andorid.com/google/play/billing을
방문하시면 됩니다
여기에는 Play 결제 라이브러리를
구현하는 방법에 대해 단계별로 다루는
전체 개요가 담겨 있습니다
그리고 저희의 샘플을 살펴보세요
저희는 서버 측 코드를 포함하여
실시간 개발자 알림을 위한
샘플을 가지고 있습니다
저희는 Kotlin으로 작성된 
Trivial Drive 2.0 버전을 가지고 있습니다
따라서 저희가 이를 구현하는
방법을 보실 수 있습니다
또한 소셜 미디어 채널에서
저희를 팔로우해 주시고
피드백을 주세요

English: 
I imagine you saw that you can--
for a fixed amount,
for a single price,
you can-- you have access for
many games and subscriptions.
It's very cool.
If you want to try different
games and different products,
it's very cool.
If you are interested to
offer it using your product,
there is a form in
developer.android.com.
And get started today.
So you have the Play
Billing Library reference.
So it's just going
developer.andorid.com Google
Play Billing.
That's a full overview with all
steps covering the developer
journey on how to implement
the Play Billing library.
And take a look at our samples.
We have samples for real-time
developer notification,
including server side code.
We had the Trivial Drive
2.0 version in Kotlin.
So we can see the implementation
how we are doing this.
And please follow us in
the social media channels.
Give your feedback.

Spanish: 
Imagino que vieron
que por un importe fijo y un precio único,
pueden acceder
a muchos juegos y suscripciones.
Es ideal para probar juegos
y productos diferentes.
Si les interesa ofrecerlo con su producto,
hay un formulario en
developer.android.com.
Y pueden comenzar hoy mismo.
Tienen la referencia de la Biblioteca
de Facturación Google Play.
Hay que ir a Facturación Google Play
en developer.android.com.
Verán una descripción completa
con todos los pasos del recorrido
que deben seguir los desarrolladores
para implementar la Biblioteca.
Miren las muestras.
Tenemos las notificaciones
para desarrolladores en tiempo real,
incluido el código del servidor.
Está la versión Trivial Drive 2.0 en Kotlin
para ver cómo hacemos la implementación.
Sigan nuestros canales de redes sociales.
Compartan sus comentarios.

Portuguese: 
Por um valor fixo, você tem acesso
a vários jogos e assinaturas. É bem legal.
Testar jogos e produtos diferentes.
Se você tem interesse
em oferecer o Play Pass,
há um formulário em
developer.android.com.
Comece hoje mesmo.
Você tem a referência da
Play Billing Library.
Estará em
developer.andorid.com/google/play/billing.
Há uma visão geral completa com
as etapas para que o desenvolvedor
saiba como implementar a
Play Billing Library.
Dê uma olhada nas nossas amostras.
Há amostras para
notificação em tempo real,
incluindo códigos do servidor.
Temos a versão 2.0
do Trivial Drive em Kotlin.
Você pode ver como estamos
fazendo a implementação.
E sigam o Google nas redes sociais.
Deem feedback.

Indonesian: 
Saya membayangkan Anda bisa--
untuk jumlah tetap, untuk satu harga,
Anda bisa-- Anda memiliki akses untuk 
banyak game dan langganan.
Itu sangat keren.
Jika Anda ingin mencoba game 
dan produk yang berbeda.
Itu sangat keren.
Jika Anda tertarik untuk 
menawarkannya menggunakan produk Anda,
ada formulir di developer.android.com.
Dan mulai hari ini.
Anda memiliki referensi 
Library Layanan Penagihan Play.
Sehingga cukup Anda hanya buka
developer.android.com,
Layanan Penagihan Google Play.
Itu adalah ringkasan keseluruhan 
dengan langkah yang meliputi
developer journey tentang 
cara mengimplementasikan
library Layanan Penagihan Play. 
Dan lihatlah contoh kami.
Kami memiliki contoh 
untuk notifikasi developer real-time,
termasuk kode sisi server.
Kami memiliki Trivial Drive
versi 2.0 di Kotlin.
Kami dapat melihat implementasi
cara kami melakukan ini.
Dan silakan ikuti kami di 
saluran media sosial.
Berikan masukan Anda.
Kami dengan senang hati 
mendengar masukan

Japanese: 
ご覧になったことがあるかと思いますが
定額で
単一価格で
色んなゲームやサブスクリプションに
アクセスできます
すばらしいサービスです
ゲームや製品をたくさん試してみたい人に
ぴったりです
自分の製品も載せてみたいという人は
developer.android.comに申込書があります
今日からでも始められます
プレイ課金ライブラリのリファレンスです
developer.andorid.comです
Google Play課金です
プレイ課金ライブラリのインプリメント方法について
デベロッパーがやることをカバーした
全ステップの概要です
私たちのサンプルも見てみてください
リアルタイムのデベロッパー通知の
サンプルを用意しています
サーバー側のコードもあります
Kotlinで書いたTrivial Drive2.0もあります
私達がどうやっているか
インプリメンテーションが見れます
ソーシャルメディアチャネルでも
私達をフォローしてください
フィードバックをお願いします

Portuguese: 
Gostamos de ouvir feedback sobre
experiências com a Play Billing Library.
Nas amostras, por exemplo,
se encontrar algo errado,
envie uma notificação no GitHub.
Teremos o prazer de
ajudar vocês nessa implementação.
Muito obrigado.

Chinese: 
我们欢迎您就使用Play结算库的体验
提供反馈
或者就样本提供反馈
例如，如果发现错误，请在GitHub上
给我们发送消息
我们非常乐意
帮助您完成实施
好了
非常感谢大家
[掌声]
[播放音乐]

Japanese: 
実際にプレイ課金を使ってみた印象や
フィードバックをぜひお願いします
サンプルに関して
おかしなところを見つけたら
GitHubで教えてください
インプリメンテーションでお手伝いできる
ことがあれば
ぜひご連絡ください
以上です
ありがとうございました

Spanish: 
Nos encantaría conocer su experiencia
con la Facturación Play.
Qué les parecieron las muestras.
Si encuentran algo mal,
envíennos el problema mediante GitHub.
Son más que bienvenidos.
Estaremos más que contentos
de ayudarlos con esta implementación.
Muchas gracias.

Indonesian: 
tentang pengalaman Anda 
di Layanan Penagihan Play Live
atau masukan Anda.
Pada contoh, misalnya, Anda bisa--
jika Anda menemukan kesalahan,
beri tahu kami 
tentang masalah tersebut di GitHub.
Kami sangat senang--
sangat senang membantu 
Anda pada implementasi ini.
Oke?
Terima kasih banyak.
[TEPUK TANGAN]
[ALUNAN MUSIK]

English: 
We'd love to hear feedback about
your experience of Play Billing
Live or your feedback.
On the samples, for
example, you can--
if you find something
wrong, please send us
a issue on GitHub.
We're more than welcome--
more than glad to help you
on this implementation.
OK?
Thank you very much.
[APPLAUSE]
[MUSIC PLAYING]

Korean: 
여러분의 Play 결제 라이브러리
사용 경험에 대해
피드백을 받고 싶습니다
예를 들어, 샘플에서
잘못된 점을 발견하신다면
GitHub에서 문제를
저희에게 신고해 주시면
대단히 감사하겠습니다
이 구현이 여러분에게 
도움이 되기를 바랍니다
대단히 감사합니다
[박수]
[음악 재생]
